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? 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 :-) I'll file items for these issues so that they are tracked.
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 would have better luck implementing a portable export (the previous version) rather than figuring out hacks for each compiler.
I don't think the previous was any more portable. It just seemed that way because it had been worked over longer.
I'm not so sure. It wasn't thread-safe but the behaviour was definitely well-defined according to the C++ standard.
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.
Note there is one important scenario for which EXPORT is by far the best solution. That is for plug-ins in DLLS. In this scenario, each DLL automagically registers the types it uses when it is loaded, and unregisters those same types when it is unloaded. This means that one can make a main program which will handle all future types even though they are not currently known. As far as I know, runtime linking and its implications for code compilation are not addressed by the C++ standard and this is why we have those compiler specific hacks in there.
(Maybe C++ commitee gurus want to think about this?).
Simple, mandated [[init]] and [[fini]] attributes would be awesome.
So a good place to start to address this for your SunCC compiler is how is such a compiler used to create a DLL? What has to be done to tell the compiler to instantiate code not explicitly called and the optimizer not to strip it as dead code? This is basically how we came up wth the hacks that are in there now.
It seems that there is support for GCC's __attribute__((constructor)) in the latest version so I might give that a shot. Maybe I'll just have to bite the bullet and stop using these features.
Good Luck with this.
Thanks! I'll let you know if anything comes of it.