Re: C++ vs C for PicoGUI 2

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/