Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to convince any C developer to dump gcc and use clang

fseek.me

Post reply on HN
Print view View original

71–80 of 97 posts

Re: How to convince any C developer to dump gcc and use clang

#71

Post by wtallis »

ndl wrote: post #32

According to the clang home page as of March 7th 2010, "Clang's C++ support is currently alpha quality at best, but is evolving rapidly." Obviously, clang does not mean to attract C++ developers. For a while, I'd been adamant about developing in C and not C++. One day I discovered that I'd hand-coded a vtable in order to allow polymorphism in structures of function pointers. The next day, I halved the project complex…

The clang developers fully intend to support C++. It's just a more complex language, and as an Apple-supported project, C and Obj-C were higher priorities. clang itself is written in C++ and is self-hosting. I expect that by the end of next year, it will be able to handle Boost and any other reasonable C++ code.

Re: How to convince any C developer to dump gcc and use clang

#72

Post by pieter »

lolcraft wrote: post #64
brl wrote: post #13

Since 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.

there's a command-line option to do just that

Re: How to convince any C developer to dump gcc and use clang

#73

Post by pohl »

kvs wrote: post #2

Part of being a C developer (or C++ template) developer is in fact understanding what the compiler spits out. So, this did't convine me enough because "two or more data types" made me skip right a head to the definition of Point. :-) My point is Clang is good but friendly error messages is not the only reason I would change to Clang.

Would you be interested in a compiler where the error messages are more difficult to decipher, then? That way you could feel even more like you're a developer.

Re: How to convince any C developer to dump gcc and use clang

#74

Post by jbjohns »

megaduck wrote: post #28

As a dynamic language guy, I can't help but look at the static analysis here and feel a twinge of jealousy. There really isn't anything like this in the Ruby world. Some stuff is starting to emerge, but we're still largely dependent on tests to catch stupid mistakes. When I'm chasing down a bug, it would be nice to have a variety of tools to throw at the problem.

You don't have to have static typing to do type analysis. Look at what these guys are/were doing: http://www.strongtalk.org/

Re: How to convince any C developer to dump gcc and use clang

#75

Post by jws »

CrLf wrote: post #56
jws wrote: post #12

Earlier quoted context omitted.

Hardly proprietary. Apple gave the "block" patches to the gcc team. Gcc isn't interested in them, they are holding off for some future C++ syntax, though I don't see how that helps C programmers. Meanwhile, I got seduced by gcc's nested functions which are not supported by clang. Apparently they are non-trivial in clang so won't appear soon if at all. Two incompatible mechanisms for function decomposition are annoyin…

"Gcc isn't interested in them, they are holding off for some future C++ syntax, though I don't see how that helps C programmers." You are assuming that C programmers need to be helped. The beauty of C lies in its simplicity, not in its features. That's what has kept C alive to this day despite its shortcomings, and despite the existence of C++. C does not need new constructs. C needs to be kept as simple and as close…

Closures in C make me uncomfortable, but lexically scope subfunctions are just syntax that serve two functions for me.

First: organization. If I grab a chunk of function and put it in nicely named subfunction, even if it is only called once it lets me keep each function to a nice size. This could be done with a static function, but then you always have to think: "What else in this file might call this function?"

Second: (And much more empowering) Gathering together repetitious code can be cleaner. Consider implementing some network protocol. You will probably have a "get next byte from buffer" function which will need access to the buffer, the current position, the number of valid bytes in the buffer, and who knows what else. You could make this a static function and pass all the arguments in, correctly, each time and if you only need a single value back that works. With a lexically scoped subfunction you can just reference these in the outer scope and if you need to set an error condition or message just set it in the outer. Very clean. No scary runtime code.

Re: How to convince any C developer to dump gcc and use clang

#76

Post by j_baker »

matthavener wrote: post #15
brl wrote: post #13

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

I wouldn't hold out for any miracles. I think that there are several aspects of the language itself that will make improving error messages difficult. In particular, template error messages are probably without much hope.

Re: How to convince any C developer to dump gcc and use clang

#77

Post by alecco »

geocar wrote: post #70
alecco wrote: post #62

Earlier quoted context omitted.

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) Turning this into a function is impossible: functions can't define functions in C. 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) Ignorin…

That's a good exception to the rule, but you have to admit it's not common.

I don't know the context of that source, so I can't make a proper reply to how to work around that. Is it really necessary to put it in the pre-processor? Does it change that often? Perhaps you can script it before pre-processing and compiling. It depends a lot on the design's context, this is probably a bad guess but the point is more often than not there are ways to avoid or minimize macro-hell scenarios, IMHE.

Re: How to convince any C developer to dump gcc and use clang

#78

Post by geocar »

alecco wrote: post #77
geocar wrote: post #70

Earlier quoted context omitted.

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) Turning this into a function is impossible: functions can't define functions in C. 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) Ignorin…

That's a good exception to the rule, but you have to admit it's not common. I don't know the context of that source, so I can't make a proper reply to how to work around that. Is it really necessary to put it in the pre-processor? Does it change that often? Perhaps you can script it before pre-processing and compiling. It depends a lot on the design's context, this is probably a bad guess but the point is more often…

I suppose it's a matter of taste, and I just look at C-style macros as a means to an end.

I suppose I think the fact it's not more common has to do with this knee-jerk reaction to avoid macros like some kind of plague.

Regarding your other point, I agree: at a certain point hacking up the DSL in perl or lisp is going to give enough greater flexibility that it's going to be worth the additional complexity (to the build system, documentation, programmer-requirements, etc).

Re: How to convince any C developer to dump gcc and use clang

#80

Post by eru »

riffraff wrote: post #47
sruffell wrote: post #41

Earlier quoted context omitted.

I spend most of my time writing C code, but like to work with Python when I get the chance. There isn't anything like pylint for Ruby? A dynamic runtime doesn't necessarily mean you have to give up static analysis.

roody, rufus, reek, flay, flog, probably more. Sadly, in the current state of the ruby community it's even hard to find a library that will run with ruby's own warnings enabled.

Isn't clean code valued in the Ruby community?

As a contrast, I had the impression that the Python guys care more about this in their code. They also avoid eval and other runtime code generation. (Though I do not if that's related.) It seems these two languages are further apart than in their culture than anything else.

Post reply on HN