is it safe to create an object inside a function and pass out in std::vector?

[zl2k]

hi, there,

Is it safe if I do like this

void PopulateVector(std::vector<Object> objs){
Object obj;
objs.push_back(obj);
}

Will the obj created inside of the function lost once I try to use it
outside of the function? I need the function to populate an empty
vector. Thanks for your comments.

zl2k

 

[Ian Collins]

hi, there,

Is it safe if I do like this

void PopulateVector(std::vector<Object> objs){
Object obj;
objs.push_back(obj);
}

Will the obj created inside of the function lost once I try to use it
outside of the function? I need the function to populate an empty
vector. Thanks for your comments.

Pass by reference:

void PopulateVector( std::vector<Object>& objs )

Objects are copied into containers, so yes it will be OK.

 

[Juha Nieminen]

hi, there,

Is it safe if I do like this

void PopulateVector(std::vector<Object> objs){

I assume you mean:

Object obj;
objs.push_back(obj);
}

Will the obj created inside of the function lost once I try to use it
outside of the function? I need the function to populate an empty
vector. Thanks for your comments.

Yes, the object created inside the function will be "lost" when the
function is exited. That's what local objects do, by design. However, you
are not putting the object in question in the vector. You are telling the
vector to *copy* the object in question (in other words, the vector will
create a *new* object in its innards, and copy-construct it with the
object you gave it as parameter). As long as the object has a
properly-working copy constructor (which might be the compiler-generated
one), it will work ok.

 

[Ruslan Mullakhmetov]

Pass by reference:

void PopulateVector( std::vector<Object>& objs )

Objects are copied into containers, so yes it will be OK.

You could also use pointer instead of reference if you know that param
is going to be changed.
As for me i do not use non-const references at all except operators
overloading. Using pointers you definitely know that object could be
changed or specify 0 (NULL) if you do not want return value.

by the way, i've read about such rule in google code style guide.

 

[Jorgen Grahn]

On 11/16/2010 1:52 AM, Ian Collins wrote: .... ....
You could also use pointer instead of reference if you know that param
is going to be changed.
As for me i do not use non-const references at all except operators
overloading. Using pointers you definitely know that object could be
changed

In other words:

- pass const Foo& when you don't modify the argument
- pass Foo* to signal that you do
- don't pass Foo&

Some people use that rule yes, but it's far from universal.
One reason is:

or specify 0 (NULL) if you do not want return value.

You probably don't want to let the user pass NULL, most of the time.

by the way, i've read about such rule in google code style guide.

If I recall correctly, that guide has been criticized a lot here.

/Jorgen

 

[Öö Tiib]

You could also use pointer instead of reference if you know that param
is going to be changed.
As for me i do not use non-const references at all except operators
overloading. Using pointers you definitely know that object could be
changed or specify 0 (NULL) if you do not want return value.

Passing NULL as output parameter when caller does not want that output
is the way of C interface. In C++ it is rude when interface demands
parameters that caller does not have; in C++ you can have overloads.

by the way, i've read about such rule in google code style guide.

Some other style guides suggest to minimize amount of raw pointers and
avoid usage of unary &. I like such rules better.

 

[Miles Bader]

Some other style guides suggest to minimize amount of raw pointers and
avoid usage of unary &. I like such rules better.

Yeah, me too.

There's obviously a tradeoff, and neither way is "perfect"; it would be
cool if c++ had a way to indicate "out/modified" parameters, just to
make source-code more readable while preserving the goodness of
references over pointers.

Of course simply by use of references to const vs. non-const objects,
one can indicate this in the function interface to some degree, but I
gather what proponents of using pointers for out-arguments want is a way
of making it obvious at the _call-site_ that an argument is an output.

E.g.

...
SomeType output;
...
some_func (inp1, inp2 + 3, out: output);

substitute your prefered notation for "out:", e.g., "=>" might also be
fairly readable:

some_func (inp1, inp2 + 3, => output);

Since const-vs-non-const largely covers the actual type-checking, I
guess this would be largely cosmetic... I suppose to make sure people
actually remembered to use such notation, declarations could also have
these annotations, and enforce the rule that "if the declaration marks a
parameter as "out:" (or "=>"), then calls must also do so."

-Miles