Subject: Re: [boost] compact_optional -- prompting interest
From: Domagoj Saric (domagoj.saric_at_[hidden])
Date: 2015-10-01 06:13:11
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
> 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.
+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
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.:
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk