Slashdot Mirror
Developing In C/C++? Why You Should Consider Clang Over GCC (dice.com)
Nerval's Lobster writes: The idea with Clang, a compiler front-end for C, C++, Objective-C++, and Objective-C, and LLVM (a compiler infrastructure) is that you can mix the compiler front-end with a targeted back-end and end up with highly portable and efficient compiler. Clang can perform static analysis of your code, and lets you write tools that give you information about a program. Although many developers prefer developing in C/C++ using GCC, developer David Bolton (in a new Dice article) makes an argument for why you should switch to Clang. While GCC is probably still best when it comes to speed, he argues, Clang is improving release by release, and features tools that developers could find useful.
While GCC is probably still best when it comes to speed, he argues, Clang is improving release by release, and features tools that developers could find useful
Translation: "network tran--I mean speed is a feature that most of our users don't need, so it's not in our development plan"
Compile in both. And visual studio too if possible. Enable all warnings. They are all good at identifying different categories of problems and code that compiles cleanly under multiple compilers will prove easier to maintain.
I strongly recommend Clang. It's speed is about on par with GCC, but the output and syntax checking is so much better. I tried it a bit a few years back and I have been hooked on Clang since. Using GCC feels like a big step backward now because it's so fussy and its warnings are so cryptic in comparison.
When people say gcc beats clang on speed, so they mean compile speed or run-time speed?
If I can be modded down for being a troll, can I be modded up for being an orc, or a balrog?
One neat thing about LLVM/clang is that theoretically you could provide your application as IR files, which can be flattened to machine-specfic code on the fly by a platform-specific backend.
I think at some point it was fast enough to generate that code on the fly. I vaguely remember Apple doing that with its OpenGL stuff.
To make sure my code is not using any compiler features I compile my code on both.
...is available. It's not that hard and it's good practice in any case. So long as whatever compiler is available works, who cares about the specifics?
If you have stuff that depends on compiler oddness and can't be removed/rewritten then just coral that into as small an area as possible and hedge it if #ifdefs.
Does Clang compile to intermediate formats, such as Bytecode or any other formats? On the GCC side, I believe that the FSF (read RMS) is opposed to it
Isn't LLVM/clang all about the license (non-GPL)? Otherwise if clang is good, then we should fork it and make a GPL version of it.
From up-close-and-personal experience with Objective C and C++ (also Smalltalk), these languages have substantially different semantics regarding class identity (primarily: what version of overridden member functions you get) during construction and destruction. I wouldn't be surprised if Objectivce-C++ had yet another semantics, pulling "features" from both, and I have no clue about LVMM.)
Building a frontend to compile to them, interchangeably, is a recipe for subtle bugs, if the frontend doesn't deal with these issues. Efficiency may go out the window if the frontend tries to impose one language's construction/destruction semantics on another. Doing so also brings up the issue of which semantics the compiler exposes to the programmer - each has its good and bad points, and each enables different - and incompatible - useful programming features.
I'd be interested in what (if anything) Clang has done about this issue. (Unfortunately, I'm busy on other stuff, so I'll have to depend on others to elucidate this.)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
While C, C++ and even Objective-C have multiple implementations, how the fuck are we supposed to do that with a language like Rust, where there is only one implementation?!
First of all, C and C++ are two different and separate languages.
Second of all, if you are developing in either C or C++, you should develop in a different language.
WTF? the article is a few paragraphs that read like an advertisement.... meh
Sure, I can spend who knows how much time trying to get it to compile myself and install it my home dir, but then I can't ship binaries compiled with clang.
And I've never had much luck getting clang to compile using gcc c++ stdlib and link against the gnu c++ libs. I suppose I could just statically link against c++ stdlib though.
I would think that if these subtle bugs exist they'd be caught by the test suites. Do you have any actual evidence of these subtle bugs?
Clang has issues with Win64. There was a bug that was around for a while with the io library's tellg function that was preventing us from using it. Now there's all sorts of issues with flags we're dealing with
So what about the fact that GCC supports a bunch of different languages, too? It sounds as if you are saying that Clang is risky because of supported language impedance, but GCC has the same issue. If the real fear is that Clang is new, then I guess Ths Devil You Know is better, eh?
Once I checked, clang was not good at generating vector instructions from simple loops. Unless it has improved lately, that would be a show stopper for a class of code.
I've done POSIX C++ programming for five and a half years. I compile on my mac using clang and on my ubuntu machine using g++. Here's the differences: 1. Clang seems to have better error messages. 2. Of course, clang is usable using libraries (rtags for emacs lets you do ctags but way better for example). 3. Run speed is about the same for optimized build between the two. They're within 1% for our application using the benchmarks for it. 4. Compile speed is a bit faster using clang. I like having two big compilers that compete with each other. It forces both to try harder and to become better compilers in the end.
Why would I care about an alternative compiler when ccache takes care of most of the GCC speed cost anyway? My personal project's edit-compile-test cycle is down to something like 45 seconds these days, and all but maybe 1-2 are the test suite where many tests use 20ms sleeps to cause ordering.
Why would I care about the micro-level speed of the program in an era where computers have been fast enough for most of a decade already? Certainly for ARM, Atom, etc. low-power targets there's advantage in being fast -- but again, that's a matter for data structures and algorithms, not micro-level tweaking. If a compiler can optimize a program to greater gains than a performance-oriented, benchmark-guided refactoring, then the program must already have been close to optimal -- and realistically that won't happen until the underlying operating system and user-space middlewares are also optimal.
I do appreciate the parallel research that clang embodies, and the static analyzer for being another tool in my kit. But to replace the GCC of 2015, clang's got about a decade to go still.
Knock yourself out! Go make your own GPL branch of an active project that large companies actively develop and see how successful it is.
Then, for real, go knock yourself out.
Preferably with a hammer. Don't worry, as best I can tell it won't affect your intelligence.
So you could write a tool against LLVM that looks to see which templates are causing problems, maybe output the usage graph to graphviz to help refactor your code...
My Other Computer Is A Data General Nova III.
I periodically run both just to get the warnings that each is able to provide. And I clean up all warnings, even if I know that they are harmless, so I won't miss a blunder buried in the noise. Turning on all warnings has saved me from having to chase down more bugs than I care to admit. gcc *.c -o xxx -O -Wall -Wextra -Wmissing-prototypes \ -Wmissing-declarations -Wshadow -Wpointer-arith -Wcast-align \ -Wredundant-decls -Wnested-externs -Winline \ -Wno-long-long -Wconversion -Wstrict-prototypes -ansi -pedantic clang *.c -o xxx -Wall -Wextra Any other warnings you'd recommend?
If you bother to actually follow the link it shows gcc producing faster code except in the artificial benchmarks he cherry-picked on page two.
>better error messages, warnings, and static analysis from Clang. Those save me way more time than the speed of the compiler.
This is the truth. Ain't nobody got time to read through a hundred lines of error messages to track down a single bug.
As a simple test, I wrote the following code which has a simple mistake (using an integer instead of an int array in a range-based for loop):
test.cc:
#include
int main() {
int x = 0;
for (int i: x) std::cout constexpr const _Tp* std::end(std::initializer_list)
end(initializer_list __ils) noexcept"
2 lines for a single straightforward error in clang++ 3.7 (with colors even!):
"test2.cc:5:12: error: invalid range expression of type 'int'; no viable 'begin' function available
for (int i: x) std::cout i;"
I currently use g++ with new programmers, and will be switching soon to clang++.
Plus Clang does cool things like interoperate with things like YouCompleteMe to do real time compiling and error message generation for syntax completion in VIM.
From up-close-and-personal experience with Objective C and C++ (also Smalltalk), these languages have substantially different semantics regarding class identity (primarily: what version of overridden member functions you get) during construction and destruction. I wouldn't be surprised if Objectivce-C++ had yet another semantics, pulling "features" from both, and I have no clue about LVMM.)
Objective-C++ mixes the syntax of the two languages, and allows you to use either a C++ object or an Objective-C object at will, however it does not make C++ objects into Objective-C objects or vice versa. Any semantics relating to C++ objects still applies to C++ objects, and no additional semantics are implied.
In short: things work as you'd expect, and there are no hidden gotchas.
The only real complexities are what happens when you embed a C++ object as a member inside an Objective-C object (this doesn't change the semantics of the C++ object itself, but obviously may change the point at which the whole thing is destroyed) and what happens when you reference an Objective-C object from within a C++ object (some of the automatic refcounting syntactic sugar goes away and you have to actually understand what you're doing.) These don't introduce difficulties for the compiler, but could potentially be confusing for the programmer.
I'm sure clang has its fair share of bugs, and I'm sure that GCC does also, that's just the nature of any complex codebase. The shared backend isn't really a contributing factor, any more so than them both emitting x86 machine code is a contributing factor.
I care how fast my compiler compiles (as long as it's not insane) about as much as I care how fast my system boots (as long as it's not insane).
Seriously. Whatever planet you weird devs came from, can you return to it? (And take Lennart with you?)... Spend your free time re-optimizing your cut-and-paste chef recipes or something, and leave the engineering to the rest of us?
Hire a Linux system administrator, systems engineer,
while clang is probably fine for most projects, if your project needs -std=c++14 then you should be warned that sometimes Clang can't properly deduce (even when you are explicit) variadic template parameters.
for example, this code will not compile on Clang no matter what but works fine with G++.
template<typename... ArgTypes> using deeper = void(*)(ArgTypes...);
template<typename... ArgTypes> void shallow(deeper<ArgTypes...> arg) { }
int main(int argc, char* argv[])
{
deeper<int> arg;
shallow<int>(arg);
return 0;
}
Anons need not reply. Questions end with a question mark.
the guy who developed clang - Chris Lattner - also wrote swift.
he first modernized the architecture of the compiler, and then wrote a better language on top of it that is capaable of doing system level things like C++ with a cleaner semantic style.
++
If I wanted to read dice, I would actually go to dice.com, no /.
Linus tried clang for the Linux kernel, and it generated terrible code for certain constructs the kernel depends on AND compiled a bit slower.
They have some way to go.
The backend code generation has nothing to do with frontend class and objects semantics, this is not .Net runtime. AFAIK the point of LLVM is not mixing different frontend languages in single backend output, just the ability to combine frontend languages with backend generators for various CPU architectures.
So the new thing about clang is that it works with an intermediate language to allow the front and back ends to optimize cleanly? I thought gcc is also doing this with the GIMPLE/GENERIC layer -- can anyone explain what's the difference?
For this reason exactly, my debug builds are with Clang and release builds are with gcc. All the bells and whistles of static analysis and nice error messages from clang, and all the speed of gcc. No need to choose one over another when you can have both.
How exactly is a compiler related to development?
Compiler takes part in the deployment phase. It may also throw some warning, so that would be useful for code-review phase. Where exactly is the development here?
Development is something that happens in your mind. All you need for development is a text editor. May come in with syntax highlighting and code completion, but that's all.
And here is your problem: you think you 'develop' by writing some code and then using a compiler to check if it works. This is exactly what a bad programmer would do. This is what code-monkeys do.
And because of this you all end up like that: 'Learn C, instead of just stringing random characters together until it compiles (with warnings).' -- Linus Torvalds https://lkml.org/lkml/2015/9/3/428
Using the compiler is the very last part of development, just to fine-tune your code. And then to release it, but that's called deployment.
So it doesn't really matter which one you use for *development*. Or you are doing it wrong.
Can Clang compile the Linux Kernel?
How about writing code that runs well on both compilers?
You should be using precompiled headers
Until the headers themselves change, causing a cascade throughout all source files that instantiate a class or its subclasses because of C++'s fragile base class tendency.
and set up your makefiles for multiple cores.
There are known limits of GNU Make when you have a single program that spits out more than one file. For example, a graphic may be converted for use on a particular platform by decomposing it into a tile file and a map file. Or a collection of documents may be compressed into a static dictionary and a (separate) archive of the compressed documents. The problem is that Make will often try to run the program twice at once, once to produce the tile file and once for the map file, wasting CPU. What's the typical workaround? Is it a good practice to have the program generate an archive file containing both files, and then generate the tile file and map file by extracting them from the archive file?
Besides, link-time whole-program optimization doesn't parallelize nearly as well.
So instead of compiling and linking the entire application repeatedly as you track down a bug, you only integrate after all your unit tests are written and passed in isolation.
Which doesn't help when the bug is in the integration.
For any type with a size less than 29 bits the behavior is undefined. [...] For signed types it is implementation defined.
But what is it for uint32_t x = 0xdeadbeef;?
you just cannot implement an efficient garbage collector in C/++.
Then what's std::shared_ptr if not an efficient reference counting garbage collector?
The fact that you have to install a cross-compiler for that particular (language, architecture) pair. For some less popular architectures, compilers accepting languages other than a handful (C++, C, and possibly Fortran) happen not to exist.