Boost logo

Boost :

Subject: Re: [boost] compact_optional -- prompting interest
From: work (Vladimir.Batov_at_[hidden])
Date: 2015-09-25 18:45:35


On 2015-09-26 00:35, Andrzej Krzemienski wrote:
> 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.
> ... It uses one
> indicated value of T to represent the "empty" (or "singular") value.

In other words, your proposed design is intrusive as it carves something
from T for its own purposes.

1) IMO non-intrusive design is by far preferred even if it comes with
extra-cost (shared_ptr might serve as an example). It's not to say
intrusive design has no place. It does... but seems niche as opposed to
a generic solution... which Boost seems to be positioning itself (IMO).

2) Obviously that technique has been used for a long time and it's not
immediately obvious to me if the extra interface adds much real value or
most importantly clarity/safety. To me having allocated -1 or
std::max<int> (or whatever) to represent no-value, i.e. "no-int" feels
hackish. If, as a developer, I advertise "int" to the user, IMO the user
is entitled to expect the full "int" range available. If, as a
developer, I do not provide the full range, the proper way (IMO) would
be to introduce a new explicit type to represent the supported subset
(via enum or proper sensibly-named type -- time, speed, temperature,
etc.) In other words, if I cannot provide "int", I should not be saying
that I do.

3) I am trying to see if compact_optional might fit in my projects and
fail. When in memory, I by far prefer boost::optional for its
orthogonality -- it adds functionality without taking anything from T.

I do have the need to be real frugal when I store data to the disk. But
for that purpose I have to be far more economical and size-specific than

> ...
> It is not meant to be an alternative to Boost.Optional: it targets a
> different application space.

I am not sure I immediately agree with you positioning your proposed
"compact_optional" as no competitor to the established "optional". After
all, your proposed "compact_optional" tries to address the same problem
of representing no-value. You even call it similarly. Surely, it for a

Having said that I can easily be wrong and I am prepared to be convinced


Boost list run by bdawes at, gregod at, cpdaniel at, john at