C++ [LWN.net]

C++

Posted Nov 13, 2008 22:59 UTC (Thu) by deepfire (guest, #26138)
In reply to: C++ by avik
Parent article: Things that go Clang in the night: LLVM 2.4 released (ars technica)

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.

to post comments

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.