C++ object for Device Independent Bitmaps

[David Cox]

Device independent bitmaps or DIBs consist of header information followed by
some number of color table entries followed by some number of pixels. The
number of color table entries and the number of pixels can only be
determined at runtime and must be stored in a block of memory immediately
following the header info. How would you model this in C++?

It is easy to create a C++ class called Bitmap that contains the header
information. But what about the color table and pixel array that are to
follow the header? Because their sizes cannot be determined until runtime,
what should be done with them?

class Bitmap {
// header info
// color table (size to be determined at runtime)
// pixels (size to be determined at runtime)
}

Is there a way to change a class definition at runtime? For example, at
compile time the color table would be declared as an array of 1 as well as
the array of pixels. Then at runtime, the color table would be redefined as
an array of 256 while the pixel array would be redefined to the number of
pixels. I don't think this is possible to do, but I thought I would ask.
What would be a good technique to handle this situation?

Thanks,
David

 

[benben]

Device independent bitmaps or DIBs consist of header information followed by
some number of color table entries followed by some number of pixels. The
number of color table entries and the number of pixels can only be
determined at runtime and must be stored in a block of memory immediately
following the header info. How would you model this in C++?

Design a class, manage a trunk of raw memory (the bitmap), then hold a
couple of pointers to the start of serveral sections in the trunk.

It is easy to create a C++ class called Bitmap that contains the header
information. But what about the color table and pixel array that are to
follow the header? Because their sizes cannot be determined until runtime,
what should be done with them?

class Bitmap {
// header info
// color table (size to be determined at runtime)
// pixels (size to be determined at runtime)
}

class Bitmap
{
struct header
{
//...
};

struct color_entry
{
// ...
};

struct pixel
{
//...
};

header* p_header;
color_entry* color_entries;
pixel* pixels;

// ...
};

 

[Cy Edmunds]

Device independent bitmaps or DIBs consist of header information followed
by
some number of color table entries followed by some number of pixels. The
number of color table entries and the number of pixels can only be
determined at runtime and must be stored in a block of memory immediately
following the header info. How would you model this in C++?

It is easy to create a C++ class called Bitmap that contains the header
information. But what about the color table and pixel array that are to
follow the header? Because their sizes cannot be determined until
runtime,
what should be done with them?

I would dynamically allocate the memory needed.

class Bitmap {
// header info
// color table (size to be determined at runtime)
// pixels (size to be determined at runtime)
}

class Bitmap {
// header info
// pointer to color table (allocated at runtime)
// pointer to pixels (allocated at runtime)
}

[snip]

Thanks,
David

Here is a C language solution:

http://astronomy.swin.edu.au/~pbourke/dataformats/bmp/

When I needed a C++ class to read and write bmp files I just wrote a wrapper
for this code. It worked fine.

 

[David Cox]

Has anyone tried using placement new with DIBs? I am thinking along the
lines of allocating a buffer for the entire DIB. Then use placement new to
point a header pointer to the first byte of the DIB, point an RGBQUAD
pointer to the first byte of the color table and a pixel pointer to the
first pixel.

These pointers would be private members of a Bitmap class and public
functions would manipulate the DIB with them.

 

[James Aguilar]

It seems like it would be just as safe to simply reinterpret_cast
pointers to structs from a big allocated block. You just have to make
sure that you don't clobber the data from a later section when
manipulating the section before, but that shouldn't be any worse than
the care you have to take normally.

 

[James Aguilar]

Actually, it seems I lied. Reinterpret cast is never safe. All the
same, if portability is no concern, then it will probably work. Also,
placement delete (to match up with your placement news) is said to be
unavailable on some platforms, so I don't know if you're any better off
that way.