Re: [Boost-users] sizeof(boost::fusion:map)

6 Nov 2010

      On Nov 6, 5:17 am, Christopher Schmidt 
wrote:
...
alfC schrieb:
...
On Nov 5, 9:49 pm, Joel de Guzman  wrote:
...
On 11/6/2010 7:56 AM, Christopher Schmidt wrote:
...
...
...
Christopher Schmidt schrieb:
...
Robert Lupton the Good schrieb:
...
I was very excited to find the boost::fusion library, expecting that I could use it to implement structs with introspection.  I still think I can, but I was disappointed to see that I'm paying a size penalty. I'd have expected all the book-keeping to be handled at compile time.
...
...
...
...
...
The following code prints
   sizeof(Foo) = 12 sizeof(FooS) = 4
with g++ 4.2 or 4.4 on an os/x 10.6 or Centos box.
...
...
...
...
...
Here Foo is
   boost::fusion::map  >
...
...
...
...
[snip]
...
...
...
...
I have no idea why there is that space overhead. This problem is not
fusion specific, though.
...
...
...
...
#include<iostream>
struct X{};
struct A:X{int i;};
struct B:X{A a;};
int main()
{std::cout<<  sizeof(A)<<  " "<<  sizeof(B)<<  std::endl;}
...
...
...
...
When compiled with gcc 4.5.1 i686-pc-mingw32 and -O2, the output is "4
8". When compiled with MSVC 2010 (x86) and /O2, "4 4" is printed.
...
...
...
...
-Christopher
...
...
...
I think gcc is correct. There are two distinct instances of X in B, and
those may not have the same address. That's why there is that 4 byte
displacement.
It is pretty much the same in Fusion. All inbuilt sequences and the
vector data storage share a common base class - fusion::sequence_root -
that's where the 4 resp. 8 bytes come from.
...
...
Good analysis, Christopher. We should do something about this.
sequence_root is only there for easy tag detection. There should
be better way.
...
Joel,
...
If I am not wrong: this is related to a question I asked some weeks
ago. When I was surprised (disappointed?) to find that
fusion::vector has a memory layout different
than double[3] (or boost::array). I didn't look at the
'sizeof' then but know that Robert mentions it I tried:
...
std::clog << sizeof(double) << std::endl;
std::clog << sizeof(vector) << std::endl;
std::clog << sizeof(boost::array) << std::endl;
...
which in my platform emits:
...
8
28
24
...
It would be interesting to know what does Boost.fusion stores in the
extra bytes and why on earth neither the size nor the memory layout is
the same as the contained data. It seems that the inconsistency on the
size raises more eyebrows than the unexpected memory layout.
Nothing is stored in those 4 additional bytes.
As I said above one additional byte is added by the compiler to the
3*sizeof(double) bytes so one is able to distinguish between the two
instances of a common base class (fusion::sequence_root) of the vector
(fusion::vector) and the internal vector data
storage (fusion::vector3). To get size and
alignment right this one byte actually emits a 4-byte overhead on your
compiler.
Isn't something called Empty Base Optimization that helps with this
problem? (not sure if it applies here).

So there is no way around it? (unless the internal design is changed?)

What do you mean by my compiler? are there compiler options that can
optimize these? (I use gcc 4.4)
...
-Christopher
_______________________________________________
Boost-users mailing list
Boost-us...@lists.boost.orghttp://lists.boost.org/mailman/listinfo.cgi/boost-users