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