I noticed that X bitmap (.xbm) image files double as valid C code, I assume so you can easily embed them in programs. It #defines constants for the width and height of the image, and includes the image data as a char array. That is, if you open the image as a text file, you'll see something like this:
#define radio_on_width 13
#define radio_on_height 13
static char radio_on_bits[] = {
0xe0,0x00,0x18,0x03,0x04,0x04,0xe2,0x08,0xf2,0x09,0xf9,0x13,0xf9,0x13,0xf9,
0x13,0xf2,0x09,0xe2,0x08,0x04,0x04,0x18,0x03,0xe0,0x00};
What is considered best practice for taking advantage of this in a project containing multiple source files? Right now, I have a header file which contains the following:
#ifndef BITMAPS_H
#define BITMAPS_H
//...
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wnarrowing"
#pragma GCC diagnostic ignored "-Wunused-variable"
// Radio buttons
#include "bitmaps/radio_off.xbm"
#include "bitmaps/radio_off_pressed.xbm"
#include "bitmaps/radio_on.xbm"
#include "bitmaps/radio_on_pressed.xbm"
#pragma GCC diagnostic pop
// ...
#endif // BITMAPS_H
And then I #include that when I need to use the bitmaps. I know that normally header files should only include declarations, not definitions, but the static declaration means that isn't a problem in this case, right? I have the header file #included in multiple source files, and it works for me so far, but it seems like something that might be considered bad practice, as it puts a separate copy of the array in every object file whose source file includes my header file. This shouldn't be an issue for small images like I'm using, but for larger images that are #included many times I could see it wasting space if the linker isn't smart enough to consolidate the arrays to a single copy. (Though with GCC at least, the -fmerge-all-constants option appears to do the job.)
Is there some reason why what I'm doing is a bad idea, or is it an accepted practice?