<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: S-expressions and variant</title>
	<atom:link href="http://boost-spirit.com/home/2010/03/11/s-expressions-and-variants/feed/" rel="self" type="application/rss+xml" />
	<link>http://boost-spirit.com/home/2010/03/11/s-expressions-and-variants/?utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=s-expressions-and-variants</link>
	<description>Home of The Boost.Spirit Library</description>
	<lastBuildDate>Sat, 28 Aug 2010 10:48:22 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: Joel de Guzman</title>
		<link>http://boost-spirit.com/home/2010/03/11/s-expressions-and-variants/comment-page-1/#comment-2729</link>
		<dc:creator>Joel de Guzman</dc:creator>
		<pubDate>Sun, 04 Apr 2010 03:56:08 +0000</pubDate>
		<guid isPermaLink="false">http://boost-spirit.com/home/?p=1039#comment-2729</guid>
		<description>Done :-)</description>
		<content:encoded><![CDATA[<p>Done <img src='http://boost-spirit.com/home/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joel de Guzman</title>
		<link>http://boost-spirit.com/home/2010/03/11/s-expressions-and-variants/comment-page-1/#comment-2320</link>
		<dc:creator>Joel de Guzman</dc:creator>
		<pubDate>Sat, 13 Mar 2010 00:36:57 +0000</pubDate>
		<guid isPermaLink="false">http://boost-spirit.com/home/?p=1039#comment-2320</guid>
		<description>Yes, Larry, that is correct. 12 bytes alignment is quite odd though. 64 bit machines I am aware of typically aligns to 8 bytes (64 bits). Correct me if I&#039;m wrong. Anyway, the point really is to make use of the padding bits and optimize the packing of the data.</description>
		<content:encoded><![CDATA[<p>Yes, Larry, that is correct. 12 bytes alignment is quite odd though. 64 bit machines I am aware of typically aligns to 8 bytes (64 bits). Correct me if I&#8217;m wrong. Anyway, the point really is to make use of the padding bits and optimize the packing of the data.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Larry Evans</title>
		<link>http://boost-spirit.com/home/2010/03/11/s-expressions-and-variants/comment-page-1/#comment-2316</link>
		<dc:creator>Larry Evans</dc:creator>
		<pubDate>Fri, 12 Mar 2010 17:27:53 +0000</pubDate>
		<guid isPermaLink="false">http://boost-spirit.com/home/?p=1039#comment-2316</guid>
		<description>The reason for this:

  Thus if you have a type in there that aligns to 12 bytes, variant
  requires another 12 bytes just for the type discriminator!

is to preserve the 12 byte alignment for the oddly aligned type when the
variant is put into an array.  By storing the type discriminant in the
1st 12 bytes of the containing structure, then when the containing structure
is put into a 2 element array, the 2nd array element will have the properly
aligned oddly aligned type.  Now I suppose you could avoid this restriction
if you&#039;re sure never to put utree into an array.</description>
		<content:encoded><![CDATA[<p>The reason for this:</p>
<p>  Thus if you have a type in there that aligns to 12 bytes, variant<br />
  requires another 12 bytes just for the type discriminator!</p>
<p>is to preserve the 12 byte alignment for the oddly aligned type when the<br />
variant is put into an array.  By storing the type discriminant in the<br />
1st 12 bytes of the containing structure, then when the containing structure<br />
is put into a 2 element array, the 2nd array element will have the properly<br />
aligned oddly aligned type.  Now I suppose you could avoid this restriction<br />
if you&#8217;re sure never to put utree into an array.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joel de Guzman</title>
		<link>http://boost-spirit.com/home/2010/03/11/s-expressions-and-variants/comment-page-1/#comment-2314</link>
		<dc:creator>Joel de Guzman</dc:creator>
		<pubDate>Fri, 12 Mar 2010 08:55:41 +0000</pubDate>
		<guid isPermaLink="false">http://boost-spirit.com/home/?p=1039#comment-2314</guid>
		<description>Definitely. It&#039;s an STL container. You can also do unary and binary visitation like you do with variant, allowing you to traverse the tree any way you want.</description>
		<content:encoded><![CDATA[<p>Definitely. It&#8217;s an STL container. You can also do unary and binary visitation like you do with variant, allowing you to traverse the tree any way you want.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dainis</title>
		<link>http://boost-spirit.com/home/2010/03/11/s-expressions-and-variants/comment-page-1/#comment-2313</link>
		<dc:creator>Dainis</dc:creator>
		<pubDate>Fri, 12 Mar 2010 05:36:24 +0000</pubDate>
		<guid isPermaLink="false">http://boost-spirit.com/home/?p=1039#comment-2313</guid>
		<description>Sometimes for tree is needed some function on its all elements .
For u-tree its possible to doo for_each?</description>
		<content:encoded><![CDATA[<p>Sometimes for tree is needed some function on its all elements .<br />
For u-tree its possible to doo for_each?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joel de Guzman</title>
		<link>http://boost-spirit.com/home/2010/03/11/s-expressions-and-variants/comment-page-1/#comment-2311</link>
		<dc:creator>Joel de Guzman</dc:creator>
		<pubDate>Fri, 12 Mar 2010 03:34:59 +0000</pubDate>
		<guid isPermaLink="false">http://boost-spirit.com/home/?p=1039#comment-2311</guid>
		<description>Yep. You can&#039;t get away with the extra padding. In my case, I just store the discriminant (intrusively) in the largest union type in a place where it can not be overwritten by other inhabitants of the union. That is a caveat. I place this at the right/bottom-most of the largest struct but there can be some obscure OS where some weird alignment can place data such that this is overwritten. This can be tested at compile time though. For a generic variant, one can perhaps use the same trick by having an array of chars with 1+ the largest struct and place the discriminator there at the extra byte.</description>
		<content:encoded><![CDATA[<p>Yep. You can&#8217;t get away with the extra padding. In my case, I just store the discriminant (intrusively) in the largest union type in a place where it can not be overwritten by other inhabitants of the union. That is a caveat. I place this at the right/bottom-most of the largest struct but there can be some obscure OS where some weird alignment can place data such that this is overwritten. This can be tested at compile time though. For a generic variant, one can perhaps use the same trick by having an array of chars with 1+ the largest struct and place the discriminator there at the extra byte.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Larry Evans</title>
		<link>http://boost-spirit.com/home/2010/03/11/s-expressions-and-variants/comment-page-1/#comment-2309</link>
		<dc:creator>Larry Evans</dc:creator>
		<pubDate>Fri, 12 Mar 2010 03:04:24 +0000</pubDate>
		<guid isPermaLink="false">http://boost-spirit.com/home/?p=1039#comment-2309</guid>
		<description>I tried using a union with a discriminant inside a struct.  I get the same
size of for composite_tagged_seq:

IOW, the following code:

[cpp]
#include 
#include 
#include 

#include 

struct x { void* a; void* b; void* c; };

struct x_union
{
      union
      { x u_x
      ; int u_int
      ; double u_dbl
      ;}
    storage
    ;
      char
    tag
    ;
};
struct x_oneof
: boost::composite_tagged_seq
  &lt; boost::composite_tags::one_of_maybe
  , boost::mpl::integral_c
  , boost::mpl::list
    
  &gt;
{
};

int main(void)
{
    std::cout&lt;&lt;&quot;sizeof(x)=&quot;&lt;&lt;sizeof(x)&lt;&lt;&quot;\n&quot;;
    std::cout&lt;&lt;&quot;sizeof(x_union)=&quot;&lt;&lt;sizeof(x_union)&lt;&lt;&quot;\n&quot;;
    std::cout&lt;&lt;&quot;sizeof(x_oneof)=&quot;&lt;&lt;sizeof(x_oneof)&lt;&lt;&quot;\n&quot;;
    return 0;
}    
[/cpp]

produces:

sizeof(x)=24
sizeof(x_union)=32
sizeof(x_oneof)=32
</description>
		<content:encoded><![CDATA[<p>I tried using a union with a discriminant inside a struct.  I get the same<br />
size of for composite_tagged_seq:</p>
<p>IOW, the following code:</p>
<pre class="brush: cpp;">
#include
#include
#include 

#include 

struct x { void* a; void* b; void* c; };

struct x_union
{
      union
      { x u_x
      ; int u_int
      ; double u_dbl
      ;}
    storage
    ;
      char
    tag
    ;
};
struct x_oneof
: boost::composite_tagged_seq
  &lt; boost::composite_tags::one_of_maybe
  , boost::mpl::integral_c
  , boost::mpl::list

  &gt;
{
};

int main(void)
{
    std::cout&lt;&lt;&quot;sizeof(x)=&quot;&lt;&lt;sizeof(x)&lt;&lt;&quot;\n&quot;;
    std::cout&lt;&lt;&quot;sizeof(x_union)=&quot;&lt;&lt;sizeof(x_union)&lt;&lt;&quot;\n&quot;;
    std::cout&lt;&lt;&quot;sizeof(x_oneof)=&quot;&lt;&lt;sizeof(x_oneof)&lt;&lt;&quot;\n&quot;;
    return 0;
}
</pre>
<p>produces:</p>
<p>sizeof(x)=24<br />
sizeof(x_union)=32<br />
sizeof(x_oneof)=32</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joel de Guzman</title>
		<link>http://boost-spirit.com/home/2010/03/11/s-expressions-and-variants/comment-page-1/#comment-2308</link>
		<dc:creator>Joel de Guzman</dc:creator>
		<pubDate>Fri, 12 Mar 2010 02:59:58 +0000</pubDate>
		<guid isPermaLink="false">http://boost-spirit.com/home/?p=1039#comment-2308</guid>
		<description>I did nothing special. I just stole one byte from the fast_string (the string that places its data in-situ) for the discriminator. Check out the implementation of fast_string:

http://boost-spirit.com/dl_more/scheme/scheme_v0.1/detail/utree_detail1.hpp</description>
		<content:encoded><![CDATA[<p>I did nothing special. I just stole one byte from the fast_string (the string that places its data in-situ) for the discriminator. Check out the implementation of fast_string:</p>
<p><a href="http://boost-spirit.com/dl_more/scheme/scheme_v0.1/detail/utree_detail1.hpp" rel="nofollow">http://boost-spirit.com/dl_more/scheme/scheme_v0.1/detail/utree_detail1.hpp</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Larry Evans</title>
		<link>http://boost-spirit.com/home/2010/03/11/s-expressions-and-variants/comment-page-1/#comment-2307</link>
		<dc:creator>Larry Evans</dc:creator>
		<pubDate>Fri, 12 Mar 2010 02:55:32 +0000</pubDate>
		<guid isPermaLink="false">http://boost-spirit.com/home/?p=1039#comment-2307</guid>
		<description>OK, but now I can&#039;t figure how you store the discriminant inside the
padding at the end of your union of POD&#039;s without somehow
misaligning the discriminant.  I guess just saying I wonder why
the compiler writers couldn&#039;t figure how to do this most efficiently.
Do you know of some language rules which require this wasted 
space?</description>
		<content:encoded><![CDATA[<p>OK, but now I can&#8217;t figure how you store the discriminant inside the<br />
padding at the end of your union of POD&#8217;s without somehow<br />
misaligning the discriminant.  I guess just saying I wonder why<br />
the compiler writers couldn&#8217;t figure how to do this most efficiently.<br />
Do you know of some language rules which require this wasted<br />
space?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joel de Guzman</title>
		<link>http://boost-spirit.com/home/2010/03/11/s-expressions-and-variants/comment-page-1/#comment-2306</link>
		<dc:creator>Joel de Guzman</dc:creator>
		<pubDate>Fri, 12 Mar 2010 02:41:15 +0000</pubDate>
		<guid isPermaLink="false">http://boost-spirit.com/home/?p=1039#comment-2306</guid>
		<description>Nope. I don&#039;t think so. The padding will be the same either way. Try it out.</description>
		<content:encoded><![CDATA[<p>Nope. I don&#8217;t think so. The padding will be the same either way. Try it out.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
