Live data from Hacker News

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

channel9.msdn.com

21–30 of 85 posts

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

#21
post #9

Earlier quoted context omitted.

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 Or, if it really has to be a pointer: void f(int n, int x) { std::unique_ptr p = new Gadget(n); // Smart pointer // ... if (x Both will be automatically freed as soon as the scope is exited.

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

Well, what's easy in Java here is that you're effectively always working with shared objects. That's easy to use, but in my experience quite error prone, I can't count how many memory leaks I fixed in Java/JS code. YMMV.

In C++, you have various ways of referencing and passing objects, so you need to be aware of the lifetime and ownership of objects. It's arguably harder, and unfortunately, the C heritage makes it a lot harder than it needs to be :(

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

#22
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.

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.

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

#23
post #19

Earlier quoted context omitted.

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.

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 "remembering" problem, we can inherit from a base class having all the needed restrictions in place. The std's "something_ptr" gimmicks may sound like a good compromise at first, but just like the garbage collector, these will make you lazy and neglectful over time. It's good for those to exist though.

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

#24
post #9

Earlier quoted context omitted.

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 Or, if it really has to be a pointer: void f(int n, int x) { std::unique_ptr p = new Gadget(n); // Smart pointer // ... if (x Both will be automatically freed as soon as the scope is exited.

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

isn't that illegal?

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

#25
post #19

Earlier quoted context omitted.

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.

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…

>That'll disable copy construction and assignment, which means that you'll need to think of that separately if it's needed.

If you have a pointer in a class that is exactly what you want to happen in most cases. Then if you want copies you "have to" define your own copy constructor and assignment operator that copy the object pointed to rather than just copying the pointer.

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

#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 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.

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

#27
post #6

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

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.

[deleted]

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

#28
post #6

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

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...

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

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

#29

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...

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

My point entirely :)

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

#30
post #6

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

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...

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).

Post reply on HN