From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14368 invoked by alias); 17 Dec 2007 00:24:17 -0000 Received: (qmail 14351 invoked by uid 22791); 17 Dec 2007 00:24:16 -0000 X-Spam-Check-By: sourceware.org Received: from exprod6og102.obsmtp.com (HELO exprod6og102.obsmtp.com) (64.18.1.183) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 17 Dec 2007 00:24:05 +0000 Received: from source ([192.150.11.134]) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP; Sun, 16 Dec 2007 16:24:03 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBH0Lfin010016; Sun, 16 Dec 2007 16:21:47 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lBH0NsFV006163; Sun, 16 Dec 2007 16:23:55 -0800 (PST) Received: from namailgen.corp.adobe.com ([10.8.192.91]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Dec 2007 09:23:53 +0900 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Sub lib compatibility with g++ Date: Mon, 17 Dec 2007 00:24:00 -0000 Message-ID: References: <271051.85458.qm@web46004.mail.sp1.yahoo.com> From: "John (Eljay) Love-Jensen" To: "Kumar Bhaskar" Cc: X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2007-12/txt/msg00297.txt.bz2 Hi Kumar, > Do you think this will work out ? It can work. It won't be fun. > One other aspect I am concerned about is that with the above, myprog will= eventually make use of both the gcc C++ runtime and the Sun C++ runtime (v= ia the two MODULES A and B which respectively call into libs libA.so and li= bB.so). Do you see any issues with that ? The key issue is making sure that symbols are properly bound, such that the= Sun C++ only binds to Sun C++ symbols by the loader, and GCC C++ only bind= s to GCC C++ symbols by the loader. Another solution is to use separate processes, and then communicate to the = Sun C++ "slave" process (assuming that's the one you'd make slave) through = RPC or IPC or a listening socket. That makes for a very clean demarcation = between the GCC C++ process and the Sun C++ process. > Also - do you know of any good examples and/or web resources that demonst= rate how the "thunking" libs. should be created and provide more info. on t= he details ? No, I'm not sure. I learned it by working with Netwise RPC technology, before Microsoft acqui= red them. Another good example of providing an opaque C interface to an object-orient= ed implementation is Apple's Carbon. X11 is also a good example of object-= oriented design, implemented in C (which could have been written in C++ -- = maybe it is in some implementations). If you only have one top level class to expose, say SunFoo... class SunFoo { public: SunFoo(); ~SunFoo(); void DoSomething(); void OtherSomething(std::string const&); }; ...you're thunking C interface will have to provide... Initialize(); Terminate(); int ExceptionOccurred(); typedef struct OpaqueSunFoo* SunFoo_t; SunFoo_t SunFooConstruct(); void SunFooDestruct(SunFoo_t); void SunFooDoSomething(SunFoo_t); void SunFooOtherSomething(SunFoo_t, char const*); You'll need to have a "cookie" that represents a SunFoo on the GCC side. S= omething like "typedef struct OpaqueSunFoo* SunFoo_t" can work well. You'll need to "revive" all C-style parms into the SunFoo's C++ object parm= s. You'll need to carefully manage memory allocation so the right side of the = fence has ownership & responsibility to delete/free things. You'll need to catch all exceptions and have some facility to query if an e= xception occurred. If your Sun C++ has lots and lots of objects and methods that you want to e= xpose... then that can be a considerable (and very unpleasant) challenge. HTH, --Eljay