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

[Matthew Brush]

On 13-08-26 08:07 AM, Nick Treleaven wrote:
>  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?
>

I was waiting for Colomban to respond before piping up, but whatever. 
I'll just respond to the general topics in the thread in my typical 
TL;DR fashion (skip to Conclusion section if you like :)

Style and Ease of Contribution
------------------------------

Personally, I think it'd be great to use C++ in Geany, and it would more 
than likely actually make it *easier* for people to contribute since 
outside of a sampling of GTK+-using desktop/GUI software (and obviously 
embedded, kernel, drivers, and similar), C is considered "dead" and the 
majority uses >= C++ (more likely Java, C#, Python ... many people also 
consider C++ outdated and dead for desktop GUI apps - not me BTW :). C++ 
allows modern programming techniques but still retains much (or more) of 
the performance and "light-weightedness" that Geany strives for.

If we were to use C++, I think it'd be pointless to limit it to 
CFront/CwithClasses-style 1980's C++. We should use common/standard 
stuff like standard library containers, inheritance (maybe not 
multipl-inheritance), the class keyword, templates (where it makes 
sense), exceptions, etc. The issues/limits being discussed in this 
thread are issues long since considered "resolved" or "non-issues" for a 
long time for desktop software (and since a *long* time even before 
Geany's first line of code was written :). The style of code I read on 
the net and in talks and books and stuff is modern (ie. >= C++98) style 
C++ and I'd expect that's what the bulk of C++-using contributors would 
be used to using.

I'd say the limit on what should be used in Geany should reflect modern 
techniques and practices (ie. since 1998), perhaps following the 
style/limits used by Qt (excepting their MOC which extends C++ and not 
implementing standard strings and containers ourselves, which Qt does 
because they weren't standard when Qt started). Another good example of 
a high-quality maintainable C++ (IMO) is LLVM, which as I read in a 
quote somewhere that it "uses a 'tasteful' subset of C++" and is 
described to some extent in their coding/style guides and elsewhere on 
the net. Of course being a *massive* hunk of code in a high-speed 
optimizing compiler framework imposes different limitations on C++'s 
use, some of which might not apply to Geany.

<semi-off-topic-legacy-rant>
I would even go so far as to say it's silly to not use C++11 since it's 
such a major improvement over previous C++ versions, in both performance 
and readability/coder-friendliness and it's well supported on current 
compilers and platforms.

I've said it before that I think coding *new code* for *future release* 
using *outdated libraries/language versions* is silly, like using 
deprecated GTK+2 APIs, C89, etc, in *new code*, and I think the same 
applies to C++11. We're talking about *new code* for *future releases* 
not *old code* in *old releases*, which remain usable by users not using 
the "latest greatest" (anywhere from 2 to 20+ years ago depending on the 
topic), and in which many cases are being supported/patched/fixed by the 
distro vendor, often for money I would presume. Keeping in mind none of 
us gets paid to write the *new code*, it's harsh having to pretend it's 
2 to 20+ years ago (in some cases), for free, for little to no gain, 
much pain, going against current best practices evolved since the bad 
old days and often at the expense of readability, maintainability and 
sometimes even performance.

IMO, so long as Geany can **RUN** on the current supported versions of 
major operating systems, that is enough to strive for. Note that I said 
**RUN** and not **COMPILE** and that I'm talking about *new code* for 
*new releases* not for the old code in already working and released 
versions supported by previously released long-term support distros.
</semi-off-topic-legacy-rant>

Where to use it
---------------

In my personal opinion, it doesn't make a whole lot of sense to use C++ 
in the src/ directory, at least not just for the sake of compiling with 
g++ instead gcc. As mentioned, it'd be awkward interfacing G* stuff with 
C++ stuff, and would likely have very little benefit unless doing majour 
changes/re-writing of the existing code. If one wanted to make serious 
modifications to one the modules in src/, like re-writing it in en masse 
or majour improvements, then it'd definitively make sense to use C++ in 
src/ dir.

Another place it'd make good sense to use C++ is in some "non-core" 
module, say something like TagManager, MIO, Scintilla, or even as above, 
re-working an existing "core" module out into "non-core" land, say 
something like Stash library, that can stand alone. If such stuff was 
being re-written, replaced, or overhauled, then it'd be cool to be not 
stuck with plain C for ease of coding and improving maintainability.

<digression-from-C++>
Since we're talking about better languages, there's also Vala which has 
most of the benefits discussed here about C++, already uses the same 
libraries and type-system as our existing G* code, is API compatible 
with C (in the sense that it generates idiomatic G*-style C code, 
mostly) and would be an easier transition for the vast quantity of C# 
programmers out there who might want to contribute, since the languages 
are so similar. Not sure it's a point since most of them use Mono and 
C#-strong IDEs, but still, in general there's probably substantially 
more developers out there who know C# better than C or C++.

One of the down-sides with Vala is that there the language specification 
is incomplete, constantly moving, and overall the project lacks any 
really good documentation. However, the wiki, the "Vala for ___ Language 
Programmers" guides, Valadoc (which gradually improves), and tons of 
tutorials and example code out on the web somewhat make up for it. The 
other obvious flaw is that it's a young programming language and not 
widely tested or supported like C/C++ - ie. has more bugs in its 
implementation.

I'm not actually saying we should use Vala, just that it makes at least 
as much sense as C++ for Geany.
</digression-from-C++>

Why not to use it
-----------------

Above being said, the biggest reason not to use or allow any C++ outside 
of Scintilla is that Geany's maintainer, largest contributor in the last 
quite a while - most reviews, merges, patches, fixes, etc. - dislikes 
C++ (and quite vehemently, last we talked about it) . I also disliked 
C++ before I started learning it in earnest at which point I could see 
many of the great benefits over C (and also some new stinkers :). I bet 
Colomban would experience the same change of opinion about it, to some 
extent, if he used it more and started using some of the 
since-CwithClasses stuff more, BUT ... I'm not sure it's fair to "push" 
that onto him.

While it's a community project, and in general I think the popular 
opinion should ultimately prevail or at least that not one person 
(barring maybe a BDL) solely controls the direction of the project's 
momentum, it's somewhat harsh to make the current maintainer who does an 
excellent job and devotes a lot of time already to working on Geany 
stuff, to learn a whole different, non-trivial language, one he 
dislikes, and to become "more proficient than average" in order to be 
able to continue doing code reviews, merging PRs and stuff.

Note that I obviously don't speak for Colomban, it's just my feeling, 
and that I tried to wait until after he responded on his own behalf 
about C++ hate :)

Conclusion
----------

I'm all for using modern C++ in strategic (or new) places and I'm 
totally against using ancient 1980/90's CFront-style C++ or that which 
is restricted so much that it's basically C. Ultimately though, I would 
go along with whatever Colomban wants (except stick to C89 instead of C99 :)

Maybe rather than bikeshed about it too much, we can wait until someone 
wants to add a new module, or replace an existing module (I'm looking at 
you TM!), or some actual use case, at which point we could discuss 
whether it makes sense to use C++ for it, and since we already use C++ 
for Scintilla, it's not a huge change to use it in another new C++ 
module with respect to the build systems and stuff.

P.S. As usual, sorry for such a long message :)

Cheers,
Matthew Brush