2015-09-26 0:45 GMT+02:00 work
Andrzej,
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.
Indeed, I have also considered name "intrusive_optional".
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).
Indeed; also compact_optional library comes with the advice that you should try boost::optional first, and only if you have performance problems with it, should you try to use compact_optional instead.
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.
Ok, I think I see where you are coming from. This is an interesting topic in itself; but for now I only stick to advertising compact_optional. Using the words from your description above, when you have decided to use the hack with "magic value", you can use compact_optional to make this explicit and visible to the type-system: now "int" and "int with magic value" are never confused.
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.
And more: boost::optional does not force you to take the time and consider and declare how you want to store the no-value.
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 compact_optional.
Indeed. We could say that compact_optional gives you a "generic optimization": it is a fairly generic and mechanical optimization over boost::optional, but to maximally optimize your particular case, you need to do it manually.
...
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 reason.
If not anything else, this often came out as an extension request to boost::optional and std::experimental::optional. My idea of the two libraries is this: When you design a new data structure, you just use boost::optional to represent optional values. Whet it never causes performance issues, you leave it at that. Another situation is where you already encode a magic value in your type int, you consider changing it to boost::optional, but are concerned about adding potential run-time overhead. Your concerns may be misplaced, but only having a concern (valid or not) is often enough to reject a safer library solution (boost::optional). compact_optional does not give you this concerns: it gives you a different trade-off between type-safety and "performance concerns".
Having said that I can easily be wrong and I am prepared to be convinced otherwise.
V.
Reards, &rzej