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

Discussion in 'C++' started by zl2k, Nov 15, 2010.

  1. zl2k

    zl2k Guest

    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
     
    zl2k, Nov 15, 2010
    #1
    1. Advertising

  2. zl2k

    Ian Collins Guest

    Re: is it safe to create an object inside a function and pass out

    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
     
    Ian Collins, Nov 15, 2010
    #2
    1. Advertising

  3. 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.
     
    Juha Nieminen, Nov 16, 2010
    #3
  4. Re: is it safe to create an object inside a function and pass out

    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.
     
    Ruslan Mullakhmetov, Nov 16, 2010
    #4
  5. zl2k

    Jorgen Grahn Guest

    Re: is it safe to create an object inside a function and pass out

    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 .
     
    Jorgen Grahn, Nov 17, 2010
    #5
  6. zl2k

    Öö Tiib Guest

    On Nov 16, 11:51 pm, Ruslan Mullakhmetov <> 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, Nov 18, 2010
    #6
  7. zl2k

    Miles Bader Guest

    Öö 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.
     
    Miles Bader, Nov 19, 2010
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Anonymous
    Replies:
    20
    Views:
    4,312
    Pete Becker
    Mar 30, 2005
  2. Jason Heyes
    Replies:
    8
    Views:
    732
    Andrew Koenig
    Jan 15, 2006
  3. Replies:
    8
    Views:
    1,939
    Csaba
    Feb 18, 2006
  4. Rune Allnor
    Replies:
    4
    Views:
    956
    Rune Allnor
    Dec 11, 2008
  5. Rushikesh Joshi
    Replies:
    0
    Views:
    368
    Rushikesh Joshi
    Jul 10, 2004
Loading...

Share This Page