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. Of course this meant some of the indicated hacking to implement some things not guarenteed 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.
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. 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.
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. 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?). 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. Good Luck with this. Robert Ramey