On 09/28/2015 08:45 PM, Gonzalo BG wrote:
Vladimir Batov wrote:
... if I cannot provide "int", I should not be saying that I do.
Using the library the best thing that I can say is that I'm providing a "compact_optional<int, some_policy, struct this_is_my_temperature_type_tag> ".
Indeed. Now I realize that "compact_optional<>" introduces a new distinct type. So, my initial concern was unfounded. More so, your example of vector<optional<int>> (with ~O(10^10) elements) seems to be a convincing use-case for such a type.
Vladimir Batov wrote:
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.
I use compact_optional to store data on disk and since sizeof(compact_optional<T>) == sizeof(T) I haven't ran into issues yet. How can one be more economical than that?
I had different economy in mind as I am forced to squeeze something represented, say, as "int" in memory into int16_t or int8_t and the likes to be stored on disk.