Beman Dawes wrote:
At 10:58 PM 3/4/2003, Douglas Gregor wrote:
On Tuesday 04 March 2003 10:16 pm, Edward Diener wrote:
Beman Dawes wrote:
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.
Would you willing to provide the definitions for these macros (or, as I >suspect, begin/end headers)? I'd be happy to use them, but as I've never >needed such a thing I don't know the particular pragmas to use.
I'm in the same boat as Doug, and I expect other Boost developers are too.
It isn't just a header (and docs) that are needed; test cases would be important too. It would be easy for mistakes in these macros to give the appearance of working, but actually do nothing. If I understand it, you can only tell they are working correctly with a fairly sophisticated build test that deliberately tries to use object files compiled with conflicting options.
While I agree with test cases, at the simplest level of just setting the #pragmas to values, there should really be no problems. I am supposing that one can set a #pragma from within a #define, but if one can't, because a #define can't create another preprocessor statement, then the best generic choice, where one doesn't have to memorize the #pragma, is probably just creating a "begin" header file to be included at the beginning of appropriate headers with just the single starting pragma in it and a header file to be included at the end of the appropriate header with just a single ending pragma in it. Again John Maddock has used these #pragmas extensively in Regex++ to avoid data layout problems and I have used them in my libraries for the same reason, including my own components built on top of Regex++, and I have never encountered problems with them. In some of my classes I use different data layout options from Regex++ whose header files I include in my own and I have never had a problem reported about it. But I admit I have never tested both extensively by changing the data layout at the command-compiler/IDE compile level to find out although naturally I have tested my own implementation with default data layout options. But of course that doesn't make it fail-safe and it needs to be tested as you said. However, I would be very surprised if it didn't work as expected since I would expect to have heard screams and howls from Borland and MS users if it didn't.