[Geany-Devel] Let's move to C++98

[Nick Treleaven]

On 05/09/2013 12:26, Lex Trotman wrote:
> [...]
>
> Hi Nick,
>
> Still somewhat noisy IMO. How about this, C++98 (I think):
>>
>> #include <boost/foreach.hpp>
>> #define FOREACH BOOST_FOREACH
>>
>> FOREACH(Document &doc, win.documents())
>> {
>>      // do stuff with each document
>> }
>>
>>
> Frankly if you want to limit the parts of standard C++ that are used, the
> last thing you want to do is to introduce a whole second language, that of
> the Boost library. :)

That macro is very similar to C++11 range for. A whole second language 
it is not.

> Also you previously worried about compilation times, well boost is a big
> hairball of headers that include each other, efficient for its developers,
> but its notorious for slowing compilations to a crawl.

I haven't used it, but it says it's supposed to be modular. It may well 
be possible to use BOOST_FOREACH without adding more than a few headers 
to the project. What don't you like about it? Surely you can see it is 
much cleaner than std::for_each?

> I guess I was wrong when I said we disagreed on details, I think after
> reviewing the thread, we disagree at a very fundamental level on limiting
> parts of the language.
>
> To me limiting language features removes many benefits of the language by
> throwing away the standard idioms and solutions that use them.  The design
> problems for Geany are not unusual, and there are a set of well known and
> documented solutions to many of them.  These solutions are known to work,
> and known to work well, and known to be safe, and by removing specific
> language features many of these standard solutions become no longer
> available.
>
> Using a project specific subset of features is not likely to make it easier
> for C programmers to learn and contribute because they can't follow the
> standard advice in books and on the web any more.  It also is not likely to

They don't need to learn it. We could even limit RAII to just using the 
string type. Dynamic strings are well understood by programmers, even 
GLib has GString. Strings are fundamental to Geany.

The problem is if we don't agree to just use the most useful C++ 
features, there is no way the project will move to it. C++ is controversial.

> attract any existing C++ programmers, they are unlikely to want to discount
> their knowledge capital by being limited to a subset of their known
> solutions.  Moving away from the documented standard language just adds
> more barriers to contribution.
>
> And doing things like writing project specific macros like
> "foreach_document" doesn't help, in either C or C++. :)

I'm happy to consider a better solution, Matt's foreach_doc is much 
better, once we move away from C90. If you have a better idea, please 
start a new thread. It must somehow deal with doc->is_valid 
transparently though.

If we could accept BOOST_FOREACH, we could make a documents() function 
that works with it.

> This does not mean that there should be a free-for-all on how C++ features
> are used.  They should be used where that feature would normally be
> expected to be used, rather than a sub-optimal C-like solution, or a
> solution that uses features for features sake.  I can only defer to the
> expert on the subject
> http://www.stroustrup.com/bs_faq2.html#coding-standard and
> please note the JSF standards are *not* applicable to Geany.  Geany isn't
> an over budget, over schedule, critical real-time, billion dollar weapons
> platform :)  The key idea is to have a set of standards appropriate to the
> project.
>
> Ignoring style advice, since we have our own, something much more
> appropriate is the GCC coding conventions
> http://gcc.gnu.org/codingconventions.html.  The C++ section starts:
>
> "C++ is a complex language, and we strive to use it in a manner that is not
> surprising. So, the primary rule is to be reasonable. Use a language
> feature in known good ways. If you need to use a feature in an unusual way,
> or a way that violates the "should" rules below, seek guidance, review and
> feedback from the wider community."
>
> This is also a project moving from C to C++ (and as of recently has
> achieved the milestone of compiling fully with C++) and the rules
> anticipate changes, such as the desire to move to RAII style exception
> safety.  This may then permit the use of exceptions.  These changes can
> happen progressively throughout the code base, and gcc is a "little" bigger
> than Geany :)

We have very few resources (and possibly expertise too) to rewrite the 
Geany API in C++, and it would be a big distraction and likely cause 
many arguments (as it already has).

We could instead decide to be pragmatic instead of idealistic and accept 
that only using the most useful features of C++ that apply for Geany is 
a workable, maintainable, easy to understand solution that is still 
better than just C99.

I won't continue to push for this unless anyone else shares my view. We 
can probably give up on any C++ in Geany's core.