-3

For me, I prefer having all my variables, not as pointers. Is it ok to keep all heap-allocated variables dereferenced?

For example:

#include "Foo.hpp"
#include "Bar.hpp"

class Foo {
private:
 Bar* ptr = new Bar();
};

Would it be ok to have Bar as a dereferenced pointer, without causing any issues?

Example:

Bar b = *(new Bar());
  • 3
    sure it's fine, but b is a copy and the new Bar object is leaked. Never use naked new. Either use plain values (here: Bar b; or Bar b = Bar()) or use smart pointers (e.g. Bar b = *std::make_unique<Bar>()) – amon May 29 '19 at 19:22
  • What advantages do you see with this approach? – user214290 May 29 '19 at 19:40
9

For me, I prefer having all my variables, not as pointers.

That's a good goal. If you are able to use C++11 or higher, that should be achievable for almost all use cases. The containers from the standard library and smart pointers make that possible. There will be exceptions but they should be rare.

Is it ok to keep all heap-allocated variables dereferenced?

From your posted code, it appears as though you want to use:

class Foo {
  private:
    Bar b = *(new Bar());
};

While that is synactically valid, it is wrong from a software standpoint. That line leaks memory. You are better off using the much simpler form:

class Foo {
  private:
    Bar b;
};

If you need to initialize b using something other than the default constructor, you may use

class Foo {
  private:
    Bar b = B(...); // Fill in the arguments for B's constructor
};

or even

class Foo {
  private:
    Bar b = someFunctionThatReturnsB(...); // Fill in the arguments for the function
};
  • So class Foo { private: Bar b; }; would be allocated on the heap? – Asyc May 29 '19 at 19:53
  • If you allocate a Foo from the heap, then the b object of the Foo will also be allocated on the heap. If Foo is on the stack, then the b will also be on the stack. – R Sahu May 29 '19 at 19:54
6

You really need to learn the language. The first example doesn't compile. The second example, if Bar b is declared in a context where it compiles, allocates and constructs an object on the heap, then uses assignment to assign a copy in a local variable, and leaks the object on the heap.

You are not "keeping a pointer dereferenced", you are making a copy of the object that the pointer points to.

2

Is it ok to keep all heap-allocated variables dereferenced?

There is no such thing as "heap-allocated variables". There are objects with dynamic storage duration (a.k.a. "heap-allocated"), but they are not associated with a name.

You can initialise an automatic storage duration (a.k.a. "stack-allocated variable") pointer object, from the result of a new expression, that points to the dynamic object. The pointer is the variable.

Would it be ok to have Bar as a dereferenced pointer, without causing any issues?

E.g. Bar b = *(new Bar());

No, that's not ok. It doesn't do what you think it does, it leaks an object and is a gratuitious use of new.

Much better is

Bar b;

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.