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