On Tue, 2003-04-01 at 01:18, Micah Dowty wrote:
> Lalo and I have been discussing this more on IRC.
>
> The main sticking point seems to be exceptions- It would be great to use C++ as
> a C-with-exceptions, but the problem with that comes in interfacing between libOm
> and other components that may be in C, C++, Python, or any other language. If you
> call a C++ function from C (or from a C interface generated for another language)
> the exception wouldn't be handled correctly.
>
> There are a few solutions to this:
>
> - Give up on real C compatibility, and use something C++-friendly like SWIG
> for interfacing to other languages
>
> - Allow users of libOm to produce either C++ exceptions or something C-friendly.
> This would be a lot of unnecessary pain.
>
> - Make Om more like pg1's protocol- a protocol definition with completely
> separate implementations in each language.
>
> - Give up on using C++ in libOm, and stick to some C-compatible exceptions.
> The two workable ways to do this that we've come up with so far:
>
> - Use calling macros similar to what pg1 uses, but with real objects instead
> of just integers for exceptions. The objects could be tagged as the stack
> unwinds, for providing backtraces.
>
> - Use setjmp/longjmp and a separate stack. There's an implementation of this
> in Kazlib: http://users.footprints.net/~kaz/kazlib.html
Apart from the issue of interfacing with other languages, I find it wise
to use C++ just as "improved C". Reasons:
* Really well mastering C++ takes years. It is not only about
object modelling, it is also because there are a lot of more or
less hidden technical pitfalls. It's long and difficult to write
a perfect class. When your class is 95% perfect, 10% of it will
be effectively used ...
* C++ can be very error-prone if design patterns and coding
guidelines are not strongly enforced.
* I don't know if our community has, in average, a sufficient
level of experience in C++.
* We are (so far) in the C world. There is some sort of gap
between the C and the C++ world (gnome vs KDE)
* Object-oriented practices can be adopted even with non-oo
languages (e.g.: gtk is written in C)
* PicoGUI-2 is aimed at being a more stable refactoring of
PicoGUI-1. But with C++ newly adopted, PG2 may be again
experimental, so the stable one would have to become ... PG3 !
I would personally love an object design, especially for pgserver
drivers.
...but...
I find C++ too risky for PG2
If it only about exceptions, I would try to keep C and explore
possibilities to find techniques to mimmic these C++ exceptions
(probably with some setjmp/longjmp deeply hidden behind macros). This
seems anyway to be a broad concern, so no doubt many articles can be
found about that (http://www.google.com/search?q=%22exceptions+in+C%22).
If it is about the excitement of another language, I would invest on a
C++ client lib.
Finally, PG2 targets also embedded devices, not only with linux. Some
processor may not have a C++ compiler...
Pascal
-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/pgui-devel
