Douglas Gregor wrote:

On Monday 03 March 2003 05:57 am, Russell Hind wrote:

...

Do (or should) all the bost headers force alignment before all structures/classes and then restore the alignment afterwards?

I don't see any reason that the Boost headers should do this unless they require a certain alignment to operate (and this should never be the case).

The problem goes deeper than the answer addresses. Certain compilers allow one to set the alignment ( and enumeration size, among other command-line changeable qualities which could affect the layout of data ) using #pragmas in the header files themselves. When this is done the compiler uses these settings consistently for the data in that header file no matter what other settings are used in a command-line or IDE build. Setting these very compiler-specific #pragmas protects the header file, and appropriate data it encompasses, from being passed incorrectly between the end-user and the implementation. This ability is a great boon to 3rd party developers of object-oriented software since it protects their users from data layout surprises. Both the Microsoft and Borland compilers support such #pragmas and use the conscientiously for all their RTL and other internal library header files. To say that Boost does not want to use the same technique for particular compilers, when it is available, appears very retrograde to me. Yes, it is possible that Boost may want to say that it doesn't know what the best alignment should be and wants to leave it to developers who build the libraries, but that will not protect the end user unless Boost makes it clear that developers may alter the distribution for themselves in order ot provide the correct alignments through these #pragmas. However, as a practical matter I see little benefit in this approach. The reasons for this is that alignment, enumeration size, and other possible issues relating to data layout are not issues which really need much serious decision. The various compilers do suggest the best default conditions in order to provide the maximum possible speed on various CPUs but in these days of faster CPUs, I personally wouldn't spend too much time worrying about setting other possible values. But whether one chooses to set the default values or other possible values in the appropriate header files through #pragmas, as long as one sets some reasonable value, the compiler will use it and avoid data mismatch. It is not good enough to just say, build your implementation from the command line using some value. This is because if it is not seen in the header file via the appropriate #pragma, when the end-user uses your OOP construct as defined in the header file, the end-user's command-line or IDE value at the time he compiles will be used, and this may not be the same as the value the implementor used to build. Nor is it good enough to use some command-line or IDE value when building your implementation and then telling the end-user that they have to use the exact same value when using your implementation. I hope I don't have to explain why this is so. I will anticipate two final objections to using particular compiler #pragmas in Boost implementation code: 1) It's not mandated in the C++ standard. Yes, #pragmas are implementation defined, but so what. Lots of other Boost code deals with implementation shortcomings in a compiler's adherence to the C++ standard and, while I hope for Boost someday to be able to chuck all those #ifdef and workarounds regarding many compiler's support for the C++ standard in the garbage, as soon as all C++ compilers are 100% conformant as they should theoretically be, surely a relatively benign use of #pragmas to eliminate data layout errors for end-users is worthwhile. 2) Boost developers have to know these #pragma tricks to use them. John Maddock already uses these #pragmas for VC++ and C++ Builder in his Boost.Regex++ library. Others will know them for these compilers, as well as other compilers if they exist, and will be glad to inform Boost developers about them for the compilers which they know about. Adding them to header files is a no-brainer experience for both VC++ and C++ Builder and may be for other compilers which have them. Finally, I admit as a 3rd party developer on Windows who has supplied implementation code for end-users of VC++ and C++ Builder, that I consider it almost "criminal" in a computer programming sense when an end-user is not protected by these #pragmas from possible changes he may make at the command-line or from within an IDE. Surely if Microsoft and Borland have gone out of the way top provide this fail-safe method of eliminating data layout errors, an intelligent implementor can use these methods.

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.

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. --Beman

Edward Diener wrote:

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,

It is implementation-defined whether or not the contents of a #pragma directive are macro expanded--I think that VC allows it. C99 explicitly allows it, but says that any #pragma that begins with STDC is explicitly _not_ macro expanded. C99, of course, has the _Pragma operator which can be generated by a macro expansion (not that that is relevent here). Paul Mensonides

Edward Diener wrote:

...

It is implementation-defined whether or not the contents of a #pragma directive are macro expanded--I think that VC allows it. C99 explicitly allows it, but says that any #pragma that begins with STDC is explicitly _not_ macro expanded. C99, of course, has the _Pragma operator which can be generated by a macro expansion (not that that is relevent here).

The opposite way was what I was wondering about. Can a #define create a #pragma which then is picked up as a preprocessor line ? As an example will this work:

#define CREATE_PRAGMA #pragma somepragma

// Code CREATE_PRAGMA // Code

Will a compiler correctly pick up the #pragma as a preprocessor line or is the preprocessor stage finished once the macro is fully expanded ? I believe the latter is true, although I could be wrong.

It is not technically legal, but it might work anyway, as #pragmas usually aren't picked up by the preprocessor.

If I am right, then creating a Boost macro for these data layout #pragmas for BCB and VC++, and any other compiler which lets one fix data layout details such as packing from within each header file, will not work. In that case the alternative of a easily remembered header file name, which contains the appropriate #pragma, is a good alternative for adding such #pragmas in the correct place of header files which need such data layout reliability.

Well, #pragmas that the compiler doesn't understand are supposed to be ignored. However, using a header for it is also a good option. You can even use a macro to introduce the header if you like: #include CREATE_PRAGMA() Paul Mensonides

Edward Diener wrote:

...

Well, #pragmas that the compiler doesn't understand are supposed to be ignored. However, using a header for it is also a good option. You can even use a macro to introduce the header if you like:

#include CREATE_PRAGMA()

Will the above really work ? I was always pretty sure that #includes have to be processed before macros are expanded and not after.

Yes. Actually, it works on all compilers too. The file-iteration mechanism, among other things, of the pp-lib uses this behavior all the time. More specifically though, both the Python library and the MPL both use file-iteration extensively. Technically speaking, the #line, #include, #if, and #elif directives must be macro-expanded. For #error and #pragma directives, the behavior is unspecified, but the C99 standard explicitly says that #pragma's of the form: #pragma STDC xyz ...are _not_ macro expanded, even if other #pragma's are. All other directives make no sense to macro-expand. (#define, #undef, #else, #endif) Regards, Paul Mensonides

Peter Dimov wrote:

The alternative is simple: always build libraries and applications using the _exact same_ settings. This is a good general advice, and it also applies to settings that we cannot "fix" using the #pragma method.

I think this is limiting. I don't mind what setting the library uses, but I don't like the fact that my project options can cause crashes in the library. As an aside, if I want to build boost libraries forcing 4 byte alignment, how do I pass -a4 to bjam so that they are built the same? (And as asked elsewhere, how do I force BOOST_HAS_THREADS with bjam also?) Thanks Russell

Russell Hind wrote:

As an aside, if I want to build boost libraries forcing 4 byte alignment, how do I pass -a4 to bjam so that they are built the same? (And as asked elsewhere, how do I force BOOST_HAS_THREADS with bjam also?)

Based on a cursory look at the Boost.Build documentation and the "borland" toolset file (borland-tools.jam), I think that the answers to these questions are bjam -sTOOLS=borland -sBUILD="<cxxflags>-a4" and bjam -sTOOLS=borland -sBUILD="<threading>multi" respectively. Alternatives include: - editing borland-tools.jam and changing -a8 to -a4. - editing borland-tools.jam and removing -a8, allowing your -a4 option in bcc32.cfg to take effect. - making a dedicated library project for Boost.Signals and building from the IDE, bypassing bjam. If this doesn't help, try the boost-install list: http://lists.boost.org/mailman/listinfo.cgi/boost-install

Peter Dimov wrote:

Edward Diener wrote: [...]

...

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.

The issue is less clear-cut than you make it seem.

What we have here is a static library (Signals) that uses several header-only libraries (shared_ptr, Function, maybe others.)

OK, I do see this problem.

To "fix" the "alignment problem", we need not only #pragmify Signals, but those other header-only libraries as well. Furthermore, we need to be careful to not miss a header-only library that is used, directly or indirectly, by Signals, or any other static library.

I view it this way. The people who create libraries, whether header-only or implementation, should be responsible for setting reasonable data layout details. After all, as I have previously mentioned, Borland sets data layout #pragmas for all of their RTL code even when the header is a class template, and therefore likely to be a header-only implementation.

This impacts not only Signals users; it also affects those that only use header libraries. They don't need the "fix", and some of them may legitimately object to the binary compatibility settings that the headers have inflicted on them, especially if these settings lead to slower or larger code.

Yes, I agree in theory. But compiler implementors do do this and I don't think they really get complaints saying "Gee, I don't like your pack alignment for your XXX class. It's really slowing me down."

The alternative is simple: always build libraries and applications using the _exact same_ settings. This is a good general advice, and it also applies to settings that we cannot "fix" using the #pragma method.

I don't think the alternative is simple. Do you feel good forcing end-users of Boost to build their applications according to what settings you specify ? And what happens if another 3rd party developer tells their end-users that they must build their applications to settings they specify and it is not the same as the Boost settings ? And what if the end-user needs to change from the Boost settings for their own purposes ? Dictating to the end-user what you insist his settings must be in order to use libraries effectively is not my idea of a simple or good alternative. I recognize that you have brought up valid points, but I would still much rather protect the end-user against inadvertent data layout problems if they change their own global settings than worry that they might not like the data layout I set for my own classes.

Edward Diener wrote:

#pragma push -someoptions

The options from windows.h of C++Builder 6 Pro are #pragma option push -b -a8 -pc -A- /*P_O_Push*/ along with the pop at the bottom. These are: -b: Force enums to be of integer size -a8: Force 8 byte alignment on structs -pc: Force 'C' calling convention -A-: Disable use ANSI keywords and extensions (because windows headers won't compile in strict ansi mode, apparently) For Borland, it might also be worth adding -Vg- which disables CodeGuard. Just in case there are allocations done in inline code in header files which are then freed in methods in the compiled lib (which may/may not have been built with CodeGuard). Also, being able to disable some of these options or all of them with a #define would also be useful so that you could link with the code directly (as I have done to get round the current problems) and there fore build with CodeGuard and other options to test the library. Unfortunately I haven't used any compilers other than bcc32 (for a long time anyway) to be able to help/test other versions of the headers, but I can help with the Borland version of them. Cheers Russell

Edward Diener wrote: [...]

Finally, I admit as a 3rd party developer on Windows who has supplied implementation code for end-users of VC++ and C++ Builder, that I consider it almost "criminal" in a computer programming sense when an end-user is not protected by these #pragmas from possible changes he may make at the command-line or from within an IDE. Surely if Microsoft and Borland have gone out of the way top provide this fail-safe method of eliminating data layout errors, an intelligent implementor can use these methods.

It is certainly "criminal" to not use the appropriate #pragma mechanism if you provide a binary compiler-specific distribution that depends on certain alignment (and other options affecting binary compatibility: enum size, empty base/member optimization, and so on.)

Peter Dimov wrote:

...

Currently, I have to link directly with the signals source code to get use the library.

This is what I'd do, too. The other alternative is to build several .lib files that match the options specified in your various project configurations (Debug, Debug MT, Release, Release MT, or however their canonical names are in BCB).

The problem with linking with the source directly (not a major problem) is that we have our own Thread.cpp which we're planning on turning into a wrapper around boost::thread (it currently uses Win32 threads directly). Unfortunately C++Builder won't allow 2 cpp files in the same project with the same name, even if they reside in different directories. We can get around this re-naming either the boost thread.cpp or own own, but it is a bit of a pain (but we haven't run into a problem with the thread library wrt this). As mentioned in the rest of the thread by Edward Diener, bcc32 supports #pragma option push and #pragma option pop to temporarily force compiler options, which as also mentioned, is how the headers that come with the compiler are configured so that the alignment for anything declared in there headers matches what was built into the .lib and therefore we can use our own compiler options for our code but not run into any problems with the pre-compiled libraries. Do you not think the same approach would work in boost? (I don't know how much support there is for push and pop of options in other compilers, though) Cheers Russell

Info: http://www.boost.org Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl Unsubscribe: mailto:boost-users-unsubscribe@yahoogroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Someone that knows the C/C++ Spec better than should confirm or deny this, but somewhere in the deep dark recesses of my memory there is something about pragma's and macros not working together. That is pragma's cannot appear in macros and expect to be acted upon. Can anyone confirm or deny this from the spec (different compilers may or may not support this "feature"). ...Duane