Le 2012-02-22 à 02:12:00, katja a écrit :
I was considering C++ just for programming comfort. I know that everything can be done in C but it is so clumsy for making class-like things. If Pd would be conceived today, would it be written in C?
I can't imagine Miller writing it in C++...
But even though I'd like Pd to be written in C++, I'm conscious of its limitations about dynamic OOP. For example, you can't define methods at runtime, find methods by string, etc., which is bad for making a language like Pd.
So, the comfort of C++ programming and the time saved during development may be outweighed by troubles in deployment? I have to think twice... My lib should easily build and run wherever Pd runs.
I'm not saying that, but it is annoying.
It's also possible to use a lot of C++ features while still using plain CDECL interfaces for external linkage (extern "C"). Plain Pd externals are even simpler : they only need to export one function to the linkers, and they do the rest of the linking by calling class_addmethod and such.
I started reading Axel-Tobias Schreiner's 'Object-Oriented Programming with ANSI-C', found via Marvin's link. The title made me enthusiastic for a moment. I like C. But for OOP? It's a lot of dull administration.
OOP has been done many times in C. There are many examples of it, most notably Xt (the common portion between Athena, XView/OpenLook, Motif/CDE, the old widget toolkits) ; but even more notably, Glib/Gtk/GNOME.
It's good to read a book like that if you wanted to rewrite Pd in C++ (I don't know that book, I mean only this topic). This is because even if you use C++, you'll probably have to cook your own OOP features at one point or another. Even though C++ includes tonnes of features and very intricate details, it still leaves a lot of interesting topics untouched. C++ is really meant for compile-only use, and anything that looks like an interpreted language (such as Pd) is unimplemented.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC