Boost logo

Boost :

Subject: Re: [boost] [ValueRef]
From: THOMAS JORDAN (tomjordan766_at_[hidden])
Date: 2015-04-22 09:51:21


> Message: 7
> Date: Tue, 21 Apr 2015 15:37:56 +0000 (UTC)
> From: Joaquin M Lopez Munoz <joaquin_at_[hidden]>
> To: boost_at_[hidden]
> Subject: Re: [boost] [ValueRef]
> Message-ID: <loom.20150421T164358-569_at_[hidden]>
> Content-Type: text/plain; charset=utf-8

> THOMAS JORDAN <tomjordan766 <at> gmail.com> writes:

> >
> > > Message: 7
> > > Date: Mon, 20 Apr 2015 18:39:57 +0000 (UTC)
> > > From: Joaquin M Lopez Munoz <joaquin <at> tid.es>
> >
> > > Boost.Flyweight uses move semantics and perfect fwd ction where
> > > available,
> > > I don't see how another solution can do better on this front
> >
> > Agreed, I'll withdraw that statement. However, as I said in the O.P.,
the
> > ValueRef implementation I have done is currently only C++03. It uses a
> > combination of N x forwarding constructor overloads taking arguments by
> > const reference, and the client can use reference wrappers to forward to
> > lvaluesto do the non-perfect forwarding (as boost.shared_ptr
make_shared
> > does) . The intention in the final library would be to support
> > C++11/perfect forwarding and possibly Boost.Move for C++03 move
semantics.
> > So they would be equivalent in that regard.

> Understood. Boost.Flyweight does in fact this something similar,
> you might want to take inspiration from

> http://boost.org/boost/flyweight/detail/perfect_fwd.hpp

> > > Boost.Flyweight is indeed heavier on the include side than some
> > > people might be comfortable with.
> >
> > I think this is my concern with having Boost Flyweight as the only
option
> > for what is a relatively simple type. ValueRef is currently about 350
> > lines of easy-to-understand code in a single header file, and has no
> > dependencies on MPL or any other Boost or std libraries, with the
> > exception of an atomic library.
> > It is intended in particular as a lightweight, clean replacement for
> > shared-ptr-to-const, which I see used a lot in code [...]

> Of course I don't want to disregard the merit of a lightweight approach
> to implementing this idiom. I'm curious: why are you implementing
> this from scracth, using atomic etc. rather than wrapping
> boost::shared_ptr? The latter, seems to me, is going to be much less
> code on your side and the dependencies on the lib are not that many:

> http://www.pdimov.com/tmp/report-b1adfee/smart_ptr.html

I was inaccurate when I said that ValueRef did not depend on any std
libraries, in fact it depends on <memory> for std::allocator<T>.

I've modified it to use boost::shared_ptr and boost::allocate_shared
(though still just with C++03 forwarding constructors at the moment) - it
was trivial, and reduces the LOCS by ~half.

> Joaqu?n M L?pez Mu?oz
> Telef?nica

Tom


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk