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.