«

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

On 11/16/10 11:45 AM, zl2k wrote:
> 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.

--
Ian Collins

zl2k <> wrote:
> hi, there,
>
> Is it safe if I do like this
>
> void PopulateVector(std::vector<Object> objs){

I assume you mean:

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.

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.

On 11/16/2010 1:52 AM, Ian Collins wrote:
> On 11/16/10 11:45 AM, zl2k wrote:
>> 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.
>

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.

On Tue, 2010-11-16, Ruslan Mullakhmetov wrote:
> On 11/16/2010 1:52 AM, Ian Collins wrote:
....
>> void PopulateVector( std::vector<Object>& objs )
....
> 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

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

On Nov 16, 11:51*pm, Ruslan Mullakhmetov <tiaba...@gmail.com> wrote:
> On 11/16/2010 1:52 AM, Ian Collins wrote:
>
>
>
>
>
> > On 11/16/10 11:45 AM, zl2k wrote:
> >> 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.
>
> 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.

Öö Tiib <> writes:
> 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

--
You can hack anything you want, with TECO and DDT.