Beman Dawes wrote:
At 07:09 PM 3/4/2003, Edward Diener wrote:
2) Boost developers have to know these #pragma tricks to use them.
I doubt you will make much head way trying to convince Boost developers to handcraft compiler specific #pragmas directly in their header files.
Have you considered proposing a macro which will automatically apply the appropriate #pragma for the compiler? That way the knowledge of what #pragma to apply for each compiler only has to be maintained and tested in one place.
Excellent idea. Now why didn't I think of that <g>. It's the old forest and the trees thing, no doubt. The macro would have to be in the form of: BOOST_DATA_LAYOUT_BEGIN at the beginning of a header file surrounding any class/struct/union/enum declarations and BOOST_DATA_LAYOUT_END at the end. The ending macro is needed because many implementations of #pragma allow: #pragma push -someoptions and then eventually #pragma pop to automatically remove the options and set them to their previous value, which is what one wants to do in these header files. I imagine the header file which has these macros would be the compiler specific header files in the config.h hierarchy and that one would set such data layout options to their default values through #pragmas as the default expansion of the macro. Of course we could get fancier and introduce some macro parameters to control the most popular data layout options such as packing and enumeration size if desired, but I actually think we should keep it as simple as possible. Maybe BOOST_DATA_LAYOUT_BEGIN for the default values and BOOST_DATA_LAYOUT_BEGIN_VALUES with some macro parameters for the more complicated cases. I see there is a clever macro library as part of Boost but the documentation is so horrendous that I have just turned away from it in chagrin. Perhaps that macro library has some functionality to make these macros easier to specify and to work with. But I think you get the general gist.