
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.
IMO it doesn't matter much how ugly the portable-to-broken-compilers workaround is, as long as it's legit for the conforming ones and doesn't induce maintenance problems.
So do you have anything to say about this?
I hate to be a pest, but I've sunk so much time into getting these issues remedied that I'm unwilling to have the issue evaporate into the past without getting addressed.
Here is what I'm doing. a) I've updated the tutorial and tweaked the explanation of derived pointers to highlight the issue more. b) I'm going to remove the class declaration and function implementation from the Archive Concept part of the document. 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. 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. e) I'm intrigued with Joaquin's suggestion regarding formal documentation of Archive and Serializable Concepts but this can and will be defered. f) I would like to revisit the Archive Implementation section at my leisure in light of this discussion. Thsi section describes how the included archve classes are implemented. There is a separate interface class which uses CRTP which conceptually dovetails with the Archive Concept as decribed above. Other issues I would like to spend time on if I had it. g) Makding a demo/test for a DLL type plugin using the polymorphic archive. This would be lightweight COM. h) Making a demo/test that generates a table of timings on all the boost platforms in order to answer questions like how much overhead does using an archive vs standard i/o. Does the compiler really optimize inline functiions to hte max, etc. So that's how it stands now. Robert Ramey