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.
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
