on Thu Sep 11 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
This specific concrete problems is that by replacing the functionality of a simple, well defined, understandable component with a very complex and elaborate one designed to address some other purpose now requires that one undertake a lot of new effort to verify what the new thing does, if it conflicts with the original reasons for selecting the component in the first place. All this takes a lot of time which I don't have. (We'll leave aside that apparently it depends on builds of other libraries for testing - which creates even more work).
I raise this concern when the problems first came up and these concerns where dismissed. The author fail to see my concerns and legitimate and so no problem with behavior.
Okay, Robert. Now your concerns have been taken seriously, and, I think, addressed. Is that correct, and if so, can we move on? If not, what is left to deal with?
This question has been raised why I put it into boost::serialization::throw_exception instead just using boost::throw_exception for the for user override. This is the decision which I believe is causing your grief. First of all, it's not clear to me anymore what boost::throw_exception should do - its not obvious that its equivalent to the old boost::throw_exception.
You won't take the word of Emil and Peter that it is?
But the truth is I didn't think about it. Last year I got a huge amount of grief for some things I had in the boot namespace and agreed to move them in to the serialzation directory and namespace. An example was BOOST_STATIC_WARNING and a couple of others. It just so happened that I was moving this stuff out of the boost namespace to the serialization namespace and it was convenient to do the same with throw_exception at the same time.
But throw_exception is not a similar case in any way. The things you were asked to move were *definitions* that were placed into namespace boost rather than into the serialization library. You didn't have a definition of throw_exception to move. Your change is analogous to making the switch from using boost::result_of to using your own private result_of template in Boost.Serialization. The result would be that existing code would stop working because your users had created necessary specializations of boost::result_of that would now not be used, just as now anyone's definition of boost::throw_exception will now not be used by the serialization library. -- Dave Abrahams BoostPro Computing http://www.boostpro.com