Re: [boost] Hello?

From: David Abrahams (dave_at_[hidden])
Date: 2005-09-14 15:31:39

"Robert Ramey" <ramey_at_[hidden]> writes:

> David Abrahams wrote:
>> David Abrahams <dave_at_[hidden]> writes:
>>
>>> "Robert Ramey" <ramey_at_[hidden]> 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