<?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 for Digital Fanatics</title>
	<atom:link href="http://www.digitalfanatics.org/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.digitalfanatics.org</link>
	<description>News, Guides and Tips for Your Digital Needs</description>
	<lastBuildDate>Mon, 24 Oct 2011 16:34:53 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>Comment on Data Alignment by Mattias Sjösvärd</title>
		<link>http://www.digitalfanatics.org/2011/10/data-alignment/#comment-282</link>
		<dc:creator>Mattias Sjösvärd</dc:creator>
		<pubDate>Mon, 24 Oct 2011 16:34:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.digitalfanatics.org/?p=389#comment-282</guid>
		<description>Sorry for late reply, I revisited this place just now!
A POD struct in C++ is likely to be the same layout unless you use different visibility on the struct members. In that case the compiler is allowed to not use the &quot;increasing address&quot;-scheme.
Regarding optimization, it depends upon if you favour space or speed. Speed is likely to follow hardware alignment, space not necessarily so. And the default space vs speed strategy is of course up to the compiler.</description>
		<content:encoded><![CDATA[<p>Sorry for late reply, I revisited this place just now!<br />
A POD struct in C++ is likely to be the same layout unless you use different visibility on the struct members. In that case the compiler is allowed to not use the &#8220;increasing address&#8221;-scheme.<br />
Regarding optimization, it depends upon if you favour space or speed. Speed is likely to follow hardware alignment, space not necessarily so. And the default space vs speed strategy is of course up to the compiler.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Data Alignment by e8johan</title>
		<link>http://www.digitalfanatics.org/2011/10/data-alignment/#comment-266</link>
		<dc:creator>e8johan</dc:creator>
		<pubDate>Fri, 21 Oct 2011 11:57:11 +0000</pubDate>
		<guid isPermaLink="false">http://www.digitalfanatics.org/?p=389#comment-266</guid>
		<description>En array bygger ju alltid på sizeof, så det blir ju inte lika ointuitivt iaf. Men, ja, i vissa lägen kan det ju vara nödvändigt. Har du koll på vid vilka tillfällen GCC gör detta? Även om standarden ger utrymme för detta, är det något som faktiskt görs?</description>
		<content:encoded><![CDATA[<p>En array bygger ju alltid på sizeof, så det blir ju inte lika ointuitivt iaf. Men, ja, i vissa lägen kan det ju vara nödvändigt. Har du koll på vid vilka tillfällen GCC gör detta? Även om standarden ger utrymme för detta, är det något som faktiskt görs?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Data Alignment by Henrik O</title>
		<link>http://www.digitalfanatics.org/2011/10/data-alignment/#comment-265</link>
		<dc:creator>Henrik O</dc:creator>
		<pubDate>Fri, 21 Oct 2011 11:53:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.digitalfanatics.org/?p=389#comment-265</guid>
		<description>Om du sen lägger in structen i en array så får du ytterligare en aspekt av data aligned. 
/Henrik</description>
		<content:encoded><![CDATA[<p>Om du sen lägger in structen i en array så får du ytterligare en aspekt av data aligned.<br />
/Henrik</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Data Alignment by e8johan</title>
		<link>http://www.digitalfanatics.org/2011/10/data-alignment/#comment-264</link>
		<dc:creator>e8johan</dc:creator>
		<pubDate>Fri, 21 Oct 2011 08:25:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.digitalfanatics.org/?p=389#comment-264</guid>
		<description>Ok, it does not depend directly on the CPU, it the compiler that does the laying out, *but* it does so in order to optimize the usage for the targetted CPU, hence, I feel that it is sort of right to write that it depends on the CPU.

Regarding the differences. Could you please elaborate. My experience is that POD-structs in C++ more or less are equivalent to C structs. But, the C++ compiler is not the same as the C compiler, so no guarantees, I guess :-)</description>
		<content:encoded><![CDATA[<p>Ok, it does not depend directly on the CPU, it the compiler that does the laying out, *but* it does so in order to optimize the usage for the targetted CPU, hence, I feel that it is sort of right to write that it depends on the CPU.</p>
<p>Regarding the differences. Could you please elaborate. My experience is that POD-structs in C++ more or less are equivalent to C structs. But, the C++ compiler is not the same as the C compiler, so no guarantees, I guess :-)</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Data Alignment by Mattias Sjösvärd</title>
		<link>http://www.digitalfanatics.org/2011/10/data-alignment/#comment-263</link>
		<dc:creator>Mattias Sjösvärd</dc:creator>
		<pubDate>Fri, 21 Oct 2011 07:22:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.digitalfanatics.org/?p=389#comment-263</guid>
		<description>Erm - no, it doesn&#039;t depend on the CPU. It depends upon your compiler. I believe that the C standard only says that fields within an &quot;ordinary struct&quot; (i.e. not using bit fields) are allocated with increasing addresses (in particular, not strictly increasing addresses) and does not say anything about alignment of them. It is quite possible that one compiler would lay out fields with different alignment than another on the same CPU, depending on how the fields are used (and compiler flags etc, etc).
Also note that this is an area where C and C+ differs.</description>
		<content:encoded><![CDATA[<p>Erm &#8211; no, it doesn&#8217;t depend on the CPU. It depends upon your compiler. I believe that the C standard only says that fields within an &#8220;ordinary struct&#8221; (i.e. not using bit fields) are allocated with increasing addresses (in particular, not strictly increasing addresses) and does not say anything about alignment of them. It is quite possible that one compiler would lay out fields with different alignment than another on the same CPU, depending on how the fields are used (and compiler flags etc, etc).<br />
Also note that this is an area where C and C+ differs.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on MakerBot Automated Build Platform Hack by e8johan</title>
		<link>http://www.digitalfanatics.org/2011/09/makerbot-automated-build-platform-hack/#comment-107</link>
		<dc:creator>e8johan</dc:creator>
		<pubDate>Fri, 16 Sep 2011 13:57:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.digitalfanatics.org/?p=497#comment-107</guid>
		<description>My idea was to use a washer instead, but I did not have any. Adding one nut meant that the bolt was too short, so I had to use two.</description>
		<content:encoded><![CDATA[<p>My idea was to use a washer instead, but I did not have any. Adding one nut meant that the bolt was too short, so I had to use two.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on MakerBot Automated Build Platform Hack by William Steele</title>
		<link>http://www.digitalfanatics.org/2011/09/makerbot-automated-build-platform-hack/#comment-106</link>
		<dc:creator>William Steele</dc:creator>
		<pubDate>Fri, 16 Sep 2011 13:56:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.digitalfanatics.org/?p=497#comment-106</guid>
		<description>Yep, I had the exact problem with my CupCake.  However, I didn&#039;t use an additional nut... I simply used two washers under it.  

The issue with it hitting the bottom of the wood plate (or in my case acrylic) happend to me as well.  It did effect the print quality of my unit slightly when it rubbed against it, so to fix it, I made sure my belts for the X/Y axis were tentioned properly so to minimize the amount of slack.  The other thing you can do is to trim the top of the brush in half (so that it is only 1/2 as thick) near the top to reduce the friction ever further.

Bill</description>
		<content:encoded><![CDATA[<p>Yep, I had the exact problem with my CupCake.  However, I didn&#8217;t use an additional nut&#8230; I simply used two washers under it.  </p>
<p>The issue with it hitting the bottom of the wood plate (or in my case acrylic) happend to me as well.  It did effect the print quality of my unit slightly when it rubbed against it, so to fix it, I made sure my belts for the X/Y axis were tentioned properly so to minimize the amount of slack.  The other thing you can do is to trim the top of the brush in half (so that it is only 1/2 as thick) near the top to reduce the friction ever further.</p>
<p>Bill</p>
]]></content:encoded>
	</item>
</channel>
</rss>

