David Abrahams wrote:
on Tue Feb 17 2009, Sohail Somani <sohail-AT-taggedtype.net> wrote:
Hi Robert,
Robert Ramey 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
Sohail Somani wrote: 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 ;-)
In general, yes. But I found that the way Robert had documented it was sufficient for it not to be a problem.
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?
Manually instantiating for hundreds of classes is not exactly easy. So it will eventually be healed, but may take a while :-)
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.
I am currently attempting to upgrade from 1.34.1.
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.
You are right! [snip]
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.
Where? http://www.boost.org/doc/libs/1_34_1/libs/serialization/doc/special.html#exp... Anyway, what is done is done. -- Sohail Somani http://uint32t.blogspot.com