on Tue Feb 17 2009, Sohail Somani <sohail-AT-taggedtype.net> wrote:
Hi Robert,
Robert Ramey wrote:
Sohail Somani wrote:
David Abrahams wrote:
Still, why intentionally restrict portability even further when the alternative was not burdensome to begin with?
The header ordering requirement of the previous system was considered a very large burden by a number of people. My view was that it wasn't that burdensome, but that if it could be eliminated, so much the better.
Is that a large burden by a few, vocal people?
No, I don't think so. Header ordering is deadly-hard to control. That's why we don't use qualified calls and overloading in the library namespace for customization points ;-)
Anyway, it has been done and from the sounds of it, does not appear to be reversible. The main issue is that it eliminated a wart for some but broke someone else's arm :-)
How's that? There's no longer a way to manually instantiate what you need? When did all this stuff start breaking for you? I made my changes to BOOST_CLASS_EXPORT years ago. IIRC it was still doing nonportable things before my changes, but was worse because of the header ordering stuff.
Of course this meant some of the indicated hacking to implement some things not guaranteed by the C++ standard. But then, the serialization library has a lot of that. On the upside, the implementation has been much improved so that these hacks are now all focused in a few places. This is much, much better. Downside is that whenever one changes anything in this area, some compiler is going to be left out in the cold.
Factoring of compiler hacks is helpful, so I am happy you decided to do that.
I thought I had done that.
Test results look to indicate to me that only a few - maybe only one - compiler is having trouble with the current system. Hopefully, some interested party will find the missing magic. The current hacks in export.hpp should provide hints of what to do.
It seems export.hpp is the least of the problems since that is somewhat well understood. base_object seems to not work anymore either:
http://www.boost.org/development/tests/trunk/developer/output/Sandia-sun-boo...
I think the export documentation should be modified to say (in big fat bold letters) that it should not be used in portable code.
I believe that the documentation does mention this. (Though not in big bold letters). I'm always gratified to receive suggestions for documentation enhancements through TRAK items.
Yep, I see it now:
http://www.boost.org/doc/libs/1_35_0/libs/serialization/doc/special.html#exp...
I don't recall reading such a thing in the 1.34.1 documentation.
Nope. The way I remember it: * I assumed Robert knew about his existing non-portability with BOOST_CLASS_EXPORT, so didn't feel the need to alert him * Robert didn't know about it * Robert found out some time after 1.34.1 came out and documented it. -- Dave Abrahams BoostPro Computing http://www.boostpro.com