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.
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
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.
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?
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.
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.
++
... you mean code written specifically for GCC doesn't work as well in every case under a different compiler without the same shitty GCC quirks?!
WHAT IS THIS YOU SPAKE?
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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.