<div dir="ltr">Hi Nick,<div><br></div><div>Thanks for the well thought out sensible proposal. In general I agree with the idea of progressively moving appropriate parts of the code to using appropriate C++ features. Of course, as usual, I disagree on some of the details and I'm sure we would disagree on some of the selections of files, but thats healthy.</div>
<div><br></div><div>Comments below.</div><div><br></div><div>Cheers</div><div>Lex<br><div class="gmail_extra"><br><br><div class="gmail_quote">On 27 August 2013 01:07, Nick Treleaven <span dir="ltr"><<a href="mailto:nick.treleaven@btinternet.com" target="_blank">nick.treleaven@btinternet.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">From the C99 discussion:<br>
<br>
lex:<br>
>>> Unless we follow the example of gcc itself and upgrade to C++ :)<br>
<br>
me:<br>
>> Not sure that's a good idea for Geany now, although I'm glad that gcc<br>
>> did it. They use a restricted subset IIRC. I miss templates and RAII in<br>
>> C though.<br>
<br>
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).<br>
</blockquote><div><br></div><div>I'll address the "restricted subset" idea here and refer back from relevant places below. My experience of a couple of projects migrating to C++ is that applying strict "limits" on the C++ features just leads to implementing those features poorly in the code itself. One common one is to not allow virtual functions, but in my experience that just leads to the use of function pointers and the associated ugly syntax and increase in errors. Since the runtime costs are still there, all you have saved is the cost of the pointer in the object (or at least reduced it to a flag indicating the object type, but then you have to test it each use, again error prone).</div>
<div><br></div><div>The approach that seems to have worked better is the same as that required for C++ in general, *appropriate* use of features. Whilst that is easier to control in a corporate situation where programmers can be trained properly, review by senior devs should catch the more egregious misuses within Geany, its not like we have a huge developer base to train anyway :).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Reasons:<br>
<br>
* No build problems for Long Term Support distros that don't support C99 (but clearly do compile scintilla's C++98).<br></blockquote><div><br></div><div>Neil is attempting to move Scintilla forward, it might soon be using C++03.5</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* RAII - this is a pretty essential feature for safe resource management. It's a stupid acronym though, it's basically automatic scoped destruction:<br>
<br>
<a href="http://en.wikipedia.org/wiki/Resource_Acquisition_is_Initialization" target="_blank">http://en.wikipedia.org/wiki/<u></u>Resource_Acquisition_is_<u></u>Initialization</a></blockquote><div><br></div><div>Agree on both the usefulness and the silly name :)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
* References can be useful in making code more readable vs pointers.<br></blockquote><div><br></div><div>Unfortunately, since references are immutable, you can never get rid of pointers in imperative style programs, that leads to code with a mix, luckily getting it wrong (using . not ->) will be picked up by the compiler.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* 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.<br>
</blockquote><div><br></div><div>Indeed there is a learning curve, but hopefully many will find that useful and attractive.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* Possibly we might use some STL containers internally.<br>
<br></blockquote><div><br></div><div>Most definitely.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Possibly we could use a GObject wrapper for safe reference counting. I don't want to add any dependencies on C++ libraries though.<br></blockquote><div><br></div><div>Or what almost all my C++03 programs have, a template headed: /* The ubiquitous intrusive reference counted smart pointer */ :)</div>
<div><br></div><div>Of course use gobject, for things that are gobjects, but don't bring it into things that are not, the idea is to move to C++, not to tie more closely to a C library.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* Possibly we could have some template function utilities instead of unsafe macros. Although I think most header files should be kept C90 compatible.<br></blockquote><div><br></div><div>Yes existing headers that are used by the remaining C code will have to remain C compatible, and will probably need:</div>
<div><br></div><div>#ifdef __cplusplus</div><div>extern "C" {</div><div>#endif</div><div><br></div><div>around them.</div><div><br></div><div>But (for C++ files) that doesn't prevent having extra headers with templates in them.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
matt:<br>
> +1. While I'm also not sure it's a good idea in Geany and certainly<br>
> won't be pressing for it anytime soon, 90% of C++'s crumminess is due to<br>
> backwards compatibility with C, so I think it should be (theoretically,<br>
> not socially) possible to gradually transition from one to the other in<br>
> a project like Geany without too much pain.<br>
<br>
colomban:<br>
> I doubt it, C++ is sufficiently different from a C program not to be<br>
> compilable by a C++ compiler in many cases -- even if it is just for<br>
> some implicit casts C++ requires to be explicit (IIRC), and there are<br>
> plenty. Or maybe it depends what "too much pain" means:)<br></blockquote><div><br></div><div>So long as the gain is larger than the pain.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> Also, I doubt it's any kind of sensible either, because good C++ use is<br>
> sufficiently different from C to require large rewrite. In this case,<br>
> better rewrite everything and don't keep the clumsy code<br>
<br>
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).<br>
</blockquote><div><br></div><div>I agree with Nick, my experience is transitioning to C++ does not need a big re-write just to get a compile. You then *choose* what to re-write, to take advantage of features to make life easier and safer. Even I don't advocate wholesale re-writing of random code to C++ idioms without a reason :) </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br></blockquote><div><br></div><div>
Yes, so long as C compatible interfaces are available for as yet unconverted files its fine, for example if GeanyDocument became a C++ class appropriate headers would be needed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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:<br></blockquote><div><br></div><div>I addressed the problems with this general idea above. It will also lead to ongoing bikesheds on what features are "allowed" and why can't Geany progress to use more useful features and ... This is both wasteful of community time, and destructive of community spirit, better to encourage use of appropriate features, and where an "advanced" feature is appropriate, then it can be used without having to remove such constraints.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-fno-rtti (disable runtime info for object inheritance)<br></blockquote><div><br></div><div>Hardly worth it :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
There ought to be a way to disable mixed code and declarations, but maybe not.<br></blockquote><div><br></div><div>NEVER DECLARE ANYTHING UNTIL YOU HAVE A VALUE FOR IT. :)<br></div><div><br></div><div>For those having trouble finding declarations not at the top of a scope, remember Geany highlights types, so declarations stand out, just change your theme to make them more visible Colomban ;)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I don't know if this can be enforced by g++, but I suggest we disallow these keywords:<br>
<br>
class<br></blockquote><div><br></div><div>Why, its just a struct with default hiding, this just forces the use of struct xxx { private: .... }. The use of private members is an important part of the ability of the compiler to protect the programmers from themselves, and a big plus of C++, since it makes it easier to ensure that required invariants are maintained because only listed entities can change the members.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
dynamic_cast<br></blockquote><div><br></div><div>Agree it should *almost* never be used, and so just search for it is easy enough.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
friend<br></blockquote><div><br></div><div>Unless you are implying never to use private members, sometimes you *have * to use friends.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
mutable<br></blockquote><div><br></div><div>Its mostly useful for optimisations that we probably don't need ... yet :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
operator<br></blockquote><div><br></div><div>Thats required to define the ubiquitous reference counting smart pointer, but agree that operators should *only* be used where their semantics mirror the standard ones. (and of course only in interfaces which are not used by C code)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
throw<br></blockquote><div><br></div><div>Agree, when we have mixed C/C++ code, throwing an exception from C++ through C can cause all the resources in the C code to leak since it doesn't have any destructors to clean up for it.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
virtual<br></blockquote><div><br></div><div>Geany has a couple of places where a bastardised version of virtual functions have been implemented in C, its ugly, hard to understand, and error prone. These cases *should* be replaced by C++ virtuals (if anyone understands the C code enough to do it :)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
That could be enforced with a 'make check' build target.<br>
<br>
Thoughts?<br>
<br>
Regards,<br>
Nick<br>
______________________________<u></u>_________________<br>
Devel mailing list<br>
<a href="mailto:Devel@lists.geany.org" target="_blank">Devel@lists.geany.org</a><br>
<a href="https://lists.geany.org/cgi-bin/mailman/listinfo/devel" target="_blank">https://lists.geany.org/cgi-<u></u>bin/mailman/listinfo/devel</a><br>
</blockquote></div><br></div></div></div>