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

From: Andrey Melnikov (melnikov_at_[hidden])
Date: 2005-07-11 04:01:08

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.

I even had my own placeholder<> implementation. But I felt myself too 
weak to perform boost-style "all possible overloads", and lack of the 
safety prevented me from using that class widely.

I wonder how many more pearls are still hidden deeply in Boost 
documentation. I'm going to contribute to the documentation (at least in 
Wiki due to my poor English) when I finish with Boost.Build.

Andrey