From mboxrd@z Thu Jan 1 00:00:00 1970 From: Razvan Cojocaru Subject: Re: [PATCH] libxc, libxenstore: make the headers C++-friendly Date: Tue, 22 Jan 2013 19:44:51 +0200 Message-ID: <50FED013.6000101@gmail.com> References: <93e5f6cf98d2ae3539db.1358873051@rcojocaru.dsd.ro> <50FED22102000078000B86C8@nat28.tlf.novell.com> <50FEC73B.7020208@gmail.com> <50FED67602000078000B86EA@nat28.tlf.novell.com> <50FECBB6.9050901@gmail.com> <20130122173130.GF87324@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130122173130.GF87324@ocelot.phlegethon.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tim Deegan Cc: Jan Beulich , xen-devel List-Id: xen-devel@lists.xenproject.org > Well, obviously you shouldn't leave it lying around. Can you do > something like > > extern "C" { > #define private mumblywurzle > #include > #undef private > } There are other headers that indirectly include ring.h. My code never includes it directly, and, as you have seen, the errors were far from specific. Trying to figure out who brought what header in and what the error means, and fighting to be able to use C++ properly on top of that is surely not something any of us prefers. > Once again, this isn't C++. If there has to be an ugly workaround, put > it in the C++ code. There should be no ugly workaround. I'll probably leave all the headers alone, implement my own C wrapper that exposes extern "C" functions and hides all the macro stuff, and build my C++ application on top of that intermediate layer. I just asked because I thought there might be some interest in being able to use the Xen code directly from C++ projects; if there isn't, that's fair enough. Thank you for all your comments! Cheers, Razvan Cojocaru