"Robert Ramey" <ramey@rrsd.com> writes:
David Abrahams wrote:
David Abrahams <dave@boost-consulting.com> writes:
"Robert Ramey" <ramey@rrsd.com> writes:
That sounds like what I did for version 1.32.
Is it equivalent to what you did, or does it just sound reminiscent?
I considered a very ugly hack. ^ "it?"
I don't think I was the only person that felt this way. I resolved to fix it in the next version - and here we are. oh well.
Surely you don't think the recommendation I'm suggesting for conforming compilers is an ugly hack?
LOL - I said I considered my first incarnation in 1.32 and ugly hack. I haven't studied your suggestion in enough detail to definitively characterise it as an ugly hack. But it IS ugly.
FCOL, does this have to be so difficult? Are you sure you want to call the recommendation I'm suggesting for conforming compilers ugly? Let me remind you, that was: The best thing you could do, IMO, is write a recommendation that works on conforming compilers, e.g. Overload serialize in the namespace of your class.
Here is what I'm doing.
a) I've updated the tutorial and tweaked the explanation of derived pointers to highlight the issue more.
Thanks.
b) I'm going to remove the class declaration and function implementation from the Archive Concept part of the document.
Are you planning to replace it with anything? It would be pretty silly to have a section called Archive Concept with no concept description.
The above I will check into RC_1_33_0
Other issues that I intend to defer for the next version
c) investigate the ar.template register_type<T>() vs ar.register_type(static_cast<T*>(NULL) workaround. I did spend some time coming up with this workaround and it has worked find and now its used by user code so changing this per your suggestion (assuming it would actually work) would have to be considered. It also takes a lot a time to verify that it works or doesn't on all the compilers.
I don't really care deeply about this one, FWIW.
d) investicate the two-phase lookup issue. There is no way any such change could be made for RC_1_33_0 and the next boost release won't be for another 10? months, so I feel that I can take some time with this.
That seems extreme to me. Surely for RC_1_33_0 a documentation fix that provides instructions that are both correct for conforming compilers and consistent with the current library implementation is possible? Not much more than a small tweak in emphasis would be required.
e) I'm intrigued with Joaquin's suggestion regarding formal documentation of Archive and Serializable Concepts but this can and will be defered.
Understandable; that will take some considerable time to analyze. -- Dave Abrahams Boost Consulting www.boost-consulting.com