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

From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2005-07-11 04:38:57

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?

> 
> 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
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> 

-- 
   Felipe Magno de Almeida
Developer from synergy and Computer Science student from State
University of Campinas(UNICAMP).
Unicamp: http://www.ic.unicamp.br
Synergy: http://www.synergy.com.br
"There is no dark side of the moon really. Matter of fact it's all dark."