C++ [LWN.net]

C++

Posted Nov 13, 2008 22:15 UTC (Thu) by avik (guest, #704)
Parent article: Things that go Clang in the night: LLVM 2.4 released (ars technica)

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.

to post comments

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.