<?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: Bjarne Stroustrup on C++/CLI</title>
	<atom:link href="http://blog.stevex.net/2006/08/bjarne-stroustrup-on-ccli/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.stevex.net/2006/08/bjarne-stroustrup-on-ccli/</link>
	<description>Software development and other notes.</description>
	<lastBuildDate>Tue, 15 Jun 2010 13:44:34 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>By: Peter Ritchie</title>
		<link>http://blog.stevex.net/2006/08/bjarne-stroustrup-on-ccli/comment-page-1/#comment-14280</link>
		<dc:creator>Peter Ritchie</dc:creator>
		<pubDate>Sat, 09 Sep 2006 16:13:19 +0000</pubDate>
		<guid isPermaLink="false">http://blog.stevex.net/index.php/2006/08/22/bjarne-stroustrup-on-ccli/#comment-14280</guid>
		<description>I think what Bjarne is trying to say is to have an abstraction layer of C++/CLI code that provides access to ISO C++ code (i.e. code that is not publicly available at the assembly level or uses .NET classes).  C++/CLI will perform all the PInvoke between the CLI class and the ISO C++ classes automatically with C++ interop.

This, of course, depends on your goals.  If you *never* plan on using the ISO C++ code in anything other than managed application, forcing it the be PInvoked adds a slight performance hit for no reason.  Arguably a premature optimization to push C++ code that does not access .NET classes or CLI features into C++/CLI...

Although Bjarne puts a heavy preference to writing &quot;portable&quot; code, using ISO C++ over C++/CLI forces the code to be compiled for a specific processor, making the assembly essentially not portable, depending on the platform to which it is deployed.</description>
		<content:encoded><![CDATA[<p>I think what Bjarne is trying to say is to have an abstraction layer of C++/CLI code that provides access to ISO C++ code (i.e. code that is not publicly available at the assembly level or uses .NET classes).  C++/CLI will perform all the PInvoke between the CLI class and the ISO C++ classes automatically with C++ interop.</p>
<p>This, of course, depends on your goals.  If you *never* plan on using the ISO C++ code in anything other than managed application, forcing it the be PInvoked adds a slight performance hit for no reason.  Arguably a premature optimization to push C++ code that does not access .NET classes or CLI features into C++/CLI&#8230;</p>
<p>Although Bjarne puts a heavy preference to writing &#8220;portable&#8221; code, using ISO C++ over C++/CLI forces the code to be compiled for a specific processor, making the assembly essentially not portable, depending on the platform to which it is deployed.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
