Re: 3 byte variables [feature request]

[Anthony Foiani <tkil at scrye dot com>]

Miles Bader <miles@gnu.org> writes:

> If you're using C++ and are willing to use gcc (and clang) extensions,
> you can do a bit better, e.g.:
>
>    class __attribute__((packed)) int24_t
>    {
>    public:
>      operator int () const { return b; }
>      int24_t (int v) : b (v) {}
>      int24_t () {}
>    private:
>      int b : 24;
>    };
>
> Then an array like "int24_t a[1000]" will only take 3000 bytes, and
> you can kinda/sorta mix int24_t types with integers...

If I recall correctly, at least one of the possible Boost.Endian
libraries supported some oddball sizes such as this.  (The theory
being that doing binary I/O would be the most likely place that one
would encounter such beasties).

Ah, this one:

    http://boost.cowic.de/rc/endian/doc/

Not formally a part of Boost (at least not as of 1.53.0, no idea what
the current status is).

But it's written by one of the most central Boost folks, so (1) it
ought to be pretty good quality to begin with, and (2) it should
interop nicely with both Boost and the standard C++ library.

Its support of oddball sizes is described at:

    http://boost.cowic.de/rc/endian/doc/integers.html

>From the Introduction:

    Header <boost/endian/integers.hpp> provides integer-like
    byte-holder binary types with explicit control over byte order,
    value type, size, and alignment. Typedefs provide easy-to-use
    names for common configurations.

    These types provide portable byte-holders for integer data,
    independent of particular computer architectures. Use cases almost
    always involve I/O, either via files or network connections.
    Although data portability is the primary motivation, these integer
    byte-holders may also be used to reduce memory use, file size, or
    network activity since they provide binary integer sizes not
    otherwise available.

> Of course the generated code is not so efficient, so don't use such
> types in inner loops if you can help it!

Indeed.

Best regards,
Anthony Foiani