[Geany-Devel] Let's move to C++98 - Re: Lets move to C99

[Nick Treleaven]

 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