bug-mailutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: C++ & Hydrant


From: Alain Magloire
Subject: Re: C++ & Hydrant
Date: Fri, 9 Feb 2001 20:46:11 -0500 (EST)

> 
> "Alain Magloire" <address@hidden> writes:
> 
> > > In C++? Absolutely not! No, GNUTS is being designed/written in C for
> > > maximum portability and ease of adding bindings for other
> > > languages.
> > 
> > Sigh ... you know that's not completly true.
> 
> Not completely true, perhaps, but it does have some truth.

Mame mangling is different from one compiler to another.
So to provide binding, one as to export some entry points:
extern "C" { int CreateMailboxFactory (mailbox_t *); }

> 
> > It is, I admit, very unfortunate that C++ does not provide __binary__
> > compatibility, this was not address in the ISO C++ std.
> > But there are good examples on how to do this cleanly with
> > the Factory design patterns, Microsoft COM(no comments form the gallery
> > please) is a prime example of good use of those patterns.
> 
> Binary compatibility is quite important, don't you think? Perhaps when

You can get away with it by having a rigid separation between the interface
and the implementation and only give the user functions entry points.
I think this what you were doing with GNUS by not exposing the layout
of your structures.  All of what the users see is
typedef struct _window * window_t;
which is an opaque object.  The same can hold for portable C++.
In C you can still typecast and peek at the layour, not in C++.

> GCC has settled down and C++ becomes stable, there will be more
> useable C++ libraries, which will be a Good Thing, but until then C
> will remain my personal language of choice for libs.

C++, as a language, was stable, but the compiler vendors including GNU C++
did not catchup and C++ has now a formal ISO C++ standard.  But that said,
I have to agree there are still some pitfalls , exceptions come to mind.

> > And you can add bindings for other language using C++.  You just
> > have to be carefull and use pure virtual base class when defining
> > your interface, working like this is already a good engineering practice.
> 
> Of course you can add bindings for other langauges from any language
> (theoretically). Arguably, though, I think it is far easier to make
> C++ bindings for C rather than the other way around, especially given
> the mentioned ABI flux.

True and for a C++ library trying to be compiler independent, the entry
point remains a C function:
extern "C" { entrypoint_create_object (); }

> Also, given that C is still where the majority
> of free software development takes place (and is the recommended
> language by the FSF for GNU projects in particular), it seems C
> bindings are more important right now.

With such a mentality, we are stuck with C forever.
I do not see QT/Kde as big failure, motif on the otherhand ... ;-)
kidding, I'm going on very dangerous ground, please take with lot of salt,
aspirins, and a shot of cognac(or brandy if you're form the UK).

> Yes, similar thing with GNUTS. You have things like a window_t and a
> button_t and you tell the window_t to insert this button_t and if the
> current backend is curses it is naturally implemented differently than
> if GTK+ is the backend. OO-y in nature, with window_t and button_t
> designed as opaque structures and families of functions associated
> with them.

There are a lot and I mean a lot of toolkits/frameworks out there, old, good,
bad, OO, non-OO, you name it exists.
There is absolutely no way that GNUTS could gain acceptance.

But OTO, using GNUTS as the generic front-end to hydrant would be certainly
worth the effort.  I do not know of any other toolkits that gives the
possibility of using cursors as the backend or gtk+.

It would be nice to use hydrant on consoles and still be able to get
to the menus and on a windowing systems taking advantage of the fact
to be able to display an inline image in a mime message.

So having a mean/lean/lightweight little toolkit to isolate ourselfs
from the gui wars could be good as long as it stays focus on its purpose.

> Not written down anywhere, I keep meaning to do it so I can force
> myself to stick with something at least, but as we all know writing
> documentation isn't the fun part. ;)

Speaking with my heart.


-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!




reply via email to

[Prev in Thread] Current Thread [Next in Thread]