Message: 7 Date: Tue, 21 Apr 2015 15:37:56 +0000 (UTC) From: Joaquin M Lopez Munoz To: boost@lists.boost.org Subject: Re: [boost] [ValueRef] Message-ID: Content-Type: text/plain; charset=utf-8

THOMAS JORDAN writes:

...

...

Message: 7 Date: Mon, 20 Apr 2015 18:39:57 +0000 (UTC) From: Joaquin M Lopez Munoz

...

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

Ok 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