9 ms·

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

66 points by qznc 13y ago

mkl 13y 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=sequential&direction=desc&term=&d=1&d=2&d=3&Media=true#theSessions http://channel9.msdn.com/Events/GoingNative/2013?sort=sequen... [1] http://channel9.msdn.com/Events/GoingNative/GoingNative-2012?sort=sequential&direction=desc&term=&d=1&d=2&Media=true#theSessions http://channel9.msdn.com/Events/GoingNative/GoingNative-2012...
yules 13y ago
Nice, thanks for posting
polskibus 13y ago
I posted some of the others while they were live : https://news.ycombinator.com/item?id=6336789 https://news.ycombinator.com/item?id=6336789 https://news.ycombinator.com/item?id=6336778 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 13y 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 :)
- fhd2 13y 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.
  - pkolaczk 13y ago
    C++ const-correctness is weaker than immutability in, say Haskell or Scala.
    - fhd2 13y ago
      Can't say anything about Haskell, but what Scala has is less flexible then const correctness in C++ IIRC. You can't have an immutable reference to a otherwise mutable object and then call non-mutating functions on it. It's either fully immutable or fully mutable. CMIIW by all means.
- eru 13y ago
  And even system programmers have other choices, as demonstrated by the linux kernel.
Aldo_MX 13y 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! :( }
- harrytuttle 13y 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...
  - fhd2 13y 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.
    - harrytuttle 13y ago
      What I was hoping you'd say :) This is fine until I want to do this, at which point C++ becomes a memory management bastard: void f(int n, int x) { Gadget g = new Gadget(n); // ... if (x < 100) throw new GadgetException("Gadget broke", x); if (x < 200) return; // ... }
      - kybernetyk 13y ago
        you can always fake a defer: void f(int n, int x) { Gadget g = new Gadget(n); std::shared_ptr<void> defer(nullptr, [g](void *) { delete g; }); ... But honestly ... I'd just use a stack allocated object - or a smart pointer. In the last year I didn't write one delete. (I'm a full time C++ dev).
fhd2 13y 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.
- fauigerzigerk 13y 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 13y ago
    C++11 move semantics eliminates the need of deep copying in most cases and return by value usually is very cheap.
    - fauigerzigerk 13y ago
zowch 13y 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.
- a8da6b0c91d 13y 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.
  - plorkyeran 13y ago
    s isn't an rvalue. It has a name, and you can refer to it within the body of the constructor.
    - a8da6b0c91d 13y ago
      I understand that, but it's clearly not used in the body. I was hoping it would be a legal and implemented optimization. move calls strike me as ugly and kinda dangerous. What if you do wind up wanting to refer to s in the body later on? It'd be nice if the compiler just handled it.
      - marshray 13y ago
        > What if you do wind up wanting to refer to s in the body later on? Then copy s, don't move it.
FurrBall 13y 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) {} } } } }
- pkolaczk 13y 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.
  - plorkyeran 13y 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.
    - pkolaczk 13y ago
      Agreed, however it is very easy to catch a forgotten close() automatically (IDEs do that), and, at least in my experience, most non-memory resources are used locally and not shared, so they are pretty easy. On the other side, some programming techniques are hard or downright impossible without GC - e.g. heavy functional programming with immutable persistent structures.
  - FurrBall 13y 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.
frozenport 13y 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.

66 points by qznc 13y ago

mkl 13y 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=sequential&direction=desc&term=&d=1&d=2&d=3&Media=true#theSessions http://channel9.msdn.com/Events/GoingNative/2013?sort=sequen... [1] http://channel9.msdn.com/Events/GoingNative/GoingNative-2012?sort=sequential&direction=desc&term=&d=1&d=2&Media=true#theSessions http://channel9.msdn.com/Events/GoingNative/GoingNative-2012...

yules 13y ago

Nice, thanks for posting

polskibus 13y ago

I posted some of the others while they were live : https://news.ycombinator.com/item?id=6336789 https://news.ycombinator.com/item?id=6336789 https://news.ycombinator.com/item?id=6336778 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 13y 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 :)

fhd2 13y 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.
- pkolaczk 13y ago
  C++ const-correctness is weaker than immutability in, say Haskell or Scala.
  - fhd2 13y ago
    Can't say anything about Haskell, but what Scala has is less flexible then const correctness in C++ IIRC. You can't have an immutable reference to a otherwise mutable object and then call non-mutating functions on it. It's either fully immutable or fully mutable. CMIIW by all means.
eru 13y ago
And even system programmers have other choices, as demonstrated by the linux kernel.

Aldo_MX 13y 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! :( }

harrytuttle 13y 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...
- fhd2 13y 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.
  - harrytuttle 13y ago
    What I was hoping you'd say :) This is fine until I want to do this, at which point C++ becomes a memory management bastard: void f(int n, int x) { Gadget g = new Gadget(n); // ... if (x < 100) throw new GadgetException("Gadget broke", x); if (x < 200) return; // ... }
    - kybernetyk 13y ago
      you can always fake a defer: void f(int n, int x) { Gadget g = new Gadget(n); std::shared_ptr<void> defer(nullptr, [g](void *) { delete g; }); ... But honestly ... I'd just use a stack allocated object - or a smart pointer. In the last year I didn't write one delete. (I'm a full time C++ dev).

fhd2 13y 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.

fauigerzigerk 13y 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 13y ago
  C++11 move semantics eliminates the need of deep copying in most cases and return by value usually is very cheap.
  - fauigerzigerk 13y ago

zowch 13y 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.

a8da6b0c91d 13y 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.
- plorkyeran 13y ago
  s isn't an rvalue. It has a name, and you can refer to it within the body of the constructor.
  - a8da6b0c91d 13y ago
    I understand that, but it's clearly not used in the body. I was hoping it would be a legal and implemented optimization. move calls strike me as ugly and kinda dangerous. What if you do wind up wanting to refer to s in the body later on? It'd be nice if the compiler just handled it.
    - marshray 13y ago
      > What if you do wind up wanting to refer to s in the body later on? Then copy s, don't move it.

FurrBall 13y 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) {} } } } }

pkolaczk 13y 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.
- plorkyeran 13y 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.
  - pkolaczk 13y ago
    Agreed, however it is very easy to catch a forgotten close() automatically (IDEs do that), and, at least in my experience, most non-memory resources are used locally and not shared, so they are pretty easy. On the other side, some programming techniques are hard or downright impossible without GC - e.g. heavy functional programming with immutable persistent structures.
- FurrBall 13y 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.

frozenport 13y 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.