<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://blogs.msdn.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>How to host an IContextMenu, part 11 - Composite extensions - composition</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/10/07/239197.aspx</link><description>Actually doing the combining.</description><dc:language>en-US</dc:language><generator>CommunityServer 2.1 SP1 (Build: 61025.2)</generator><item><title>re: How to host an IContextMenu, part 11 - Composite extensions - composition</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/10/07/239197.aspx#239266</link><pubDate>Thu, 07 Oct 2004 16:42:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:239266</guid><dc:creator>Jack Mathews</dc:creator><description>---------&lt;br&gt;Since a C++ constructor cannot fail, there are various conventions for how one handles failure during construction. One convention, which I use here, is to put the bulk of the work in an Initialize method, which can return an appropriate error code if the initialization fails.&lt;br&gt;---------&lt;br&gt;&lt;br&gt;Actually, the way you fail a C++ ctor is to throw an exception.  It will unwind the stack properly and will destroy appropriate obects if you throw in the middle of a ctor initialization.&lt;br&gt;&lt;br&gt;By putting your work in Initialize methods, you run the risk of not having fully formed objects, so that if an exception happens in between your ctor and initialize, your dtor could crash, causing all sorts of badness.</description></item><item><title>re: How to host an IContextMenu, part 11 - Composite extensions - composition</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/10/07/239197.aspx#239273</link><pubDate>Thu, 07 Oct 2004 17:07:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:239273</guid><dc:creator>Mike Dunn</dc:creator><description>I'll read the full post during my lunch break, but after a quick skim I'm confused by your CCompositeContextMenu::QueryInterface. If you do these steps:&lt;br&gt;  IUnknown* punk;&lt;br&gt;  punk = static_cast&amp;lt;IContextMenu*&amp;gt;(this);&lt;br&gt;  *ppv = punk;&lt;br&gt;Won't the first assignment counteract the cast, since by C++ rules the rvalue gets converted to an IUnknown*? ((IContextMenu*)this) is going to be a different value than ((IUnknown*)this), so wouldn't *ppv end up pointing at the wrong place in the vtbl?</description></item><item><title>re: How to host an IContextMenu, part 11 - Composite extensions - composition</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/10/07/239197.aspx#239318</link><pubDate>Thu, 07 Oct 2004 17:50:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:239318</guid><dc:creator>Raymond Chen</dc:creator><description>It's great to use a throwing model if your entire program follows it, but COM does not allow exceptions to be thrown across the COM boundary.&lt;br&gt;&lt;br&gt;Mike: I discussed this yesterday in a comment.&lt;br&gt;&lt;br&gt;&lt;a target="_new" href="http://weblogs.asp.net/oldnewthing/archive/2004/10/06/238630.aspx#239019"&gt;http://weblogs.asp.net/oldnewthing/archive/2004/10/06/238630.aspx#239019&lt;/a&gt;&lt;br&gt;&lt;br&gt;The double-cast works due to the rules for COM object layout.  COM requires that&lt;br&gt;&lt;br&gt;(void*)(IBaseInterface*)(IDerivedInterface*)p == (void*)(IDerivedInterface*)p&lt;br&gt;&lt;br&gt;In other words, the implicit cast to IUnknown is required by COM rules not to change the numeric value of p.&lt;br&gt;&lt;br&gt;Most C++ compilers for Windows will conform to COM object layout rules if you set the right compiler flags or use the right macros.&lt;br&gt;&lt;br&gt;&lt;a target="_new" href="http://weblogs.asp.net/oldnewthing/archive/2004/10/05/238050.aspx"&gt;http://weblogs.asp.net/oldnewthing/archive/2004/10/05/238050.aspx&lt;/a&gt;&lt;br&gt;</description></item><item><title>Using fibers to simplify enumerators, part 5: Composition</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/10/07/239197.aspx#346275</link><pubDate>Tue, 04 Jan 2005 18:00:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:346275</guid><dc:creator>The Old New Thing</dc:creator><description>Building a new enumerator by combining existing ones.</description></item><item><title>IContextMenu のホスト方法 - Shell</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/10/07/239197.aspx#558168</link><pubDate>Wed, 22 Mar 2006 20:33:34 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:558168</guid><dc:creator>社本＠ワック Blog</dc:creator><description>IContextMenu のホスト方法 - Shell</description></item><item><title>Shell Extensibility in Longhorn</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/10/07/239197.aspx#667451</link><pubDate>Sun, 16 Jul 2006 18:16:42 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:667451</guid><dc:creator>Community Blogs</dc:creator><description>I've been following in awe the series of posts (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11) by Raymond Chen about</description></item></channel></rss>