Static Initialization

[2wycked]

I'm trying to initialize a static block of memory to all zeros using (essentially) the following code:

[CODE=cpp]
#define NUM_BYTES 2048

typedef unsigned int uint;

class SomeClass {
protected:
static const uint* some_block();
public:
// more methods and such...
};

const uint* some_block() {
static bool isUninit = true;
static uint block[NUM_BYTES];
if( isUninit ) {
uint* at = block + NUM_BYTES;
while( at-- > block) *at = 0;
isUninit = false;
}
return block;
}

[/CODE]

My question is if there is an easier way to do this initialization, i.e. without using isUninit. I don't think there is any guarantee that the block will be initialized to all zeros, but is there a way to avoid having isUnint?

Thanks

[weaknessforcats]

Since

static uint block[NUM_BYTES];

is not part of any object, you could just define the array as a global:
[code=cpp]
class SomeClass
{
static uint block[NUM_BYTES];
};

uint SomeClass::bloc k[NUM_BYTES] = {0};
[/code]

You should also be using a Singleton to front this array to avoid breaking encapsulation. There is an article about Singletons in the C/C++ Articles forum.

[2wycked]

You should also be using a Singleton to front this array to avoid breaking encapsulation. There is an article about Singletons in the C/C++ Articles forum.

I forgot to mention that SomeClass is an ADT, so there are no instances of SomeClass. I believe this covers the Singleton issue, bur correct me if I'm wrong.

[weaknessforcats]

You are wrong and I think you may be confusing an Abstract Data Type (*like a class) with an Absrtract Base Class (has no objects).

It has to do with exposing the fact that you are using an array of uint.

As soon as this array is spattered throughout thye application and you need to redesign and implement a database rather than an array you are hosed.

The singleton is to be used as the interface to the array. It's methods manage the array. Ideally, you could re-engineer the array to a vector and as long as the published interface functions of the singleton class didn't change, all you need to is recompile an re-link the singleton code. In fact if you implement this as a dll, your application won't even know what you did. It would just load the new version of the dll.

And this also removes the requirement for static data. Static memory can be limited and you application may not be able to load. Try to stick with the heap.

[2wycked]

You are wrong and I think you may be confusing an Abstract Data Type (*like a class) with an Absrtract Base Class (has no objects).

It has to do with exposing the fact that you are using an array of uint.

As soon as this array is spattered throughout thye application and you need to redesign and implement a database rather than an array you are hosed.

The singleton is to be used as the interface to the array. It's methods manage the array. Ideally, you could re-engineer the array to a vector and as long as the published interface functions of the singleton class didn't change, all you need to is recompile an re-link the singleton code. In fact if you implement this as a dll, your application won't even know what you did. It would just load the new version of the dll.

And this also removes the requirement for static data. Static memory can be limited and you application may not be able to load. Try to stick with the heap.

Well, I'm in the process of writing my own memory manager, so using the heap would be circular in this case. What this is for is an allocation table, where the array represents a listing of bits that determine if a memory segment is managed by a heap or not. SomeClass is really class Heap, where Heap is an ADT, because I have purely virtual functions in the class. I could see where the singleton issue could come in, but since this needs to be declared before anything else, it seems to cry out to be static data. I'm essentially using Heap as an interface for the array, but I see where I could make the function some_block() private, because it's use is really only with another static Heap function.