Re: Re: Re: boost::signals build and C++Builder 6 Pro in 1.29.0

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-03-05 18:37:17

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.