Re: [boost] [ValueRef]

Subject: Re: [boost] [ValueRef]
From: THOMAS JORDAN (tomjordan766_at_[hidden])
Date: 2015-04-21 13:38:29

> 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

Ok

> > > 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

There is no compelling reason why I shouldn't use shared_ptr. The first
implementation I did of ValueRef was just a small modification to Adobe's
C++03 copy_on_write library, because I had already been playing with that
class, it was fairly quite simple and just involved: adding the forwarding
constructors; removing the dependencies on the other (Adobe and Boost)
libraries; changing the wrapped type to const T; removing the non-const
write() function. I operate in a fairly constrained environment, and I
generally like the idea of minimising dependencies, however, as you imply,
there is no point reinventing the wheel (for example shared_ptr/make_shared
would already provide most of the solution for the dual C++03/11 support
for forwarding constructors, etc.). Furthermore, I'd guess using shared_ptr
might help facilitate submission generally.

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

Tom