0

I have a question about allocating in c++. I have this code:

vector<unsigned char> &v = *new vector<unsigned char>();

Now the question is, is it generally a good idea to dereference the object and assigning it directly to a reference?

In my opinion, that makes it easier to use the object, because now you can just do:

v.push_back('a');
v[0];

instead of 

v->push_back('a');
(*v)[0];

finally, I can do 

delete &v;

to free my heap

Just because of the amount of (same) nice answers: I know I can just use a stack-variable but in my case, I need it on the heap! But the question of using a heap or stack-variable is another one.

So I kept this example simple and especially did not asked if I should allocate the variable at all.

El Hocko
  • 2,581
  • 1
  • 13
  • 22

4 Answers4

5

Is it generally a good idea to dereference the object and assigning it directly to a reference?

No, not at all.

If you don't need dynamic allocation, because the object only needs to last as long as the current scope, then make an automatic variable instead:

vector<unsigned char> v;

If you do need a dynamic object, then trying to disguise it is a good way to forget that it needs deleting. The best thing is to use a smart pointer so you don't need to remember to delete it at all; failing that, use a pointer.

Mike Seymour
  • 249,747
  • 28
  • 448
  • 644
  • What about something like `Base& obj = *(condition ? new Derived1 : new Derived2);` (with the necessary casts)? (I suspect that the fact that you can't use a smart pointer is a valid enough reason, since it means that you have to enclose all of the following code in a `try...catch` block.) – James Kanze Feb 01 '13 at 14:38
2

It's purely a stylistic issue. None of the places I've worked have used this convention, so it might deroute new people in your organization, but it is a valid convention.

It should be part of a larger definition of when you use pointers, and when you use references. (And you'll find a lot of variation in this; I've used at least three different conventions in different firms.)

James Kanze
  • 150,581
  • 18
  • 184
  • 329
0

It's not a good idea to store a heap object primarily in a reference variable, for the reason Joachim Pileborg gives in his comment. You ultimately need to delete the object, and that is best done through a pointer variable (in a reference, people will always wonder whether the actual object lives elsewhere).

Martin v. Löwis
  • 124,830
  • 17
  • 198
  • 235
  • 1
    `delete &v;` actually does delete the object properly, I tested it with valgrind and it said to me he didn't found any memory leaks so it works and the handling is far more simple than `(*v)[0]` and sometimes you have to store objects in the heap, think about a generator function that does some other things I omitted here to keep it simple: ` vector& gen(){ return *new vector(); } ` – El Hocko Feb 01 '13 at 14:06
  • I didn't mean to suggest that you can't delete it, but that delete &v; is confusing. – Martin v. Löwis Feb 01 '13 at 14:20
  • 1
    @Martinv.Löwis But why is it confusing? Only because you've never worked in a company that used this convention, or for some more fundamental reason. (I know it surprises me, but I'm pretty sure that that's just because I've never worked in a company which used it.) – James Kanze Feb 01 '13 at 14:36
  • The typical usage convention of references is that they get initialized with an object managed elsewhere. Having the reference variable own the object is a violation of that convention. – Martin v. Löwis Feb 01 '13 at 14:55
0

You could just do:

...
{
    vector<unsigned char> v; // this allocates the vector in the stack
    v.push_back('a');
    v[0];
} 
...

As far as I can see there is no need to allocate the vector in the heap.

You should read about heap and stack memory:

Community
  • 1
  • 1
lucasmrod
  • 260
  • 2
  • 9