|
Boost : |
Subject: Re: [boost] How do I specify no padding bytes within a struct/class?
From: Daryle Walker (darylew_at_[hidden])
Date: 2013-06-17 17:30:28
> Date: Mon, 17 Jun 2013 20:16:49 +0100
> From: e_float_at_[hidden]
>
> >I've never done this before, so I'm asking first: how do I specify that a
> >struct/class should have no padding at all, at the start, end, or middle?
> >Daryle W.
>
> Microsoft compilers have a pragma pack for this at source
> level. The pragma pack needs to be applied individually to
> each structure.
>
> There are also Microsoft-specific compiler flags that can be
> used project-globally for this. But I forgot the names of
> those flags.
>
> It's going down a tough road, though, because of potential
> portability issues.
I'm just going to have a (huge) #if/#elsif/#else chain with every compiler I can get support on.
> Pretty much every embedded microcontroller system I have
> used has some kind of structure packing facility.
>
> If you don't mind, why do you want to do pack structs in the
> first place? Most people cringe at the thought of packing-specific
> code.
I've read about using an array segment of complex numbers as an array of real numbers (but twice as long) for stuff like Fourier transforms. At http://en.cppreference.com/w/cpp/numeric/complex#Non-static_data_members, the effect is documented for std::complex (at least for float/double/long-double). I want to simulate the effect.
template < typename T, unsigned R >
struct complex_it {
T c[ 1ULL << R ];
};
The above class template will be standard-layout if "T" is; that mandates no starting padding. Array elements are packed. So I can do the array-segment translation only if there's no trailing padding. In contrast:
template < typename T, unsigned R > struct complex_rt;
template < typename T >
struct complex_rt<T, 0u> { T r; };
template < typename T, unsigned R >
struct complex_rt { complex_rt<T, R - 1u> b[2]; };
will have padding all over the place if there's any trailing padding at a lower level.
Daryle W.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk