"Vyacheslav E. Andrejev" <vandrejev@excelsior-usa.com> wrote in message news:cnf21s$124$1@sea.gmane.org...
Hello Robert,
Yes, your're right. But this preprocessor macro is used only in one place of the whole boost, namely in serialization library.
LOL - that amazes me. I guess I'm just lucky.
What were the reasons to put load and save methods for collections to std namespace? This is a root of evil.
We may not define BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP for vc7.1, but simply put load and save to boost::serialization for vc7.1. I think, that code that you have removed, was intended exactly for this purposes, but were written with error. May be right decision would be not to remove the code, but instead accuratly rewrite it in order to place load and save in serialization namespace specailly for vc7.1.
Your analysis and understanding are correct on this. Here is how we came to be here. a) originally everything was in the boost::serialization namespace and the serialization library code specifically used the boost::serialization namespace. This required user specializations to be in the boost::serialization namespace as well. b) Some people complained but it was OK by me and I was resolved to defer adjustments to a future release (at that time release branching was scheduled for 28 July 2004 !!!). c) I ran tests with the codewarrior compiler 9.2 - everything using export bombed. It seems that this is the only compiler I used that implemented two-phase lookup. So specializations subsequent to the definiation of of the default one in the serialization header wouldn't be found. The implementation of export functionality required that headers be in a certain order so I couldn't easily fix this problem. d) the "fix" was to rely upon the fact that there are no compilers which implement two-phase lookup and do not implement ADL. So the requirement was imposed that specializations be part of the same name space of the data-type to be serialized for those compilers which implement it. e) the REAL fix is to re-implement the export functionality so it doesn't require the current header sequence. This would permit specializations to be in boost::serialization or, for compilers supporting ADL, in the same namespace as either the archive type or that of the type to be serialized. This fix is certainly not trivial. I briefly considered one idea but rejected for reasons I don't remember now. f) After implementing e) above, the serialization library would no longer depend upon BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP and I would be off that hook. I hope this answers your question. Its not that there's a reluctance to fix things, its just that by the time on considers all the reasons that things are the way they are, it isn't obvious how to fix something. Robert Ramey P.S. want to hear something funny? After going through all this codewarrior compiler doesn't build programs which use the serialization export functionality. This is due to a compiler feature which removes all code not explicitly referenced by name. That is, an overzealous optimization. Heroic efforts have failed to resolve this issue for this compiler. Arrrrrrrgggggggghhhhhhh.