THOMAS JORDAN
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 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 Joaquín M López Muñoz Telefónica