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.