Bjarne Stroustrup Discusses C++

http://electronicdesign.com/dev-tools/interview-bjarne-stroustrup-discusses-c

by DmitryNovikov • 13 years ago

49 68 13 years ago

fhd23• 13 years ago

I'm sort of a C++/Stroustrup fan I guess, but this confused me:

C isn’t simpler for C-style programming than C++ is [...]

Is Stroustrup really arguing that C is not simpler than C++? How can it not be simpler? C++ is essentially C with a ton of features added on top.

deletes• 13 years ago

C is not simpler as C++ as you can program( with a few minor differences ) in C++ using C style. In that case both are equally complex.

Sharlin2• 13 years ago

His point is that actually you don't want to write plain C - you want to pick some C++ features that considerably reduce the complexity of your code.

barrkel• 13 years ago

Your statement that, effectively, C++ can do everything C can, plus more, has the direct logical implication that C++ is absolutely more complex, not equally complex.

(FWIW, I don't fully agree with even that statement. C++ makes using e.g. enums with bitmasks much harder than C.)

recentdarkness• 13 years ago

He's just saying that if you write C in C++ it's as 'simple' as C itself. > C++ is essentially C with a ton of features added on top. You would just not use those 'ton of features on top'

fhd23• 13 years ago

Even unused code arguably adds to the overall complexity. But maybe that's what he meant, yeah.

sz4kerto• 13 years ago

The complexity of feature set of a language does not translate to complexity of programming in the given language. That's because if the problem is complex, then it might be easier to learn the more complex language features than solving the problem with simple language features.

fhd23• 13 years ago

"Simple" and "easy" mean two very different things [1].

[1] http://www.johndcook.com/blog/2011/11/11/simple-versus-easy/

stephen_g2• 13 years ago

Those added features make for simpler code - I mean, almost anything that does string handling or requires dynamic arrays is way easier to do in C++.

Sharlin2• 13 years ago

Indeed. A simple language leads to complex code. And code complexity is the thing that needs to be avoided, not language complexity. You could write a Turing-complete language with a single instruction, for instance "subtract and branch if negative", and it would probably be the simplest language in the world, but writing anything nontrivial in it would be horribly complicated.

eliasmacpherson13• 13 years ago

That whole paragraph is ridiculous. I'm commenting but really I should abstain because I feel I am lowering the tone with yet another great religious debate: C vs. C++.

"No. C isn’t simpler for C-style programming than C++ is, nor “closer to the hardware,” nor indeed more efficient. I have yet to see a program that can be written better in C than in C++. I don’t believe such a program could exist. By “better” I mean smaller, more efficient, or more maintainable."

Firstly, I'm sure what he's writing there is predicated on the C++ STL being available, the use of which will in turn increase compilation times, because there's a lot of templated code to compile.

I cannot see how you would implement strlen or malloc in C++ (EDIT: as efficiently and/or) more efficiently than C, particularly when you take casting void into account. It's not a far stretch then to imagine writing drivers and so on, where idiomatic C++ would be a distraction compared to C.

In the above his metrics, smaller, more efficient, more maintainable - I can't see any features that C++ has that will allow them to be proven true.

Any program that has to interact with a C library - Stroustroup would suggest library then to be wrapped to make it behave according to C++ style - if so - if the code is just calling a few library functions, C will be shorter and better by all his metrics.

The most convincing is maintainability, but C++ has many more ways to skin a cat than C, so where C had the overhead of understanding someone else's data structure, C++ pretty much does too.

stinos2• 13 years ago

[note: I use both C and C++ heavily, and I think you are interpreting Bjarne wrong here]

the use of which will in turn increase compilation times

sure, but that does not makes anything he says about it less true. You could even argue it has nothing to do with the discuession at all.

I cannot see how you would implement strlen or malloc in C++ more efficiently than C

He says "C is not more efficient" which means "C++ is as effecient, or more efficient". Which in turns means you are right, and he does not imply you are not (that's the "as efficient" part). Yeeha, you're both right, no need to start a war.

Stroustroup would suggest library then to be wrapped to make it behave according to C++ style

I'd rather think he'd suggest the library should have been written in C++ in the first place. Which is definitely shorter and better by his metrics.

The most convincing is maintainability

which again comes down to the "as efficient" part then.

CJefferson3• 13 years ago

Firstly, you can always assume the "C++ STL" is present, it is part of C++.

While implementing strlen faster in c++ is harder, implementing qsort faster is easier, as you have the option of compiling a version with the size of type, and comparator, known and inlinable.

Also, you could use a constexpr version of strlen on strings known at compiletime, and be sure the compiker will optimise out the call, unlike in C where you just have to hope the compiler will

stephen_g2• 13 years ago

I know what he means about teaching - I do a lot of systems (embedded) stuff, and love (well written) C++, but the course I did on it at Uni was awful. If that had been my only exposure to C++, I never would have wanted to touch it again!

azov• 13 years ago

For the sake of balance, here is Yossi Kreinin's list of things that are wrong with C++: http://yosefk.com/c++fqa/defective.html

PS. One of my biggest gripes with C++ is the lack of uniformity. Not only the language itself has insane learning curve, every project does so many trivial and not-so-trivial things differently that it's like learning another language each time you dive into a new codebase. From code formatting, documentation, and source tree layout to error handling, libraries and build system - for something so huge and complicated as C++ there's an amazing number of batteries not included. Even the things that are supposed to be standard in theory are often not so in practice. Damn, there's still custom string classes in the APIs of many popular libraries - almost two decades after std::string and STL!

PPS. And yes, there's a difference between having consistent conventions and trying to be perfect for everybody and everything.

stinos2• 13 years ago

or as bjarne points out in the article There can be no programming language that is perfect for everybody and for everything. C++ doesn’t try to be everything for everybody, but it is rather good at the tasks for which it was designed – mostly systems programming, software infrastructure, and resource-constrained applications and Don’t just say “I want a GUI library” or “there is no proper support for task-based concurrency” or whatever. We know that.

pkolaczk10• 13 years ago

Yet, most operating systems have been written in pure C, resource constrained applications are still being written mostly in pure C or eventually C with classes (and mobile apps are not resource constrained apps anymore), and enterprise software infrastructure is written in a wide range of languages ranging from C, through Java to even Python. What C++ is mostly used for are games and desktop GUIs... :D

huhtenberg• 13 years ago

The fact that this list has been around for a while doesn't make any less inaccurate and massively biased. That's basically a milder version of that "Indian Programmer Competency Matrix" - both are notable for how frequently they are plugged into conversations and not for their actual content.

[0] http://sijinjoseph.com/programmer-competency-matrix/

nkurz• 13 years ago

Stroustrup says:

  The real novelty here is the return statement: Note that
  I return a potentially huge vector by value. In C++98,
  that would typically cause the copy of all elements of
  res, potentially many thousands of elements. That would
  be a serious performance bug. In C++11, vector has a
  “move constructor,” so that rather than copying elements,
  the representation of res (merely three pointers) is
  “stolen” for use in the caller and an empty vector is left
  behind. After all, we are just about to return from 
  find_all() and won’t be able to use res again. Thus,
  returning a vector by value costs at most six word
  assignments independently of the number of elements.

  Move constructors is a simple facility available to every
  programmer and used by all standard-library containers
  implemented as handles. This allows us to return large
  objects from a function without messing around with
  memory management (explicitly) using pointers and
  free store.

Are most C++ programmers excited by this? Is the idea that people should start writing code depending on this behind the scenes behaviour, or that we now have a way to speed up poorly written code? It feels like an awful lot of effort to avoid returning a pointer. And if I were actually worried about the performance, I wouldn't feel comfortable just hoping it happened. Is there any confirmation by the compiler that it handled this in the way the programmer wanted?

dasmoth• 13 years ago

If you're living without a garbage collector, avoiding that pointer return is potentially quite a big deal.

"Just use a GC" is a viable answer to this in many circumstances, but probably not all.

pkolaczk10• 13 years ago

"Just use a GC" is not a viable answer in the C++ world, because for C++, contrary to Java, there are no GCs of acceptable throughput and pause times.

CJefferson3• 13 years ago

The compiler is required to put calls to nove constructors in specific placez, it doesnt change based on compiler or optimisation level.

The problrm with returning a pointer is now someone has to worry about when the memory that pointer refers to gets ckeaned up. In my current 50,000 line c++ project, there are exactly 3 places where I call new or malloc, and then have to manually worry about cleaning up the result.

jacobparker• 13 years ago

You don't just hope that it happens. Move semantics increase the usability of value-type semantics in C++ - you can now do more things with "values" without shooting yourself in the foot (performance-wise) i.e. you can replace some previous uses of references, pointers etc. (note however that moves, while potentially cheap, are not free. There is still RVO.)

It behove users to learn about move semantics before using them (or rather before assuming that they are implicitly using them.) The topic is unfortunately complicated.

yoodenvranx• 13 years ago

I am not that good at C++ so it would be really nice if somebody can enlighten me:

Isn't this already the case with some (all?) compilers in pre-C++11?

http://www.parashift.com/c++-faq/return-by-value-optimizatio...

eliasmacpherson13• 13 years ago

NVRO works by constructing the object once... (EDIT: detrino points out this is wrong, the object is not constructed first before passing, it is only a memory address that is passed, it's the return value that is constructed on to this address)

It is passed as a hidden argument to the function, assigning the return value to that argument passed in. Prior to the NVRO, the object was constructed once, a temporary was constructed and then copy constructed to give the result. You can test out the NVRO yourself by putting a printf in an object's constructor, and have the object returned from a function on to an object of the same type.

Stan Lipmann's Inside the C++ Object Model explained it best for me. NVRO applies to the vector object.

The difference here is that Stroustrup is talking about the elements of the vector, not the vector itself, and how the move semantics remove the need for constructing/copy constructing them.

detrino7• 13 years ago

The compiler is not required to perform RVO/NRVO and when it can be done depends on some surprising things such as the calling convention of the machine you are targeting. It's just an optimization the standard allows compilers to do (eliding copies).

What C++11 provides is a new kind of type that says "it is safe to steal the guts of this value". You can use this to overload a copy constructor or assignment operator to do "moves" instead of "copies". Because it is baked into the type system, it is guaranteed to happen when you expect it. While eliding a copy essentially has 0 cost, and the compiler will still prefer this over a move, moving a vector can have a very small cost (copying a few pointers), but it is still O(1) instead of O(n).

eliasmacpherson13• 13 years ago

There's precedent for this sort of thing in C++, the move semantics are added on top of this: https://en.wikipedia.org/wiki/Return_value_optimization If you are depending on code in the constructor of an object, this optimisation can catch you out.

simias• 13 years ago

I don't feel it's behind the scene at all, the behaviour is fairly straightforward and easy to understand. It seems pretty error-proof as far as I'm concerned.

We already trust the compiler to do a lot more tricky optimisations (loop unrolling, inlining, dead branch elimination...) so it doesn't really trouble me.

pkolaczk10• 13 years ago

Loop unrolling, inlining, dead code elimination does not change the asymptotical complexity of the program. This optimisation does.

detrino7• 13 years ago

The alternative to returning a vector by value would more likely be passing an empty vector by reference and then adding elements to it, then returning void. Returning a pointer instead (or unique_ptr) would be replacing value semantics with reference semantics which would be less efficient and inconsistent in interface. That's what move semantics bring to C++, consistent interfaces and efficiency.

textminer• 13 years ago

I've basically freshly come to C++ in a work environment, and C++11 is all I've learned so far. Range-for loops and smart pointers and move semantics are wonderful. I still haven't adopted to a perfect idiom for calling functions, though: It's straightforward if I call a function and it returns a single object with move semantics. But what if I want to mutate multiple things with a function call (say, go through a vector and throw out indexes below a certain threshold, updating an unordered_map so as to specify the names and locations of certain columns). Do I return one, while changing the other by reference? Do I return a pair or a struct that only exists for me to quickly unpack? Do I make the function void and change both by reference?

z3phyr• 13 years ago

There are languages specially groomed to replace C++, like D and Rust, but they might never; Not in this decade.

The day LLVM gets rewritten in Rust, that day Rust barely starts replacing C++.....

Bjarne Stroustrup Discusses C++

Related Stories