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

[Nick Treleaven]

On 29/08/2013 02:39, Matthew Brush wrote:
> 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.

Yeah, templates make it much easier for libraries to have extra 
flexibility in performance.

> 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.

Idiomatic C++ takes a *lot* of learning and experience to get right for 
someone coming from C.

> 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

I'm curious, why does it perform better?

> and readability/coder-friendliness and it's well supported on current
> compilers and platforms.

Is it? I hadn't heard that, maybe. But I bet it will cause problems for 
some distro maintainers/builders on LTS distros.

Readability is definitely better in C++11 when avoiding iterators and 
using lambdas, but I was kind of hoping we could avoid those ugly cases. 
I wasn't thinking of using the STL heavily, just a few containers like 
string, and perhaps others for any specialized use cases.

Variadic templates are very cool also. (Die, stream << operators!)

> 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++.

I'm happy to consider using Vala, but I think it would probably be a lot 
less work to use C++ if we want to convert existing code.

> 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.

+1. Although I would definitely be keener to contribute using restricted 
C++, I don't want to be maintainer again. Thanks for all the great work 
Colomban (and others) ;-)

> 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.

totally against :-O

RAII is a powerful feature that standard C has no hope of competing 
with. It basically allows a string type with automatic memory 
management. Ditto for templates, but I can live without defining our own 
templates if that helps contributor understanding & maintainability.

I proposed banning OOP, operator overloading and exceptions in src to 
make it (much?) easier to understand & maintain the code vs idiomatic 
C++, with all its unintuitive bug-prone corner cases (which are still in 
C++11), see my reply to Lex for more info.

> 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.

Yes, or maybe convert a core plugin that uses strings a lot, so we get 
the benefit of RAII. I might look into it unless Colomban is against 
that (even for a core plugin).

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

No problem, it was an interesting read.