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. -Christopher

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. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net

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. -Christopher

On 11/06/10 07:33, alfC wrote: [snip]

On Nov 6, 5:17 am, Christopher Schmidt wrote:

[snip]

...

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?) [snip] Not if the compiler conforms to the standard, AFAICT. However, apparently, according to the Christopher's earlier post:

http://article.gmane.org/gmane.comp.lib.boost.user/63553 MSVC 2010 (x86) believes avoiding this restriction has some advantage. There is a link in this post: http://groups.google.com/group/comp.lang.c++/msg/ab0c802f7b5e9072 to comp.lang.c++ which maybe explains more. That post also has a code attachment illustrating that EBO doesn't always work as one might expect(see the struct empties_inherit). The code attachment also shows a workaround using: https://svn.boost.org/trac/boost/browser/sandbox/variadic_templates/boost/co... HTH. -Larry

On 11/6/10 8:49 PM, Christopher Schmidt wrote:

Joel de Guzman schrieb:

...

On 11/6/2010 7:56 AM, Christopher Schmidt wrote: [snip]

...

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.

I committed a preliminary fix to the trunk. See

https://svn.boost.org/trac/boost/changeset/66411

for more details. It does not break Fusion and Proto on gcc 4.5.1 -std=c++0x, gcc 4.5.1, msvc 10, msvc 9 and gcc 3.4.2 .

I removed fusion::sequence_root and added an implicit conversion operator to fusion::sequence_base .

https://svn.boost.org/trac/boost/browser/trunk/boost/fusion/support/sequence...

Instead of using boost::is_base_of to detect inbuilt fusion container we can use boost::is_convertible now.

https://svn.boost.org/trac/boost/browser/trunk/boost/fusion/support/is_seque...

This solution is not pretty but it does not make the situation worse either.

Thanks, Christopher. That will do for now. I'm sure you can do better though ;-) Cheers, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net