Re: [boost] Lack of good brief descriptions is a marketing issue

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2005-07-11 12:18:03

"Felipe Magno de Almeida" <felipe.m.almeida_at_[hidden]> escribió en el 
mensaje news:a2b17b6050711023823971693_at_mail.gmail.com...
> On 7/11/05, Andrey Melnikov <melnikov_at_[hidden]> wrote:
>> David Abrahams wrote:
>> > "Jost, Andrew" <Andrew_Jost_at_[hidden]> writes:
>> >
>> >
>> >>>From: boost-bounces_at_[hidden]
>> >>
>> >>[mailto:boost-bounces_at_[hidden]] On Behalf Of Eelis van der 
>> >>Weegen
>> >>
>> >>
>> >>>Jost, Andrew wrote:
>> >>>
>> >>>>I am curious if there is support for what I'm calling a "dual_state"
>> >>>>template class.
>> >>>
>> >>>From your description it sounds a lot like Boost.Optional. What are
>> >>
>> >>the main differences?
>> >>
>> >>>Eelis
>> >>
>> >>I'll admit I did not even pause at Boost.optional when I scanned the
>> >>library listing for previous work, a failure in my ability to connect
>> >>the description, "Discriminated-union wrapper for optional values," 
>> >>with
>> >>the concept I had in mind.
>> >
>> >
>> > Oh, you're right!  That is a terrible one-line description, because
>> >
>> >   a. It uses technical terms that many people probably don't know
>> >      "discriminated union"
>> >
>> >   b. optional doesn't really act like a union (in any way that matches
>> >      my intuition)!  I understand the theoretical connection, of
>> >      course, but nobody is thinking that way when they read brief
>> >      descriptions.
>> >
>> Well, even despite I do understand what "discriminated union" is, it's
>> more an implementation detail than a brief descripton of practical
>> applications for the library.
>>
>> I found Boost.Optional very useful for myself.
>>
>> http://www.boost.org/libs/optional/doc/optional.html#inplace describes a
>> usage scenario which has almost nothing to do with optionality.
>>
>> With boost::optional in-place construction facilities I can easily store
>> non-Copyable or non-DefaultConstructible objects in STL containers and
>> avoid extra construction, copy and dynamic memory allocation operations
>> in many scenarios, even in those not related to containers. For example,
>> I can return a fresh NonCopyable and NonDefaultConstructible object from
>> a function without often expensive heap operations.
>
> Isnt that the boost::ref goal? Or am I missing something?
>
No it isn't... and becasue your're asking, is evident that the
documentation for this is still inadequate.

Fernando Cacciola
SciSoft