Now, now. LLVM and clang are very interesting projects but changing compilers just because of one feature isn't smart. GCC is good enough in that area and the code it generates is amazing, it often beats every other C compiler out there. And that helps keeping readable code optimized.
How to convince any C developer to dump gcc and use clang
61–70 of 97 posts
Re: How to convince any C developer to dump gcc and use clang
#62Since when is it hard to find and correct syntax errors that are preventing your C code from compiling?
I can think of one example, heavy use of macros can create a syntax error nightmare. One of the projects I've worked on (I had inherited it without documentation) had some seriously obtuse nested macros that threw a spanner in the works at least once.
It's better not to use macros. Let the compiler optimize. If you really need more control use __inline. Debugging code generated from complex macros is close to impossible.
If you have to use someone else's macros you can use a wrapper function with exactly the same effects.
Also avoid #define constants not related to compilation or pre-processing themselves.
Readable code > unreadabe code. Same counts for compiled binaries.
Re: How to convince any C developer to dump gcc and use clang
#63you're saying I should port all my code just because the ui is more user-friendly? what about performance, options, special warnings, builtins, and everything else? I've been using gcc for a while now, and every time I use it I found a new feature. It's rock solid and had never let me down.
wow, just wow. how about read what clang actually is before posting?
[deleted]
Re: How to convince any C developer to dump gcc and use clang
#64Since when is it hard to find and correct syntax errors that are preventing your C code from compiling?
Why not make it easier if you can? Vagueness is hardly a virtue for a programming tool. Also, I don't think the ladies are impressed by your cryptic error fixing skills ;)
What this feature needs now is code correction on the fly. Any error reporter smart enough to ask "did you mean 'x'?" should allow me to answer "yes", and write the changes to the file. That would sell clang to a lot of people.
Re: How to convince any C developer to dump gcc and use clang
#65I use it as a static analyzer for iPhone projects and it creates a nice summary of issues (as linked to) on a web page
Same here - for missing retain/release calls (i.e., stupid memory leaks) it works great.
Re: How to convince any C developer to dump gcc and use clang
#66Earlier quoted context omitted.
"What would happen if the programmer got a list of error and started fixing from the end?" I always fix the first 1 or 2 reported errors and try to recompile. I assume everyone did. A traditional "report on errors which are actually there each time they happen" compiler will give you tons of completely spurious errors which happily disappear once you fix the first few. In the instance you point out, it could just use…
I usually try to fix as many errors as I can identify before recompiling. And yes, I usually fix from the bottom up, because that way my changes don't alter the line numbers of future fixes. On large projects, recompile time can be significant.
Yes, sure, large projects can take time to compile, but doesn't your compile environment just try to recompile the last file that it failed on during the build? That is, if in trying to build my app FooBar, and foo.c compiles ok but bar.c fails, when I try to run the build the next time having modified bar.c, it starts by trying to compile bar.c anyway... So I guess what I'm trying to say is that I don't understand the advantage you are apparently getting by woring from bottom up.
Re: How to convince any C developer to dump gcc and use clang
#67Earlier quoted context omitted.
"What would happen if the programmer got a list of error and started fixing from the end?" I always fix the first 1 or 2 reported errors and try to recompile. I assume everyone did. A traditional "report on errors which are actually there each time they happen" compiler will give you tons of completely spurious errors which happily disappear once you fix the first few. In the instance you point out, it could just use…
I usually try to fix as many errors as I can identify before recompiling. And yes, I usually fix from the bottom up, because that way my changes don't alter the line numbers of future fixes. On large projects, recompile time can be significant.
I think you need to upgrade you editor. For instance both vim & emacs are smart enough to adjust for inserts and removals.
Re: How to convince any C developer to dump gcc and use clang
#68Since when is it hard to find and correct syntax errors that are preventing your C code from compiling?
yeah, I'm thinking this might be more useful for c++ :)
In the meantime before clang fully supports C++ I would appreciate a flag for GCC that just gives me abbreviated error info:
file.cpp:65: error: please have a look at this line and see if anything jumps out at you.
Re: How to convince any C developer to dump gcc and use clang
#69Earlier quoted context omitted.
I can think of one example, heavy use of macros can create a syntax error nightmare. One of the projects I've worked on (I had inherited it without documentation) had some seriously obtuse nested macros that threw a spanner in the works at least once.
It's better not to use macros. Let the compiler optimize. If you really need more control use __inline. Debugging code generated from complex macros is close to impossible. If you have to use someone else's macros you can use a wrapper function with exactly the same effects. Also avoid #define constants not related to compilation or pre-processing themselves. Readable code > unreadabe code. Same counts for compiled b…
It's better not to inherit code. Meanwhile…
Re: How to convince any C developer to dump gcc and use clang
#70Earlier quoted context omitted.
I can think of one example, heavy use of macros can create a syntax error nightmare. One of the projects I've worked on (I had inherited it without documentation) had some seriously obtuse nested macros that threw a spanner in the works at least once.
It's better not to use macros. Let the compiler optimize. If you really need more control use __inline. Debugging code generated from complex macros is close to impossible. If you have to use someone else's macros you can use a wrapper function with exactly the same effects. Also avoid #define constants not related to compilation or pre-processing themselves. Readable code > unreadabe code. Same counts for compiled b…
No, you can't.
I have the following macro in a program I'm writing right now:
#define DEF(f)static A f##_n(A x);A f(A x){ \
return r1m(f##_n,x);}static A f##_n(A x)
Here's another one:
#define DEF(f)static A f##_n(void);A f(void){ \
static int d=0;static A x=0; \
if(unlikely(!d))d++,x=f##_n(); return x;} \
static A f##_n(void)
If I type this nonsense out for the 60 (or so) times its used, it is likely I'll make a typo that will be difficult to catch.
If I build the table at run-time (roughly the same amount of code), then I accept a run-time cost for something that will be called very frequently.
If I build a table at compile time and fill it at startup, then my program takes longer to start. Maybe if I put a splash screen up my users will forgive me, but that seems dishonest.
A long time ago, programmers did abuse macros as a kind of poor-compiler's inlining, and your advice is good for that: people shouldn't be doing that, and legacy code where it exists should be fixed.
However macros are great for composition. They can greatly improve the readability of some otherwise repetitive code, and while they can be used for evil, they could also be used to solve problems.