Things that go Clang in the night: LLVM 2.4 released (ars technica)

[Posted November 13, 2008 by corbet]

Here's a look at the LLVM 2.4 release on ars technica. "One very significant part of the LLVM effort is the Clang project, which aims to build a completely new LLVM front-end - one that can be used in place of the current GCC-based front-ends - for C-like languages. Clang is progressing rapidly and is already capable of compiling some C applications. Clang offers a lot of really compelling advantages over GCC. Some early benchmarks show that it delivers insanely fast compilation and much lower memory overhead. In some real-world tests, Clang is 2.5 times faster than GCC and uses five times less memory. It also uses less disk space during the compilation process."

to post comments

Overly Hyped

Posted Nov 13, 2008 16:53 UTC (Thu) by clugstj (subscriber, #4020) [Link] (16 responses)

This reminds me of an article from some months ago where someone was writing a replacement for the "ld" command. People were gushing about it being faster, smaller, other "compelling advantages". The actual facts of the matter were that what it did was a very narrow subset of the actual capabilities of GNU "ld" (only supported the x86 ISA, only supported the ELF file format). This seems to be much the same. All this talk about speed of compilation, compiler memory usage, but nothing about how the generated code runs.

I have no problem with anyone writing replacements for tools, but lets lay off the hype unless the new tool can actually replace the old one in some real-world situations.

Overly Hyped

Posted Nov 13, 2008 17:43 UTC (Thu) by jbailey (guest, #16890) [Link]

What, you're saying you wouldn't be happy if you discovered that the only functioning backend was Logo? =)

Overly Hyped

Posted Nov 13, 2008 17:51 UTC (Thu) by JoeBuck (guest, #2330) [Link] (1 responses)

Ian Taylor's "gold" linker currently only supports ELF/x86 and ELF/x86_64. Adding back ends for more ISAs should not be difficult, but supporting object file formats other than ELF would be much harder; to quote Ian's announcement, "There is no expectation that gold will ever support anything other than ELF targets."

Overly Hyped

Posted Nov 13, 2008 22:24 UTC (Thu) by andikleen (guest, #39006) [Link]

It supports sparc64 too now.

Overly Hyped

Posted Nov 13, 2008 18:40 UTC (Thu) by darthscsi (guest, #8111) [Link] (6 responses)

Interprocedural optimization of an entire linux kernel not enough for you (SOSP2007, though actually that was just a side effect of making the kernel memory safe (e.g. no buffer overflows, etc))? JITing of per-application OpenGL stacks (MacOS)? Compiling iPhone Apps? JITing image processing routines optimized for the specific image and combination of transformations (adobe). C to flash translation so you can run C programs (including bash, python, and nintendo enumlators) in a browser (adobe)? These are not real enough workloads for you? Most of those are shipping.

Overly Hyped

Posted Nov 13, 2008 19:51 UTC (Thu) by clugstj (subscriber, #4020) [Link] (5 responses)

Sorry, I've got to call Bullshit on this. If there were a compiler for the linux kernel that was as wonderful as you say, all the kernel developers would be using it.

Overly Hyped

Posted Nov 13, 2008 23:58 UTC (Thu) by darthscsi (guest, #8111) [Link] (4 responses)

Go ahead and call bullshit. Let me refer you to:
http://portal.acm.org/citation.cfm?id=1294295
for the linux kernel, and other users:
http://www.tungstengraphics.com/wiki/index.php/Gallium3D#...
http://www.osnews.com/story/15530/LLVM-at-Apple-the-OpenG...
http://www.ipodobserver.com/story/30184
http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/11
http://www.ffconsultancy.com/products/ocaml_journal/?llvm
http://ajaxian.com/archives/llvm-and-running-c-as-well-as...

Oh and back to the kernel...

llvm-gcc -Wp,-MD,arch/x86/kernel/.ioport.o.d -nostdinc -isystem ~~/cfe/install/bin/../lib/gcc/i686-pc-linux-gnu/4.2.1/include -D__KERNEL__ -Iinclude -I~~/Applications/linux-2.6.27.5/arch/x86/include -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -O0 -m32 -msoft-float -mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2 -march=i686 -mtune=pentium2 -mtune=generic -ffreestanding -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Iinclude/asm-x86/mach-generic -Iinclude/asm-x86/mach-default -fno-stack-protector -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -Wdeclaration-after-statement -Wno-pointer-sign -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(ioport)" -D"KBUILD_MODNAME=KBUILD_STR(ioport)" -c -o arch/x86/kernel/ioport.o arch/x86/kernel/ioport.c

llvm-gcc -Wp,-MD,arch/x86/kernel/.ldt.o.d -nostdinc -isystem ~~/cfe/install/bin/../lib/gcc/i686-pc-linux-gnu/4.2.1/include -D__KERNEL__ -Iinclude -I~~/Applications/linux-2.6.27.5/arch/x86/include -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -O0 -m32 -msoft-float -mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2 -march=i686 -mtune=pentium2 -mtune=generic -ffreestanding -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Iinclude/asm-x86/mach-generic -Iinclude/asm-x86/mach-default -fno-stack-protector -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -Wdeclaration-after-statement -Wno-pointer-sign -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(ldt)" -D"KBUILD_MODNAME=KBUILD_STR(ldt)" -c -o arch/x86/kernel/ldt.o arch/x86/kernel/ldt.c

llvm-gcc -Wp,-MD,arch/x86/kernel/.setup.o.d -nostdinc -isystem ~~/cfe/install/bin/../lib/gcc/i686-pc-linux-gnu/4.2.1/include -D__KERNEL__ -Iinclude -I~~/Applications/linux-2.6.27.5/arch/x86/include -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -O0 -m32 -msoft-float -mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2 -march=i686 -mtune=pentium2 -mtune=generic -ffreestanding -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Iinclude/asm-x86/mach-generic -Iinclude/asm-x86/mach-default -fno-stack-protector -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -Wdeclaration-after-statement -Wno-pointer-sign -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(setup)" -D"KBUILD_MODNAME=KBUILD_STR(setup)" -c -o arch/x86/kernel/setup.o arch/x86/kernel/setup.c

just to pick out something scrolling by my screen right now (Paths slightly mangled for privacy). (The llvm knowledgeable will recognize that this build is not doing IPO, but see the SOSP07 paper where complex interprocedural analysis and transformations were performed on the entire kernel).

Overly Hyped

Posted Nov 14, 2008 2:41 UTC (Fri) by clugstj (subscriber, #4020) [Link] (2 responses)

Please read the comment to which you are replying. The article is about something called "Clang" that is to replace the GCC-based front end to LLVM. You are apparently not using "Clang" because your command line begins with "llvm-gcc". So what you are hyping is not actually what the article was about.

Overly Hyped

Posted Nov 14, 2008 3:41 UTC (Fri) by darthscsi (guest, #8111) [Link] (1 responses)

Please read the article, the article is about the llvm 2.4 release. Clang is an in development sub-project of that. I am quite aware that I am using llvm-gcc and not clang. But neither the complaint about the hype (and implication that it is thus not worth looking at) nor the original article are about Clang, they are about llvm. The ability to do IPO on large projects with llvm is not dependent on the C frontent (clang or llvm-gcc) you are using.

Overly Hyped

Posted Nov 14, 2008 18:54 UTC (Fri) by clugstj (subscriber, #4020) [Link]

Funny, "Clang" is the 4th word in the title of said article.

Overly Hyped

Posted Nov 20, 2008 14:24 UTC (Thu) by Nelson (subscriber, #21712) [Link]

Is that actually compiling the kernel code with LLVM? The man pages are a bit confusing, aren't the -S and -emit-llvm options required? It's not clear to me if that's just normal GCC or LLVM without the link time options.

Overly Hyped

Posted Nov 13, 2008 22:01 UTC (Thu) by wmf (guest, #33791) [Link] (1 responses)

> People were gushing about it being faster, smaller, other "compelling advantages". The actual facts of the matter were that what it did was a very narrow subset of the actual capabilities of GNU "ld"...

Another way to look at it is that many open source projects are being held back by support for obscure platforms with few users. Concentrating on Linux/x86 could speed development of these projects for the majority of mainstream users.

Overly Hyped

Posted Nov 14, 2008 0:32 UTC (Fri) by SLi (subscriber, #53131) [Link]

Yet another view that I've seen in practice: While support for multiple
architectures and obscure devices sometimes are a pain, often they also
increase the quality of the code by forcing people to think about
abstractions. Good examples would be Linux and NetBSD.

Overly Hyped

Posted Nov 14, 2008 0:38 UTC (Fri) by jwb (guest, #15467) [Link] (1 responses)

Well there are actually lots of papers about how well llvm's generated code performs. I read one regarding the llvm php project that was only about 100x slower than the regular php interpreter ...

Overly Hyped

Posted Nov 14, 2008 6:11 UTC (Fri) by nhippi (subscriber, #34640) [Link]

The point of the php project was to test how fast it takes to write a LLVM based php JIT compiler. It took two days.

Ofcourse something written in two days isn't going to be optimized at all, or be any kind of competition PHP's zend engine which has been tuned for 10 years...

Overly Hyped

Posted Nov 20, 2008 18:15 UTC (Thu) by jzbiciak (guest, #5246) [Link]

In the comparison between GCC's C and C++ frontends and Clang, Clang is smaller and faster and more reusable. Is that what you're complaining about? That it doesn't support non-C-like languages?

g77, gfortran, GNAT, etc. are all different front ends. Nothing stops LLVM from getting front ends for those languages at some point.

Overly Hyped

Posted Nov 21, 2008 19:39 UTC (Fri) by lysse (guest, #3190) [Link]

> I have no problem with anyone writing replacements for tools, but lets lay off the hype unless the new tool can actually replace the old one in some real-world situations.

Like, for example, linking ELF-format x86* binaries? Or are you using "some" as a synonym for "all" in this instance?

Things that go Clang in the night: LLVM 2.4 released (ars technica)

Posted Nov 13, 2008 17:15 UTC (Thu) by saffroy (guest, #43999) [Link] (8 responses)

"Another important bonus of using Clang and LLVM instead of GCC is that the former is better able to identify and articulate where problems are in code. The intermediate format it uses is much closer to the original code, so it can tell developers a lot of things that GCC cannot."

To me, this is a much more important feature than compiler speed. The usual C error messages can be so painfully cryptic, even for trivial stuff.

Things that go Clang in the night: LLVM 2.4 released (ars technica)

Posted Nov 13, 2008 19:43 UTC (Thu) by asamardzic (guest, #27161) [Link] (4 responses)

The usual C error messages can be so painfully cryptic, even for trivial stuff.

Heh - and how about C++ error messages, especially when so called "template meta-programming" crap employed? Although, I guess no compiler could emit sane error messages there...

Things that go Clang in the night: LLVM 2.4 released (ars technica)

Posted Nov 13, 2008 20:24 UTC (Thu) by ncm (guest, #165) [Link] (3 responses)

The problem with C++ error messages is that the compiler isn't told enough about the library programmer's intentions for it to explain usage problems to users of the library. A new feature of C++09, due out next year, called "concepts", will enable library writers to tell the compiler enough so it can produce short, helpful error messages for mistakes in calls to the library.

Things that go Clang in the night: LLVM 2.4 released (ars technica)

Posted Nov 14, 2008 0:14 UTC (Fri) by dlang (guest, #313) [Link]

unfortunantly the standards track is runninng slowly, the new standrd probably won't make it out next year

Things that go Clang in the night: LLVM 2.4 released (ars technica) [offtopci]

Posted Nov 20, 2008 17:34 UTC (Thu) by Frej (guest, #4165) [Link] (1 responses)

I keep wondering why they called it concepts instead of interfaces?

Things that go Clang in the night: LLVM 2.4 released (ars technica) [offtopci]

Posted Nov 20, 2008 22:58 UTC (Thu) by nix (subscriber, #2304) [Link]

It's a term from the STL, which predates Java, where it's not an interface
so much as a set of behavioral guarantees: I'm fairly sure that a Java
interface couldn't express what an STL concept can. (Now I will shut up
and let ncm, an actual C++ expert rather than a poseur like me, tell me
I'm full of crap. I expect I am.)

Things that go Clang in the night: LLVM 2.4 released (ars technica)

Posted Nov 13, 2008 20:53 UTC (Thu) by robert_s (subscriber, #42402) [Link]

To me, the more interesting thing about clang is, due to its library nature, it should encourage and facilitate tighter integration with development tools to show problems in a more more intuitive way.

Things that go Clang in the night: LLVM 2.4 released (ars technica)

Posted Nov 13, 2008 23:21 UTC (Thu) by aleXXX (subscriber, #2742) [Link] (1 responses)

Hmm, I don't see a problem with gcc's error messages. Maybe this is also
because I'm used to them and know what they mean.
OTOH when I saw MSVC error messages these seemed very cryptic to me.
I'd say it's a matter of being used to them or not.

Alex

P.S. yes, template error messages are more or less unreadable

Things that go Clang in the night: LLVM 2.4 released (ars technica)

Posted Nov 14, 2008 8:29 UTC (Fri) by mjthayer (guest, #39183) [Link]

With a bit of practice even GCC's template errors are readible. You do need to upgrade your internal parser a bit though :)

Things that go Clang in the night: LLVM 2.4 released (ars technica)

Posted Nov 13, 2008 20:54 UTC (Thu) by Ed_L. (guest, #24287) [Link] (1 responses)

"LLVM still doesn't support as many architectures as GCC, and Clang's C++ support is still at an early stage."

I think it safe that no compiler will ever support as many architectures as GCC. Unless it replaces GCC completely, of which there is no immediate danger. Clang's C++ shortcoming is another story; good thing LLVM has GCC's C++ front end to tide them over. Good C++ front ends are not trivial to come by. This may take awhile.

Things that go Clang in the night: LLVM 2.4 released (ars technica)

Posted Nov 13, 2008 23:59 UTC (Thu) by wmf (guest, #33791) [Link]

GCC is never going away, but I could imagine it being marginalized as "the embedded compiler" while Clang takes the OS X/Linux desktop/server/HPC markets.

C++

Posted Nov 13, 2008 22:15 UTC (Thu) by avik (guest, #704) [Link] (39 responses)

Unsurprisingly, this is written in C++. The attitude of many open source developers, that C++ is a bunch of crap that does things behind the programmer's back is really holding development back. People spend their time doing things the language should be doing and getting bogged down in details.

I'm not saying using C++ will automatically result in better, faster code; but using C will automatically increase the amount of effort that has to go into making robust, efficient, and maintainable software. Using C++ allows focus on the algorithms rather than implementation details.

C++

Posted Nov 13, 2008 22:59 UTC (Thu) by deepfire (guest, #26138) [Link] (22 responses)

The problem with C++ is that it's neither meat, nor fish.

It's not an unencumbered portable assembly for reusable library building (yeah, mangling), and neither it is a proper high-level language. It's something forever stuck in between, a static, insanely cornercased language with no obvious reason for existence other than "to vaguely reminisce of C".

If you claim that "focus on algorithms rather than implementation details" is your reason to go away from C, then, clearly, C++ is a wrong choice.

C++

Posted Nov 14, 2008 0:42 UTC (Fri) by ncm (guest, #165) [Link] (1 responses)

Whatever reasons anyone advances for it, the Clang project's choice was, manifestly, C++. If you don't understand the choice, it tells us more about your state of knowledge than about the language.

People actually building things that have to work well aren't much concerned about how "pure" a language is: they want to use whatever best helps them get their work done, with a minimum of fuss, bother, and risk. Among the alternatives available, it's not hard to choose. No successor to C++ is anywhere on the horizon, except for C++09 itself.

A language equally as powerful as C++, but much simpler, is certainly possible in principle. Part of the reason no seriously considerable replacement for C++ is in the works anywhere is that academia is the only remaining milieu capable of nurturing a new language, but academic computer scientists are, as a rule, actively hostile to concerns of industrial programmers. Working on a plausible successor would be death to one's academic career.

C++

Posted Nov 14, 2008 5:46 UTC (Fri) by bins (guest, #49492) [Link]

""A language equally as powerful as C++, but much simpler, is certainly
possible in principle.""

yeah and it is called D.

C++

Posted Nov 14, 2008 0:55 UTC (Fri) by qg6te2 (guest, #52587) [Link]

One has to understand the choices made in C++, otherwise the same stuff just gets reinvented in C, albeit less readable (e.g. the GTK+ toolkit). Granted, C++ is not as quick to learn as C, but the extra time to learn it more than makes up through decreases in coding time.

Each line of C++ code tends to do more, hence the probability of making bugs decreases. Old empirical estimates have a ball-park figure of 2.5 C lines for 1 C++ line. This multiplier can probably be safely revised upwards if one considers the heavy use of the standard C++ library (and/or Boost libraries) in modern code.

C++

Posted Nov 14, 2008 1:13 UTC (Fri) by robert_s (subscriber, #42402) [Link] (18 responses)

"It's not an unencumbered portable assembly for reusable library building"

Why not? The only feature that I would say "does things behind your back" in c++ is virtuals. And if you don't want virtuals to be used, don't use them.

(However, implementing the same functionality yourself in C would be much more fugly and almost certainly less performant.)

Virtuals are minor problem

Posted Nov 14, 2008 5:59 UTC (Fri) by khim (subscriber, #9252) [Link] (17 responses)

The only feature that I would say "does things behind your back" in c++ is virtuals.

Sorry, but that's not true. C++ can add generate elaborate code when programmer is using innocent assignment: A=B can mean network/disk access and more! Heck, empty closing "}" can mean network/disk access and more!

And it's not easy to disable such features: people are using them all the time and there are no compiler switch to warn about them. C is simpleminded, C++ is treacherous. It's simpler to write C++ program but it's much harder to read C++ program - and that's big issue...

Virtuals are minor problem

Posted Nov 14, 2008 8:30 UTC (Fri) by nix (subscriber, #2304) [Link] (2 responses)

Both the examples you provide would involve bad code. I'd suggest that
people can write bad code in any language. Plus, most of the examples you
provide are consequences of things that allow very powerful and clear
coding styles when used correctly. e.g. the } 'executing code', a very
peculiar way to describe going out of scope calling destructors, is the
thing behind RAII, which is how C++ manages to avoid all those bloody
nasty explicitly-called close() methods Java is littered with, and the
primary way to avoid resource leaks without having to do *anything*
special. Is avoiding resource leaks a bad thing? I don't think so.

(What *is* nastier is exception handling, simply because exceptions can
emerge from so many places that it is still unknown how to safely handle
all of them while keeping your system's state consistent. This is largely
an academic concern, but still it *is* a concern.)

Virtuals are minor problem

Posted Nov 14, 2008 12:34 UTC (Fri) by mjthayer (guest, #39183) [Link] (1 responses)

I thought that the accepted treatment of exceptions was to only throw one if things are messed up beyond repair, and when one is thrown to abandon ship in the subsystem it occurs in. Then the only consistency you have to ensure is that resources are freed, which is what the "} executing code" thing is there for.

Virtuals are minor problem

Posted Nov 14, 2008 19:48 UTC (Fri) by nix (subscriber, #2304) [Link]

Yes, indeed: but the *reason* why 'abandon ship' was adopted was that
fine-grained management of exceptions is too hard.

Virtuals are minor problem

Posted Nov 14, 2008 8:42 UTC (Fri) by mjthayer (guest, #39183) [Link]

What you describe is not a problem if you use libraries that you know properly. The you will know what happens if you write A=B and }. It is just that a C programmer is used to the fact that a function will not be called "=" (and will be called as a function, not as an operator). And is not used to the fact that by creating an object you are also making a call to its destructor. Of course, it is very easy to use these features to make code unreadable, but as I said, use libraries that you know (and that don't do nasty things) - a badly designed C library can also make for confusing and unreadable code.

Virtuals are minor problem

Posted Nov 14, 2008 11:10 UTC (Fri) by epa (subscriber, #39769) [Link] (10 responses)

A=B can mean network/disk access and more!

This is true in C too, if you #define A.

True, but how often it happens?

Posted Nov 14, 2008 11:28 UTC (Fri) by khim (subscriber, #9252) [Link] (9 responses)

This is not question about "can I do it in theory". This is more like "does it happen in practice". While it's easy to lose track of what happens where in C program it's infinitely easier to do so in C++ with all these RAII, operator overloading and so on.

Now, I'm not saying it's such a bad thing (I like Python, for example, and it's even easier to do there), but that way beyond "unencumbered portable assembly for reusable library building" - that's for sure...

True, but how often it happens?

Posted Nov 14, 2008 13:04 UTC (Fri) by epa (subscriber, #39769) [Link] (8 responses)

I don't see why libraries must be built in 'unencumbered portable
assembly'... surely what matters is that they be robust, present a clean
interface, and be fast enough. If you are writing a library to provide
arbitrary precision arithmetic, for example, it would certainly be a big
disadvantage to make the user write xyz_assign(&a, xyz_multiply(b, c))
instead of a = b*c. The same applies for a library providing hash tables:
surely it is much better that the hash table clean up its resources when it
is destroyed. A main design goal of C++ was to provide a good language for
building reusable libraries, a better alternative to C for this task.

I suppose you would call C++ unencumbered, if you care about that, because
you don't pay for anything if you don't use it. The same code for calling
the multiply function or freeing memory would have to be written anyway,
and it doesn't make it any more efficient at runtime to use a more verbose
syntax.

Argh. How is this relevant?

Posted Nov 14, 2008 13:38 UTC (Fri) by khim (subscriber, #9252) [Link] (7 responses)

The whole discussion is kind of pointless.

Please read the whole thread starting with The problem with C++ is that it's neither meat, nor fish. It's not an unencumbered portable assembly for reusable library building, and neither it is a proper high- level language.

Basically the story goes like this: C++ is poor as "unencumbered portable assembly for reusable library building" AND it's poor as high- level language too (compare metaprogramming in C++ and Lisp, for example).

A main design goal of C++ was to provide a good language for building reusable libraries, a better alternative to C for this task.

Yes. And they failed. You can not use STL like you'll use Python - you need to know a lot of details and you can not use it as portable assembler too. Basically resulting language is useless for everyone - but you can try to shoehorn both low-level stuff and high-level stuff in C++. The question is: why not use suitable language for these purposes? C for low-level stuff (much closer to hardware then C++) and Java/Python/Ruby (much safer) for high-level stuff?

C++ is "new PL/I" - the language which must be equally good for all kind of tasks but which is equally bad for all kind of tasks instead...

I suppose you would call C++ unencumbered, if you care about that, because you don't pay for anything if you don't use it.

You do pay for features worth having (exceptions and RTTI) and features which cost you nothing don't buy you much.

The same code for calling the multiply function or freeing memory would have to be written anyway, and it doesn't make it any more efficient at runtime to use a more verbose syntax.

When you see how much code this thing actually needs you'll try to avoid such code. When it's generated by compiler it looks like it's really free where it's not.

Argh. How is this relevant?

Posted Nov 14, 2008 19:50 UTC (Fri) by nix (subscriber, #2304) [Link] (4 responses)

Yeah, it's terrible to have the compiler do boring work for you. After
all, CPU time is so terribly expensive these days.

Compiler do boring work for you? Don't make me laugh.

Posted Nov 15, 2008 12:27 UTC (Sat) by khim (subscriber, #9252) [Link] (3 responses)

Have you actually written something with template metaprogramming? That's constant parade of repetetion, bunch of tricks and unclear semantic. Compiler does not do the boring work for you. It tries to strangle you at every step. The fact is: C++ is not powerful enough to make a lot of stuff easy and it's too far removed from the hardware to use it as "high- level portable assembler". Neither fish nor meat as was said above.

Compiler do boring work for you? Don't make me laugh.

Posted Nov 16, 2008 15:16 UTC (Sun) by nix (subscriber, #2304) [Link] (2 responses)

The 'compiler doing the boring work for you' was a reference to RAII,
obviously. 'Going out of scope firing destructors' being an example of the
compiler doing the boring work for you.

I have no idea why you dislike it: all you've given so far has been
venting.

Compiler do boring work for you? Don't make me laugh.

Posted Nov 16, 2008 19:44 UTC (Sun) by mgb (guest, #3226) [Link] (1 responses)

One can use C++ as "C plus extra type checking". Or one can use one or several or all of the C++ features such as virtuals, templates, and exceptions. C++ is great for abstract programs.

But C++ can be a royal pain when it comes to doing real work. Ever tried to open a pipe and handle it through C++ iostreams? Pipes are not available in Windoze so C++ refuses to admit they exist. You're stuck with compiler-specific extensions that change every other release, hidden in a namespace with three underscores.

C++'s operating system support transcends file cabinets in locked basement cupboards guarded by leopards and landmines.

Compiler do boring work for you? Don't make me laugh.

Posted Nov 16, 2008 22:11 UTC (Sun) by avik (guest, #704) [Link]

C doesn't recognize pipes either. You can't access a pipe using FILE *s using Standard C.

(fdopen() is not Standard C)

Argh. How is this relevant?

Posted Nov 15, 2008 16:44 UTC (Sat) by ikm (guest, #493) [Link] (1 responses)

> Basically resulting language is useless for everyone

You do understand that this statement doesn't reflect the perceived reality, don't you? And to address the rest:

> The whole discussion is kind of pointless.

Totally agreed. Each time C++ is spotted on LWN, it starts all over again. I even start to think that this phenomenon could deserve a dedicated article on its own.

Argh. How is this relevant?

Posted Nov 16, 2008 15:19 UTC (Sun) by nix (subscriber, #2304) [Link]

The language certainly seems to attract some dedicated haters.

Virtuals are minor problem

Posted Nov 14, 2008 17:30 UTC (Fri) by robert_s (subscriber, #42402) [Link]

Yeah, if you don't like operator overloads, don't use operator overloads.

If you're not going to trust the libraries you're using either, the whole "behind your back" argument is a bit of a moot point, because those libraries could be doing anything during their function calls anyway.

Virtuals are minor problem

Posted Nov 14, 2008 18:00 UTC (Fri) by robert_s (subscriber, #42402) [Link]

"A=B can mean network/disk access and more!"

In fact this is nonsense. C++ doesn't allow overloading of builtin types' operators. So you're not able to, i.e. redefine operator+ ( int , int ). So existing uses of operators will all work. Without operator overloads (in C), you wouldn't be able to do the equivalent at all. The way you'd have to do it in C would be:

A a;
B b;
C c;

c = addAandB ( a , b );

...and that function call could do anything.

C++

Posted Nov 14, 2008 2:15 UTC (Fri) by MisterIO (guest, #36192) [Link] (15 responses)

They use a sane subset of C++, so that's not a bad choice. But did you ever look at LLMV code? The code style is horrible for my taste! Just 2 spaces indentation!! Once I was reading a bit the code, but it gave me and headache because of that.

C++

Posted Nov 14, 2008 8:23 UTC (Fri) by nix (subscriber, #2304) [Link] (3 responses)

You'd think GNU indent was never written and indentation style differences
were ineluctable and unfixable.

C++

Posted Nov 17, 2008 4:53 UTC (Mon) by sbergman27 (guest, #10767) [Link] (2 responses)

"""
and indentation style differences were ineluctable
"""

I found this statement interesting. In 45 years, I do not believe that I have *ever* heard anyone use the word "ineluctable". (Or "eluctable" for that matter.) Often I hear words that I have to look up to confirm the meaning or spelling. But almost always I am at least familiar with the *existence* of the word. This was something completely new. :-)

C++

Posted Nov 17, 2008 19:13 UTC (Mon) by nix (subscriber, #2304) [Link]

They call me the rogue wordsmith at work because I keep on bringing up
words like that. (Equally often I bring up perfectly normal words that
nobody recognises because I don't know how to pronounce them...)

(It wasn't really the right word anyway, but I only spotted that after
hitting publish.)

C++

Posted Nov 22, 2008 8:54 UTC (Sat) by gold (guest, #3971) [Link]

Off-topic, but the only other time I've encountered the word "ineluctable" was in Alfred O'Rahilly's "Electromagnetic Theory", an astounding good book originally published in 1938. O'Rahilly was quite the pompous writer, and a real pleasure to read.

C++

Posted Nov 14, 2008 8:48 UTC (Fri) by mjthayer (guest, #39183) [Link] (10 responses)

> They use a sane subset of C++, so that's not a bad choice.

C++ is a brilliant language which makes for efficient and readable code. C++ is an awful language which makes for incomprehensible, broken code. It all depends on what subset of the language you use. I personally think that the best way to "fix" C++ would be to decide on a sane subset of the language and make the compiler produce warnings if anything else is used. Unfortunately, neither getting people to agree on what constitutes a "sane subset" nor parsing code to make sure that it sticks to it would be an easy job.

It's doable in corporate enviroment, but in free software world

Posted Nov 14, 2008 11:37 UTC (Fri) by khim (subscriber, #9252) [Link] (9 responses)

It's easy to declare some subset of C++ "sane" and everything else forbidden in a corporation: it does not even matter of some useful stuff will be forbidden as there are usually path to infrequently allow exceptions. With free software it's almost impossible. That's why C++ is an Ok language for corporate programming and bad for LLVM... May be they have authoritative enough core to cope?

It's doable in corporate enviroment, but in free software world

Posted Nov 14, 2008 12:27 UTC (Fri) by mjthayer (guest, #39183) [Link] (8 responses)

One way to do this would be to make it a compiler flag (e.g. -Wsane-subset). You could even have different flags if people differed as to which subset should be considered sane. People would use the flags if they wanted guidance from the compiler as to what is sensible to use and what not, and the choice would not be forced on them.

It's doable in corporate enviroment, but in free software world

Posted Nov 14, 2008 22:44 UTC (Fri) by salimma (subscriber, #34460) [Link] (7 responses)

Or one flag, but with loadable definitions, so large collaborative projects can define their accepted subsets and have it enforced at compile time.

It's doable in corporate enviroment, but in free software world

Posted Nov 15, 2008 7:33 UTC (Sat) by njs (subscriber, #40338) [Link] (6 responses)

Or people could just catch bad ideas during code review, and inoculate against them through development culture -- just like they already have to do for all languages.

At least, that's seemed to work for the C++ projects I've been involved with. We've even sometimes used horrible nasty constructs, because the horrible nastiness was technically superior and could be tucked away behind a simple interface. (My favorite: a macro "M" that "marked" an object as being interesting for debugging data-dependent crashes -- you just put M(myobj); on a line in your code, and then if an assertion fails in that function or anywhere under it in the stack, the contents of myobj are dumped to the log. Implementing this is a neat puzzle for keen students, and probably impossible in any other common language.)

It's doable in corporate enviroment, but in free software world

Posted Nov 15, 2008 7:50 UTC (Sat) by njs (subscriber, #40338) [Link]

Right, forgot to finish with my main point: it would be nice if "sane code" mapped nicely onto the use or non-use of specific language constructions, or indeed there were any simple algorithm for distinguishing code that was sane from code that was otherwise; indeed, this idea is so seductive that the search for such algorithms in various domains has driven thousands of years of philosophy and mathematics. But, alas, code -- like life -- is not so simple, and seductive ideas don't always give the payoff you hope for.

It's definitely doable in the free software world.

Posted Nov 16, 2008 10:25 UTC (Sun) by Ze (guest, #54182) [Link] (4 responses)

I mean really why does the whole C++ isn't suitable for free software thing stand up?

C++ is good precisely because it's so flexible. Personally I find operator overloading common sense.

Just like how you can't tell what's happening in non-operator overloaded languages for functions,methods,procedures without looking at the API , the same applies to C++.

When you look at the alternatives to templates , you throw out type safety with it and end up with something that is worse. When it comes to error messages yes gcc error messages suck , that doesn't mean that c++ sucks. Personally I'll be quite happy when clang c++ is well advanced. When I get time I'll contribute to it. I wouldn't be surprised to see LLVM approach the number of languages and architectures that gcc supports in 5 years.

When it comes to the free software world GTK+ with it's Gobject crap is horrible and I hate the thought of using QT with it's non standard extensions using it's own preprocessor. If the GTK people were sane they'd make GTK 3.0 using C++ with bindings for C instead of the other way around.

It doesn't matter whether you write C,C++,Java,Lisp,Python,Perl,Haskell,O'Caml,Scheme or any other language you need to document your code and API thoroughly from the point of someone new to the library/application otherwise there will be errors. You need to make sure that all the developers have roughly the same mental model and have it explained succinctly and coherently for new users.

I think the reason why scripting languages go through phases of being popular is because of their large libraries of modules all in one spot along with the libraries being relatively easy to use. There is no reason why C++ can't do the same thing (and it has started with boost).

It's definitely doable in the free software world.

Posted Nov 16, 2008 22:22 UTC (Sun) by Ed_L. (guest, #24287) [Link] (3 responses)

The choice of C vs. C++ for GTK+ was made by the GTK+ developers. Its only relevant to some one else if that some one wants to actually hack GTK+ code. I've been using the GTKmm C++ wrapper for five years now, it works quite well. Given that one of the design goals for GTK+ was a requirement that GTK+ be wrappable by many different languages, I'm not absolutely certain C was the wrong choice. Yes, Gobj() is ugly, but to make the library wrappable would require a C API to all its exposed public methods anyway, because of (I suppose) different object and inheritance models in different languages. So I'm not certain having allowing C++ under the covers would have bought them a great deal. That, and I suspect the GTK+ team shares many of this threads sentiments r.e. C++. Their choice. GTKmm certainly fills my needs, so I don't worry about GTK+ much one way or the other.

It's definitely doable in the free software world.

Posted Nov 17, 2008 14:53 UTC (Mon) by cortana (subscriber, #24596) [Link] (2 responses)

I like gtkmm a lot, but I find not being able to use exceptions a real pain in the arse. :(

It's definitely doable in the free software world.

Posted Nov 17, 2008 23:45 UTC (Mon) by Ed_L. (guest, #24287) [Link] (1 responses)

Not sure what you mean. I use Glibmm exceptions extensively throughout my code, they work pretty much the same as C++ exceptions. I haven't tried mixing C++ exceptions into this environment, so I can't comment on what would happen then. But Glibmm exceptions throw just fine.

It's definitely doable in the free software world.

Posted Sep 1, 2009 12:40 UTC (Tue) by cortana (subscriber, #24596) [Link]

Whoa, oooold thread. But I thought I'd refer to the gtkmm documentation:

Can I use C++ exceptions with gtkmm?
Yes, it is possible but it is not a very good idea. The official answer is that, since plain C doesn't know what a C++ exception is, you can use exceptions in your gtkmm code as long as there are no C functions in your call stack between the thrower and the catcher. This means that you have to catch your exception locally.
You will be warned at runtime about uncaught exceptions, and you can specify a different handler for uncaught exceptions. Some gtkmm methods do even use exceptions to report errors. The exceptions types that might be thrown are listed in the reference documentation of these methods.

It's the typical C++-code-called-by-C-code hooplah that I have to go through that makes use of gtkmm more annoying than it could have been.