From the C99 discussion:
lex:
Unless we follow the example of gcc itself and upgrade to C++ :)
me:
Not sure that's a good idea for Geany now, although I'm glad that gcc did it. They use a restricted subset IIRC. I miss templates and RAII in C though.
I now think gradually using a (quite heavily restricted) subset of C++98 for *some* source files might be better than moving to C99 (more on that below). I still support C99 over just C90 though. (I don't do a lot of Geany coding now, but I plan to do some from time to time, so obviously this is just my opinion and less important than more active devs).
Reasons:
* No build problems for Long Term Support distros that don't support C99 (but clearly do compile scintilla's C++98).
* RAII - this is a pretty essential feature for safe resource management. It's a stupid acronym though, it's basically automatic scoped destruction:
http://en.wikipedia.org/wiki/Resource_Acquisition_is_Initialization
* References can be useful in making code more readable vs pointers.
* Developer enjoyment, productivity & gaining more experience with C++. (This might be an incentive for e.g. me to spend more time working on Geany). This has to be offset against those that might need to learn e.g. RAII.
* Possibly we might use some STL containers internally.
* Possibly we could use a GObject wrapper for safe reference counting. I don't want to add any dependencies on C++ libraries though.
* Possibly we could have some template function utilities instead of unsafe macros. Although I think most header files should be kept C90 compatible.
matt:
+1. While I'm also not sure it's a good idea in Geany and certainly won't be pressing for it anytime soon, 90% of C++'s crumminess is due to backwards compatibility with C, so I think it should be (theoretically, not socially) possible to gradually transition from one to the other in a project like Geany without too much pain.
colomban:
I doubt it, C++ is sufficiently different from a C program not to be compilable by a C++ compiler in many cases -- even if it is just for some implicit casts C++ requires to be explicit (IIRC), and there are plenty. Or maybe it depends what "too much pain" means:)
Also, I doubt it's any kind of sensible either, because good C++ use is sufficiently different from C to require large rewrite. In this case, better rewrite everything and don't keep the clumsy code
I disagree it *requires* a large rewrite. You can make *good* use of some C++ features without having *idiomatic* use of C++. (E.g. dmd, the reference D compiler is not written in idiomatic C++ - it doesn't use the STL really, but it's still good code).
I think it would be quite manageable. If we did this, I suggest just converting one source file at a time, and only files that can benefit from RAII and/or the more powerful type system.
We would also need to disable some C++ features. I hoped we could do that with g++ flags, but I've only found this so far:
-fno-rtti (disable runtime info for object inheritance)
There ought to be a way to disable mixed code and declarations, but maybe not.
I don't know if this can be enforced by g++, but I suggest we disallow these keywords:
class dynamic_cast friend mutable operator throw virtual
That could be enforced with a 'make check' build target.
Thoughts?
Regards, Nick