On 13-08-16 01:57 PM, Colomban Wendling wrote:
Le 16/08/2013 22:09, Matthew Brush a écrit :
[...]
Not meant as a rant against G*,
Sorry then, I read the final sentences as such, sorry.
when it was started (~1998 IIRC), there was a reason for wrapping all the (then) non-standard stuff for portability. But now, it just makes it harder for people to contribute code since many are used to using standard C (or more likely C++) and have to double check everything to make sure that nothing post 1989 was used unless it has a g in front of it.
You're dreaming, I 99.99999% sure *nobody* does it, and if we don't have to change much is only because there aren't much use of the things C99 adds. And at worse it's only adding "g_" in front, it doesn't really mangle the name.
P.S. Sorry for the bikeshed bait.
Yeah, and sorry to sound so annoying (especially in the other mail ;), but I really see this as "let's upgrade for the sake of upgrading", and I don't see the point. And this annoys me when you try to justify it by ranting against G* -- not that I care about the rant, but because it's a false justification.
Although I often do rant against G*, I didn't do that here at all, I don't think. My point is why does everyone (core devs and especially other drive-by contributors) have to use rules from before you were born (or so), just for the sake of you being able to stick -pedantic -std=c89 on your compiler command line? It seems so arbitrary.
A: Why not? Or, so we don't get mixed declaration and code, it just doesn't build with -std=c89 :)
While I agree mixing declaration and code is almost always a bad thing (generally means you should have another scope), I'm pretty sure it does have sometimes a usefulness. One fake example could be:
int foo, bar; GtkWidget *blah;
... 50 lines of code using foo, bar and blah ...
bool result = something_at_end(blah); if (result) do_something_special(); return result;
Although I'm not fan of the idea, I wouldn't bikeshed against it if there was a reason *to* do so. The only one I see in your mail is "Allowed to declare loop counter-style variable inside the for loop", and I don't find it worth even updating HACKING.
Actually I provided a list of 44 new features, of which we all seem to agree (even you) that a subset of those are useful.
Even if it was only for // comments, what's the argument for *NOT* starting to use a well-established ISO standard that's already one full iteration behind the current standard? Sure we might only use 4 or 5 "new" language features in practice as opposed to the full list I pasted, but so what? Why not? What do we lose by doing this?
What do we get?
I'm pretty sure I already gave a list of things, including a number of those that we all seem to think are useful, but I'll filter out and repeat here:
1. Variable length arrays 2. Translation unit limits (IIUC - and not super compelling) - Longer string literals (from 509 chars to 4095) after concat - Number of external variables (think of those from sys hdrs) - Number of nested includes (again gtk/sys hdrs) - Number of enumerators in an enum (from 127 to 1023) 3. Remove implicit int (useful for when you made a typo, like forgetting return statement, although compiler usually warns anyway). 4. Reliable integer division (always rounds in same direction) 5. Compound literals 6. Designated initializers 7. // comments 8. Extended integer types (can use std names rather than g ones) 9. Remove implicit func. decls (compiler usually warns, but still) 10. Mixed declaration and code (as example above it *might* be useful once in a while, but nothing says our style guide can't disallow it). 11. Vararg macros (IIRC the thing you mentioned can be avoided by combining the arguments - would need to confirm, I've only used the GCC extensions for this). 12. Trailing comma in enums (no biggie but it's useful in case of modifying or re-arranging existing code) 13. Inline functions guaranteed to hint the compiler (and without ugly g names) 14. snprintf (without using non-std g one) 15. bool (without using non-std g named one - shorter and more readable, and can use "true" and "false" instead of non-std TRUE and FALSE macros, which is same as most other C-ish langs) 16. Empty macro arguments (might be useful for avoiding to break code by changing a function out for a function-like macro without arguments). 17. VA_COPY (sometimes useful when passing around va_lists)
So there's 17 reasons to allow using C99 (not including mentioned loop counter thingie), of which I'm sure you'll agree at least a handful could be well used in Geany. And yeah G* provides wrappers for some of them, but why would we want to use non-standard G* wrappers rather than standard C unless we had to?
Think of new contributors who haven't used C since college (which likely could've been C99 at that point :), when they want to make changes to Geany they not only have to learn all of the G*-isms and follow our own style rules, but also code to a > 20 year old obsolete (twice over) language standard.
BTW, what originally inspired me to send this message was that many many PRs have this comment attached to them: "no //-style comment, we use C89" (paraphrasing). IMO that's a crap reason for blocking a contribution or making someone (who used a perfectly standard C feature) add another commit, squash it into the previous ones and open a new pull request (or however it gets dealt with).
We cant change them ourselves, indeed. But even if we started to use C99 (why?), I'd still would like to keep our style -- which does include "no C++-style comments" :) Why? Because I like it, because it'd be consistent with the rest of the sources, and because it doesn't hurt. Yesterday I said "no blank line at start of block": this has nothing to do with the language, it's just useless and ugly.
I'm not advocating for throwing away our style guide at all, just that we should allow some C99 and update our guide accordingly. And FWIW, they aren't "C++-style comments", they're "standard C comments" since over 10 years, and you're the only person I've heard say they don't like/use em :)
And one last note is that we have a giant glob of C++ in our source tree that is moving towards C++11[1] (which not surprisingly uses // comments), and I'm pretty ruins any chance of compiling Geany on a pocket calculator that only supports ancient C89 compilers :)
Let's party like it's 1999!
Cheers, Matthew Brush
[1] https://groups.google.com/forum/#!topic/scintilla-interest/j5xKrl9cU2g