Live data from Hacker News

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

channel9.msdn.com

11–20 of 85 posts

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

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

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.

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

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

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

#13
post #9

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

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 

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

#14
post #11

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.

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

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

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

you can always fake a defer:

    void f(int n, int x) {
      Gadget g = new Gadget(n);
      std::shared_ptr 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).

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

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

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.

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

#17
post #16

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.

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.

OOP means you design your thing as objects, with each object taking care of its own stuff. You don't have to use pointers, you may just use other objects as members, as you do in many other languages. Pointers just give you additional power and flexibility and if they are used in a object oriented design, its safe to assume that they should be managed by the owner object, like any other object's internal stuff.

Of course, you may prove me wrong.

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

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

    Gadget g = new Gadget(n);
That code won't compile unless Gadget has an assignment operator that accepts a pointer, which is, well, not a very common scenario.

Note: I'm not trying to be nitpicky. I really don't understand what you mean when you write that you "want to do this".

Now, I don't know anything about you, but based off your comments in this thread I'm not sure you have a working knowledge of C++.

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

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

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`. That'll disable copy construction and assignment, which means that you'll need to think of that separately if it's needed.

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

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

Nitpick:

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

    if (x 
Post reply on HN