Bjarne Stroustrup – The Essence of C++ [video]

http://channel9.msdn.com/Events/GoingNative/2013/Opening-Keynote-Bjarne-Stroustrup

by qznc • 13 years ago

66 83 13 years ago

channel9.msdn.com

mkl• 13 years ago

I think I watched all the talks from Going Native 2012, and I highly recommend them [1]. I expect 2013's will be just as good, though I won't have time to watch any for a while. Here are the others: http://channel9.msdn.com/Events/GoingNative/2013?sort=sequen...

[1] http://channel9.msdn.com/Events/GoingNative/GoingNative-2012...

yules• 13 years ago

Nice, thanks for posting

polskibus• 13 years ago

I posted some of the others while they were live : https://news.ycombinator.com/item?id=6336789 https://news.ycombinator.com/item?id=6336778

Hopefully we can have an interesting discussions on those topics now that at least 1 news about them has reached the main page.

bsaul• 13 years ago

really interesting to see classes as ressource manager above all, instead of concept incarnation. I was almost convinced to go back to C++ until the slide with auto range and all, combining new features of C++, at which point i remembered why i didn't want ro have a look at C++ code again.

but hey, i'm not a system programmer so i can afford it :)

fhd29• 13 years ago

RAII ("classes as resource manager") is one of the nice concepts in C++. My favourite is certainly const correctness.

And then there's tons of things that creep me out a bit. Being a multi paradigm language sounds good on paper, but it seems to cause a lot of accidental complexity. The best way to stay sane is probably to pick a certain subset of C++ for your project and stick to that, that's what I tend to do.

Then again, that's not uncommon in simpler languages either. "JavaScript, The Good Parts", lint and all that. Code accessibility matters IMO.

pkolaczk4• 13 years ago

C++ const-correctness is weaker than immutability in, say Haskell or Scala.

eru• 13 years ago

And even system programmers have other choices, as demonstrated by the linux kernel.

Aldo_MX• 13 years ago

I liked this snippet about pointer misuse:

  void f(int n, int x)
  {
    Gadget* p = new Gadget(n);  // look I'm a java programmer! :)
    // ...
    if(x<100) throw std::runtime_error("Weird!");  // leak
    if(x<200) return;                              // leak
    // ...
    delete p;  // and I want my garbage collector! :(
  }

harrytuttle4• 13 years ago

I rather prefer Java:

    void f(int n, int x) {
        Gadget p = new Gadget(n);
        // ...
        if (x < 100) throw new Exception("Weird!); // no leak
        if (x < 200) return;
        // ...
    }

Yes, good night's sleep tonight after writing that...

fhd29• 13 years ago

The point of the example is that this is how NOT to do it in C++.

There are two better options:

  void f(int n, int x) {
      Gadget p(n); // Stack allocated
      // ...
      if (x < 100) throw new Exception("Weird!); // no leak
      if (x < 200) return;
      // ...
  }

Or, if it really has to be a pointer:

  void f(int n, int x) {
      std::unique_ptr<Gadget> p = new Gadget(n); // Smart pointer
      // ...
      if (x < 100) throw new Exception("Weird!); // no leak
      if (x < 200) return;
      // ...
  }

Both will be automatically freed as soon as the scope is exited.

tspiteri• 13 years ago

The point is not about C++ vs Java, it is rather about writing C++ like you would write Java, which leads to leaks.

Sharlin3• 13 years ago

Java:

    void f(int n, int x) {
        Reader fr = new FileReader("foo.txt");
        // ...
        if (x < 100) throw new Exception("Weird!); // resource leak
        if (x < 200) return;                       // resource leak
        // ...
    }

A garbage collector that gives a false sense of security is much worse than no garbage collector at all.

pyrtsa3• 13 years ago

Nitpick:

    if (x < 100) throw new Exception("Weird!); // LEAK!

You shouldn't use `new` either when throwing exceptions. Just:

    if (x < 100) throw Exception("Weird!); // no leak.

abrahamsen• 13 years ago

Yes, Java is a far superior language than C++ for writing Java code.

sgoody• 13 years ago

I'm a C# dev and I totally agree with this.

I've done a limited amount of C++ many many years ago before I even knew what garbage collection was and I keep thinking of revisiting it, but honestly in my line of work ("Enterprise") I don't need the mental overhead of dealing with things such as pointers and memory allocation.

Perhaps, my view is outdated, but I get the impression that everything in C/C++ is just a little thorny when compared to other slightly more high-level languages, such as namespaces, package management, list comprehensions, library compatibilities, type strictness etc.

I would like to be wrong about that though... I wish I had a little more motivation to spend some real time with C++ (or perhaps even C).

userulluipeste4• 13 years ago

In OOP its recommended to use pointers as class members, managed by class methods. What you show is a "wild" allocation that doesn't really belong to no one and thus not really managed. You're right, pointers can be misused, but what can't be? Think of infinite loops or some similar very bad algorithm choice if nothing else. No amount of language design will fix bad programming.

curyous• 13 years ago

I don't think OOP means what you think it means. There's nothing in Object Oriented Programming paradigms that specifies what you should declare class members as. There are more important components to that decision such as what language you're using.

pyrtsa3• 13 years ago

Bjarne's advice also applies to pointers wrapped as class members. There are just too many ways you can mess things up inside the class when dealing with raw pointers, examples including:

- partial construction: having to deal with already allocated pointers in case of errors during the construction - copy construction: who owns the resources? (Alternatively, you'll need to remember to disable the copy constructor explicitly.) - copy assignment: likewise

Doing the Right Thing is just so much easier when you wrap those member objects into e.g. `std::unique_ptr<T>`. That'll disable copy construction and assignment, which means that you'll need to think of that separately if it's needed.

fhd29• 13 years ago

If you've ever wondered what's the deal with C++ and why it's being used in 2013, you might wanna watch this. Stroustrup isn't a very flashy speaker, but he says some incredibly insightful things.

C++'s C heritage makes it hard to master and also causes countless misconceptions. Even if you never want to use C++, it's worth looking into some of the unique concepts that, sadly, didn't catch on in other languages so far. (My personal favourites are const correctness and RAII.)

Do watch the talk, the first few minutes might already be mind blowing for anyone who thought C and C++ are basically the same language.

fauigerzigerk5• 13 years ago

There are also some things that are powerful but I'm not quite sure if I really like them. For instance, he promotes the use of handles instead of pointers. He goes through these variants:

  Gadget* p = new Gadget(n); // not exception safe
  shared_ptr<Gadget> p{new Gadget(n)}; //exception safe
  unique_ptr<Gadget> p{new Gadget(n)}; //exception safe and less wasteful than shared_ptr if local
  Gadget g{n}; //his preferred solution

My problem with his preferred solution is that I cannot know that Gadget is really a handle to a shared Gadget and not a big fat Gadget value on the stack. The only way of knowing that is to look at the implementation or the documentation.

So if g is returned from a function or passed to a function by value, I don't know whether or not a deep copy is made. If I manipulate that Gadget, am I manipulating a shared object affecting others or is this my private copy?

Qt uses that pattern throughout, and because it is used for everything in Qt, you know that you're dealing with handles. But the C++ standard library doesn't do it that way. Almost none of the classes in the standard library are handles.

If I see a pointer, shared or otherwise, I know I'm not dealing with a deep copy. I know someone somewhere else might point to the same object.

T-zex• 13 years ago

C++11 move semantics eliminates the need of deep copying in most cases and return by value usually is very cheap.

fhd29• 13 years ago

My problem with his preferred solution is that I cannot know that Gadget is really a handle to a shared Gadget and not a big fat Gadget value on the stack. The only way of knowing that is to look at the implementation or the documentation.

I'd say you do not _need_ to know. If Gadget contains tons of data, it's wiser for it to just put that on the heap, internally. Like std::vector does. As long as Gadget handles (or forbids) copying, assigment etc. (rule of three), that's fine.

If you do have a huge performance issue because you're using a class that, unwisely, puts tons of data on the stack, you can use a unique_ptr instead. Kind of an edge case in my experience though.

marshray5• 13 years ago

Somehow I don't find this to be a problem in my code. Yes, when using someone else's library you need to know how they handle ownership. But this is basically a problem inherited from C.

For example, in the code you posted all the pointer-like handles are named 'p'. In my experience, if we consistently pursue minimal scope and minimal lifetime for our objects, then longer-lived objects are oddballs and we use the type of the handle to help describe its ownership strategy.

epsylon2• 13 years ago

C++'s C heritage

Well, at this point it's more like C++'s C++ heritage.

const correctness

It certainly exists in plenty of other languages, but in a non-broken way. C++'s const correctness model is mostly broken, by the way [1]. D's model is a bit more sane [2]. Languages like Haskell or Clojure (AFAIK) make immutability a default. This kind of functional style is a good thing for C++ developers overall, as emphasized by John Carmack [3].

[1] Once again, the C++ FQA has plenty of wisdom to share: http://yosefk.com/c++fqa/const.html [2] http://en.wikipedia.org/wiki/Const-correctness#const_and_imm... [3] http://www.altdevblogaday.com/2012/04/26/functional-programm...

RAII didn't catch in other languages

That's because most other languages are garbage collected. (Not that RAII is a bad thing, it's just not needed.)

fhd29• 13 years ago

It certainly exists in plenty of other languages, but in a non-broken way. C++'s const correctness model is mostly broken, by the way [1]. D's model is a bit more sane [2]. Languages like Haskell or Clojure (AFAIK) make immutability a default.

What in particular is broken about const correctness in C++? That things are not const by default? I agree, they should be, but I wouldn't really call that broken. I put const wherever I can, just like Carmack. So I sort of pretend it's the default :)

I don't think it makes sense to compare const correctness in C++ to immutability in Clojure. In Clojure, you don't have objects that encapsulate internal state. const in C++ allows you to say which methods do change internal state and which don't. If you pass a const reference, the receiver can only call const methods. I just learned from you that D has this, wasn't aware of any other OOP language that has it. Not even Scala :(

That's because most other languages are garbage collected. (Not that RAII is a bad thing, it's just not needed.)

RAII is about more than just memory, it's about any kind of resource. That includes stuff like file handles, Java's try {} finally {} is IMO a weird workaround. In C++, stream's can just close themselves when they go out of scope.

dustingetz• 13 years ago

Const correctness is the essence of all functional languages; RAII is in functional languages too and even java has an interface for it

zowch• 13 years ago

As somebody who attended this conference, and hadn't had much exposure to C++11 features outside of 'auto', my personal biggest takeaway from almost every talk was this: Stop passing your sink variables as const refs.

That is to say if you have a constructor:

  MyClass::MyClass(const std::string& s) : m_s(s) {}

That you call like:

  std::string s = "Some string";
  MyClass c(s);

You're hamstringing the compiler into always copying that string instead of being able to use the new move semantics, because it can't mess with the guts of a const reference. Instead, do the previously unspeakable evil of passing by value and then moving, e.g.

  MyClass::MyClass(std::string s) : m_s(std::move(s)) {}

This lets the compiler know that if string has a move constructor, and is an rvalue, it can just move the guts into place instead of performing the copy, since the variable is 'sunk' into the new location. Huge wins all around.

a8da6b0c91d4• 13 years ago

Is the std::move call really necessary? It's a little sad if the compiler can't see that s is already an rvalue.

plorkyeran2• 13 years ago

s isn't an rvalue. It has a name, and you can refer to it within the body of the constructor.

detrino6• 13 years ago

Once things have a name and you can take their address they are no longer an rvalue. It would require a much more sophisticated type system to do this automatically (when you pass a reference to another function, does it capture it?). It would also be non-obvious when you were moving. Think of Java style escape analysis vs C++ stack allocation (implicit vs explicit). There is one case where the compiler will do this though, when you return a stack allocated value from a function, it is implicitly moved.

FurrBall4• 13 years ago

I look at Java code and it horrifies me. Java is great if your resource is memory. It turns into a horrible unsafe mess the moment your resources are not memory.

  //C++ RAII goodness.
  void foo()
  {
  	conn.open();
  	file.open();
  	printer.activate();
  	//do stuff
  }
  
  //Java's lack of RAII is disturbing
  void foo()
  {
  	try{
  		conn.open();
  		file.open();
  		printer.activate();
  		//do stuff
  	}
  	catch(Exception e) { }
  	finally{
  		try {
  			conn.close();
  		}
  		catch(Exception ee) {}
  		finally{
  			try {
  				file.close();
  			}
  			catch(Exception eee) {}
  			finally {
  				try{
  					printer.close();
  				}
  				catch(Exceptoin eeee) {}
  			}
  		}
  	}
  }

pkolaczk4• 13 years ago

You can write bad code in any language. No experienced Java coder would write a code like this. Java has ARM blocks for dealing with deterministic resource cleanup.

plorkyeran2• 13 years ago

using/ARM/etc. make classes which own non-memory resources a lot less awkward to deal with, but one of the big wins of RAII is that the caller doesn't have to know or care that you have things which require special cleanup.

FurrBall4• 13 years ago

Reality is there are many Java code bases which handle resources like this. For java 6 and below this not bad code; it is how you are forced to deal with resources.

Even with the new block syntax, you have painful nesting if the operation requires several disparate resources.

Blocks are an improvement, but not the same as RAII. A block is literally converted to a try-finally by the compiler. It is the same thing with a cleaner syntax. There is no safety added to the old Java way. A programmer can forget to put his stuff in a block and leak the resource the same as he forgets to use a try-finally. The onus is on the consumer, not the library writer.

With RAII the onus is removed from the consumer. The consumer writes safe code automatically, no onus to remember any special clean up idioms.

applecore• 13 years ago

Java 7 introduced a new language construct, called the try-with-resources statement, for automatic resource management:

    void foo() {
        try (open file or resource here) {
            // do stuff
        }
        // after try block, resource will close automatically
    }

This works with non-memory resources such as files, streams, sockets, and database connections.

FurrBall4• 13 years ago

Pasting a response:

With C++ RAII the onus is removed from the consumer. The consumer writes safe code automatically, no onus to remember any special clean up idioms.

frozenport• 13 years ago

Am I the only one who is too lazy to write concepts? The process seems too involved and represent a case of diminishing returns. Large OOP projects are infamous for having classes that are impossible to mock, this will only make the problem worse.

Bjarne Stroustrup – The Essence of C++ [video]

Related Stories