C Pointer Question

[N64vSNES]

I've been writing a image library to gain some knowledge in areas that I've been constantly getting other libraries to do for me and I've got a design like this:



So for the sake of keeping the code tidy, each format that the loader supports will be inherited from its own base class to deal with it's own loading and initializing.

Now with this approach I would have to declare things in each of the base class irrelevant of if that one gets used.

So for example, in my BMP base class, if I have the members "BitmapHeader" and "BitmapInfoHeader" but just declare them as pointers and keep them at NULL like this:

Code: Select all

class BitmapLoader
{
       public:
		BitmapLoader();
		~BitmapLoader();

	private:
		BitmapHeader *Header;
		BitmapInfoHeader *InfoHeader;

	protected:
		void LoadBMP(std::string filename, char *Pixels);
};

BitmapLoader::BitmapLoader()
{
	Header = NULL;
	InfoHeader = NULL;
}

I would expect the pointers to take up a few bytes, but I'm not 100% how resource heavy this would be.

So basically I'm asking, am I being retarded or would this be a sufficient design? And exactly how much room would a NULL pointer take?

Thanks!

[Light-Dark]

Not to sound retarded, but isn't a null pointer the same as setting it to 0, since null is nothing and zero is nothing so it would be the same as setting a 0 pointer which is going to take up very little space ? :S

[Falco Girgis]

Not to sound retarded, but isn't a null pointer the same as setting it to 0, since null is nothing and zero is nothing so it would be the same as setting a 0 pointer which is going to take up very little space ? :S

A pointer has a fixed size of 32-bits/4-bytes on a 32-bit operating system and 64-bits/8-bytes on a 64-bit operating system regardless of the value of the pointer.

I would have to see more than just that diagram to comment on the design, though. At least from a memory standpoint, a single pointer is never enough to make a fuss over... it's the same size as an integer on 32-bit Windows versions and the same size as 2 integers on 64-bit Windows versions.

[N64vSNES]

Not to sound retarded, but isn't a null pointer the same as setting it to 0, since null is nothing and zero is nothing so it would be the same as setting a 0 pointer which is going to take up very little space ? :S

A pointer has a fixed size of 32-bits/4-bytes on a 32-bit operating system and 64-bits/8-bytes on a 64-bit operating system regardless of the value of the pointer.

I would have to see more than just that diagram to comment on the design, though. At least from a memory standpoint, a single pointer is never enough to make a fuss over... it's the same size as an integer on 32-bit Windows versions and the same size as 2 integers on 64-bit Windows versions.

Exactly what I was looking for!

The idea is that the when the image class inherits all of the base classes it will inherit all of it's types, but if I dynamically allocate them then it would just inherit the NULL pointers and only get allocated if that specific format was determined to be the one that's required.

However, if each base class has 2-3 pointers, then for just these formats it could use up to 36 bytes of data per texture (on a 32-bit system). So even with that, it still seems like a bad idea. I'm really not sure.

[ismetteren]

Maybe i don't understand the design, but it seems a bit backwards to me. Why not let the different loaders inherit a common interface instead of having the common interface inherit each of the loaders?

[qpHalcy0n]

I would usually suspect that BMP, TGA, and whatever loaders to be children of an ImageLoader type object, not the other way around. It seems that you're starting very specific then getting more general as you cascade down the inheritance tree. This is the opposite of the concept where you ask "Is the <child> a type of <the parent>". So then, "Is an ImageLoader a type of a BMP Loader?" or is "A BMP loader a type of an Image Loader?".

Headers for images are generally considered disposable. You really only need them for the actual file loading. It would be handy if you had to load an image from disk several times, but if this is the case then you've got some even bigger problems to worry about. So in this sense, you don't really need to store them for the life of the object. Things that are common to all images however might be: width, height, bits per pel, pel format, the raw data array, and so on. This way you're not storing redundant data in children classes for things that are common for ALL images. Knowing all of this will allow you to do whatever image processing things that you need to do from the "most parent" class and is consequently where I would keep them. "I have an Image, now do stuff with it". Instead of "I have a bitmap, which is an image, now do stuff with it", "I have a targa, which is an image, now do stuff with it.". Very repetitive. The only thing that changes significantly from type to type is the actual loading which is a one time thing. Just always ask yourself, what is common to all of my things and what is unique about them. The common elements can go with the parent as they're shared, the unique things can be derived behaviours.

[N64vSNES]

I would usually suspect that BMP, TGA, and whatever loaders to be children of an ImageLoader type object, not the other way around. It seems that you're starting very specific then getting more general as you cascade down the inheritance tree. This is the opposite of the concept where you ask "Is the <child> a type of <the parent>". So then, "Is an ImageLoader a type of a BMP Loader?" or is "A BMP loader a type of an Image Loader?".

Headers for images are generally considered disposable. You really only need them for the actual file loading. It would be handy if you had to load an image from disk several times, but if this is the case then you've got some even bigger problems to worry about. So in this sense, you don't really need to store them for the life of the object. Things that are common to all images however might be: width, height, bits per pel, pel format, the raw data array, and so on. This way you're not storing redundant data in children classes for things that are common for ALL images. Knowing all of this will allow you to do whatever image processing things that you need to do from the "most parent" class and is consequently where I would keep them. "I have an Image, now do stuff with it". Instead of "I have a bitmap, which is an image, now do stuff with it", "I have a targa, which is an image, now do stuff with it.". Very repetitive. The only thing that changes significantly from type to type is the actual loading which is a one time thing. Just always ask yourself, what is common to all of my things and what is unique about them. The common elements can go with the parent as they're shared, the unique things can be derived behaviours.

I think I see what you mean. And the idea of The Image class is to be the most general because all the other classes I.E. bmp, tga, png etc are indeed children.

I think I was just over-complicating things

Thanks for the input!