On 25.9.2015. 16:35, Andrzej Krzemienski wrote:
Hi Everyone, I would like to inquire if there would be an interest in Boost in another library for storing optional objects, but working under different design goals.
Compact optional T has (or can have) the same sizeof as T. It uses one indicated value of T to represent the "empty" (or "singular") value. You can declare it like this:
compact_optional<evp_int<int, -1>> oi; <...> It is not meant to be an alternative to Boost.Optional: it targets a different application space.
Hi Andrzej, +1 @ the improvement (as just one of the many improvements and 'polishes' long overdue for boost::optional) -1 @ making it a new/different class template If the improvement/change does not prevent providing the same interface and semantics as optional while offering same-or-better efficiency - then it's just simply better. IOW, I'm all for adding a new 'policies' template parameter (properly defaulted for backwards compatibility) to optional (or perhaps trait(s) classes instead of a new template parameter - w can debated that ;). The one-size-fits-all shared_ptr and make-every-one-pay-for-everything-no-matter-how-fat-it-is iostreams, filesystem, Qt,... logic is IMNHO so C#/Java like and so 'unworthy' of C++...so can we please remove that mentality from optional before it gets into the standard? As the discussions and (already implemented) proposals from a couple of years back show, eg.: http://lists.boost.org/Archives/boost/2012/01/189857.php http://lists.boost.org/Archives/boost/2009/10/156750.php there are many other possible and needed improvements for optional and it is not nearly all about memory efficiency. There are many codegen issues, for example if I work with floats that must never be NaN, I'd want to wrap them in optional<float, NeverNaNPolicy> _without_ the compiler suddenly adding braindead branching in my code and passing the never-nan-floats through the stack (instead of in registers like 'raw' floats). The approach with different class templates will actually cause uglier user code in the long run (as opposed to a relatively minor _one_time_ hurdle in only some projects that would be broken by a new defaulted parameter) - we'll end up with projects that use optional, pink_optional, compact_optional, smelly_optional and hal9000_optional... with someone having to track and document where and why each of those is used. In addition, the different class templates and/or explicit specializations approaches either require either: - duplication (of the shared optional interface and functionality that optional-like classes must have) - a private base/impl class w/ policies which the public 'different class templates' and/or 'explicit optional specializations' can reuse. If duplication is 'almost always evil', 'all I'm saying' is make the 'private base/impl class w/ policies' the public boost/std::optional proper... C++ >In The Kernel< Now! -- Domagoj Saric Software Architect www.LittleEndian.com