Re: [gtk-list] Re: I want to understand (and new questions)

[Erik Mouw <J A K Mouw its tudelft nl>]

On Wed, 14 Apr 1999 12:05:33 +0200, gtk-list@redhat.com (Lars Hallberg) wrote:
> On Wed, Apr 14, 1999 at 04:56:08PM +0900, Ionutz Borcoman wrote:
>> Robert_Gasch/PeopleSoft@peoplesoft.com wrote:
>> > 
>> > 4) Using C++ as the base would make other language bindings more difficult
>> > to write (??)
>> C++ mangles names in the object code generated, while C not. I have
>> understood that this is the reason why bindings to C code is simpler to
>> made. Somebody please correct me if I'm wrong.
> 
> And the namemangling is not standarised so moduls from different compilers
> might not link toghether - Thats a pain with 3:th party non sourcecode
> librarys (but open source is a solution to that ;-).

And it will not even be standa

> Hovever, C++ have a keyword for declering C-functions so ther is no problem
> to add an C interface to a C++ library. The data structurs is identical
> (as long they ar *not* virual classes) so that ads no extra trouble.
> 
> The other way around, use a C library from C++ is also esy so the question
> comes down to void ;-) With one exeption - callbacks and exeptions.
> 
> GTK is realy a framework that take (big) part of the controll of the
> applikation and do callbacks to eventhandlers. That mens a C++ event
> handlers can't throw an exeptions to be catched in an main C++ app.
> 
> If the event handler is defined in an library that might be anoying. I
> guess it is anoying for some langage bindings to ;-)
> 
> What can be done?
> 
> 1) Only use the low level GTK and write a new C++ framework.
> 
>    * Some stuff like confile interface and thems can hopfully be reused.
> 
>    * I have not looked at the source but i geuss the callbaks is
>      raised from the widgets themself wich means all the widgets
>      will be reimplemented :-(
> 
> 2) Introduse an #ifdef branch that C++:ifies the GTK framework part
> 
>    * Advantage over abowe is that most parts of the widgets will
>      be reused an that the two interfaces will follow eachother
>      more naturly i the development.
> 
>    * Will slightly inkrease GTK owerall source complexity.
> 
>    * This will be a HUGE job but can be joint efort from GTK--,
>      VDK and other C++ users. Thanks to CVS the efort shuld not
>      need to come in the way for C developer (not much at least)
> 
> 3) Live with an restricted usage of exeptions forewer :-(
> 
> Don't count on me for some while, I'm busy with glib C++ wraper and
> face much the same troubles. Thats way ben thinking about it ;-)
> 
> So, i just wanted to share the ide. What do You C developers feel
> about an C++ #ifdef branch for the 'framework' and othe callback
> parts of GTK? It seams to be the 'less unreasnable' path for me
> even if not compleatly reasnable ;-)
> 
> Thanks /Lars
> 
> PS Exeptions adds complexity the other way around to. You do
> not want a C interface to a C++ lib to throw exeptions at an
> helples C app :-( DS
> 
> -- 
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
> 



-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2785859  Fax: +31-15-2781843  Email J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/