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. :)

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 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 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++. :)

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 :)

Cheers

Lex

[...]