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://listarchives.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."