Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

channel9.msdn.com

Post reply on HN
Print view View original

31–40 of 85 posts

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

#31

Post by zowch »

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.

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

#32

Post by moron4hire »

pyrtsa wrote: post #22
harrytuttle wrote: post #14

Earlier quoted context omitted.

try/finally in Java / using in C# are designed for that scenario.

But you'll need to document it very visibly that "Thou shalt call resource.close() whatever happened." C++ makes it possible for the library writer to take care of freeing the resources automatically.

A class implementing IDisposable is that documentation. You shouldn't need more documentation than the fact that IDisposable is there.

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

#33

Post by fauigerzigerk »

fhd2 wrote: post #26

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 fa…

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 p{new Gadget(n)}; //exception safe
  unique_ptr 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.

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

#34

Post by daxelrod »

userulluipeste wrote: post #23
pyrtsa wrote: post #19

Earlier quoted context omitted.

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 ex…

These are problems that pop out from a bad design choices. One of the first things I remember from OOP learning is that constructors should be as safe as they can be, which means no allocations, partial or not. Of course it is tempting to misuse the language features out of personal commodity and blame someone else. I think we can agree that a few design changes would solve the ambiguous cases. Also, for the "remembe…

> constructors should be as safe as they can be, which means no allocations, partial or not.

Can you expand upon what you mean by "safe" here?

If you mean "unable to fail", I vehemently disagree. Constructors should validate what is passed into them and fail if that is invalid. The alternative is to construct a zombie object that can't actually be used. Objects like this subvert the type system and lead to lots of unnecessary "if object.is_valid()" checks all over code that uses them.

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

#35

Post by T-zex »

fauigerzigerk wrote: post #33
fhd2 wrote: post #26

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 fa…

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 p{new Gadget(n)}; //exception safe unique_ptr p{new Gadget(n)}; //exception safe and less wasteful than shared_ptr if local Gadget g{n}; //his preferred solution My proble…

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

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

#36

Post by Sharlin »

harrytuttle wrote: post #14
Sharlin wrote: post #11

Earlier quoted context omitted.

Java: void f(int n, int x) { Reader fr = new FileReader("foo.txt"); // ... if (x A garbage collector that gives a false sense of security is much worse than no garbage collector at all.

try/finally in Java / using in C# are designed for that scenario.

And try/finally assigns the cleanup responsibility to the caller, not the callee, which just adds boilerplate and mental burden. C++ does not need a finally block due to RAII. The using block (and "try-with-resource" in Java 7) is a poor man's RAII emulation.

Anyway, what if you need to share non-memory resources? Suddenly you cannot depend on the garbage collector, you cannot use try/finally, you cannot use using or try-with-resource - you need to handle the situation just like in C++, except you're given fewer tools to do it - and a poorer understanding of the situation if you've learned that you don't need to do manual resource management due to the garbage collector.

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

#37

Post by Sharlin »

pyrtsa wrote: post #20
harrytuttle wrote: post #8

Earlier quoted context omitted.

I rather prefer Java: void f(int n, int x) { Gadget p = new Gadget(n); // ... if (x Yes, good night's sleep tonight after writing that...

Nitpick: if (x You shouldn't use `new` either when throwing exceptions. Just: if (x

The grandparent's code is Java, not C++.

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

#38

Post by vertex-four »

Sharlin wrote: post #11
harrytuttle wrote: post #8

Earlier quoted context omitted.

I rather prefer Java: void f(int n, int x) { Gadget p = new Gadget(n); // ... if (x Yes, good night's sleep tonight after writing that...

Java: void f(int n, int x) { Reader fr = new FileReader("foo.txt"); // ... if (x A garbage collector that gives a false sense of security is much worse than no garbage collector at all.

Go's defer keyword is good for this. You could also attach a finalizer to the struct, to panic/log in case it's never closed.

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

#39

Post by FurrBall »

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) {}
  			}
  		}
  	}
  }
Post reply on HN