Subject: Re: [boost] compact_optional -- prompting interest
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-09-25 11:37:10
On 25.09.2015 17: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;
> This reads: we have an optional int, with type int inside, where -1
> represents the empty value. It can never have a genuine (non-empty value
> -1). This can be used, for instance, to wrap the std::string::npos into:
> compact_optional<evp_int<string::size_type, string::npos>>
> With the same memory layout as std::string::size_type, but with the special
> syntax for managing the singular value.
> It is not meant to be an alternative to Boost.Optional: it targets a
> different application space.
The idea looks interesting - I sometimes have to deal with magic values.
Currently I prefer to wrap the object into optional<> or at least make
the special value not so magic (i.e. so that the code always does the
right thing without checking for the magic value).
However, I'm not sure I agree with your rationale on the reduced
interface and possibly the compact_optional naming.
1. You chose not to provide relational operators for compact_optional
because you don't know how to order 'empty' values. I think you don't
have to make that decision and simply forward the call to the underlying
type. I mean, you always have the stored object constructed in some
state and as long as it implements operators you can always use them.
2. compact_optional does not provide direct assignment of the values of
the stored type, requiring to manually construct a
compact_optional-wrapped value. To me, this is too cumbersome to use
while I don't see any wins from this restriction. Besides more typing,
this essentially requires to use a typedef to declare and use the
3. Nitpick: the typical name for the getter operation is get(), not
value(). I would also have used empty() to test for the magic value but
maybe that makes you feel it like a container.
4. Regarding compact_optional naming. While the class can be used for
similar purpose as optional, its interface and behavior are
significantly different. Perhaps a different name would be better to
avoid confusion (e.g. nullable<>).
5. A suggestion: add evp_zero and evp_empty policies. The first uses
literal zero as the special value and can be used with numeric (integer
and fp) and pointer types. The second uses a default constructed value
as the magic value and a member empty() function to test for magic
value. This could be useful with containers, strings and ranges.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk