how to return std::vector from function?

[zl2k]

hi, c++ user

Suppose I constructed a large array and put it in the std::vector in a
function and now I want to return it back to where the function is called.
I can do like this:

std::vector<int > fun(){
//build the vector v;
return v;
}

int main(){
std::vector<int > a = fun();
return 0;
}

It works fine. However, I believe there is a deep copy in fun(), so the
cost is big when the array is big. Now I tried to return a pointer without
deep copy.

std::vector<int >* fun(){
//build a pointer to vector;
return *v;
}

int main(){
std::vector<int >* a = fun();
return 0;
}

This got memory leak trouble in fun() since v will be deleted after return
thus the pointer returned will be invalid.

Is there anyway that I can get a correct pointer from fun()? I also
thought to use a smart pointer, such as boost::shared_p tr:

boost::shared_p tr< std::vector<int > > getV(){
boost::shared_p tr< std::vector<int > > v;
v->push_back(1) ;
v->push_back(2) ;
return v;
}

int main(){
boost::shared_p tr< std::vector<int > > v = getV();
std::cout << v->at(0);
return 0;
}

I got the following message when run the program:
/usr/include/boost/shared_ptr.hpp: 253: T* boost::shared_p tr<T>::operator->() const [with T = std::vector<int , std::allocator< int> >]: Assertion `px != 0' failed.
Aborted

How can I get it correct? Is there any deep copy when the getV() return
the shared_ptr?

Thanks a lot.

zl2k

[loufoque]

BigBrian a écrit :

Why return a huge object by value
and just hope the compiler does the optimization, when there are other
options that are just as easy to implement and then you *know* you
won't have this as a performance issue.

Because those options are ugly.
I recommend the elegant C++ way.

[Ben Pope]

zl2k wrote:

On Mon, 20 Mar 2006 14:48:55 -0500, Clark S. Cox III wrote:

boost::shared_p tr< std::vector<int > > getV(){
//Note the 'new' on the next line, as it is what actually creates the vector
boost::shared_p tr< std::vector<int > > v = new std::vector<int >;
v->push_back(1) ;
v->push_back(2) ;
return v;
}

int main(){
boost::shared_p tr< std::vector<int > > v = getV();
std::cout << v->at(0);
return 0;
}

It looks good, but can I sure that there is no deep copy involved when
getV() is called?

Yes. A boost::shared_p tr is, essentially, a pointer. So the the only
thing that is copied is the pointer, which holds some kind of reference,
to the vector.

Ben Pope
--
I'm not just a number. To many, I'm known as a string...

[Gavin Deane]

Tomás wrote:

Suppose I constructed a large array and put it in the std::vector in a
function and now I want to return it back to where the function is
called.

#include <vector>

template <class T>
class Unconstructed
{
private:

union UniversalAllign ment
{
char a; int b; short c; long d;

bool e;

float f; double g; long double h;

void* p;
};

UniversalAllign ment buffer[
sizeof(T) / sizeof(Universa lAllignment)
+ static_cast<boo l>( sizeof(T) % sizeof(Universa lAllignment) )
];

public:

void* ObjectAddress()
{
return &buffer;
}

T& GetProperRefere nce()
{
return *static_cast<T* >( ObjectAddress() );
}

};

void fun(void* p)
{
new(p) std::vector<int >();
}
int main()
{
Unconstructed< std::vector<uns igned> > my_vec;

fun( my_vec.ObjectAd dress() );

std::vector<uns igned>& real_vec = my_vec.GetPrope rReference();

real_vec.push_b ack( 5 );

real_vec.~vecto r();
}

Splendid. I think you have surpassed yourself. Pure, incomprehensibl e
genius. Well done :-)

To the OP: Don't ever write code like this if you want other people to
be able to work with it.

Gavin Deane

[Rolf Magnus]

zl2k wrote:

On Mon, 20 Mar 2006 18:44:34 +0100, Rolf Magnus wrote:

zl2k wrote:

hi, c++ user

Suppose I constructed a large array and put it in the std::vector in a
function and now I want to return it back to where the function is
called. I can do like this:

std::vector<int > fun(){
//build the vector v;
return v;
}

int main(){
std::vector<int > a = fun();
return 0;
}

It works fine. However, I believe there is a deep copy in fun(),
Why?

I am not sure, correct me if not. Is there any deep copy needed if I
return a std container from a function? I'll be very happy if not.

so the cost is big when the array is big. Now I tried to return a
pointer without deep copy.

std::vector<int >* fun(){
//build a pointer to vector;
return *v;
}
}
int main(){
std::vector<int >* a = fun();
return 0;
}
}
This got memory leak trouble in fun() since v will be deleted after
return thus the pointer returned will be invalid.

Your description is correct, though that is not a memory leak.

right, no leak but the returned pointer is invalid.

Is there anyway that I can get a correct pointer from fun()? I also
thought to use a smart pointer, such as boost::shared_p tr:

boost::shared_p tr< std::vector<int > > getV(){ boost::shared_p tr<
std::vector<int > > v; v->push_back(1) ; v->push_back(2) ; return v;
}
}
int main(){
boost::shared_p tr< std::vector<int > > v = getV(); std::cout <<
v->at(0);
return 0;
}
}
I got the following message when run the program:
/usr/include/boost/shared_ptr.hpp: 253: T*
boost::shared_p tr<T>::operator->() const [with T = std::vector<int ,
std::allocator< int> >]: Assertion `px != 0' failed. Aborted

How can I get it correct? Is there any deep copy when the getV() return
the shared_ptr?

Instead of returning a vector, your function could simply take one by
reference.

void fun(std::vector <int>& v){
//fill the vector v;
}
}
int main(){
std::vector<int > a;
fun(a);
return 0;
}

In some cases, I can't construct an empty container and pass it to the
function.

I can't think of any.
I want the class which owns the member function fun to own the
container. Say,

Class A {
public:
void GenerateBigData ();
void getBigData();
private:
std::vector<int > bigData;
}

Basically, the bigData is generated within the class A. When I need it, I
just want to access the bigData by calling getBigData. I don't want a
duplicated copy of the bigData, a reference will be good.

Then use a reference.

class A {
public:
void GenerateBigData ();
const std::vector<int >& getBigData() const { return bigData; }
private:
std::vector<int > bigData;
};

int main()
{
A a;
a.GenerateBigDa ta();
const std::vector<int >& data = a.getBigData();
}

[Rolf Magnus]

zl2k wrote:

On Mon, 20 Mar 2006 18:44:34 +0100, Rolf Magnus wrote:

zl2k wrote:

hi, c++ user

Suppose I constructed a large array and put it in the std::vector in a function and now I want to return it back to where the function is
called. I can do like this:

std::vector<int > fun(){
//build the vector v;
return v;
}

int main(){
std::vector<int > a = fun();
return 0;
}

It works fine. However, I believe there is a deep copy in fun(),

Why?
I am not sure, correct me if not. Is there any deep copy needed if I
return a std container from a function? I'll be very happy if not.

so the cost is big when the array is big. Now I tried to return a
pointer without deep copy.

std::vector<int >* fun(){
//build a pointer to vector;
return *v;
}
}
int main(){
std::vector<int >* a = fun();
return 0;
}
}
This got memory leak trouble in fun() since v will be deleted after
return thus the pointer returned will be invalid.

Your description is correct, though that is not a memory leak.
right, no leak but the returned pointer is invalid.

Is there anyway that I can get a correct pointer from fun()? I also
thought to use a smart pointer, such as boost::shared_p tr:

boost::shared_p tr< std::vector<int > > getV(){ boost::shared_p tr std::vector<int > > v; v->push_back(1) ; v->push_back(2) ; return v; }
}
int main(){
boost::shared_p tr< std::vector<int > > v = getV(); std::cout v->at(0);
return 0;
}
}
I got the following message when run the program:
/usr/include/boost/shared_ptr.hpp: 253: T*
boost::shared_p tr<T>::operator->() const [with T = std::vector<int , std::allocator< int> >]: Assertion `px != 0' failed. Aborted

How can I get it correct? Is there any deep copy when the getV() return the shared_ptr?

Instead of returning a vector, your function could simply take one by reference.

void fun(std::vector <int>& v){
//fill the vector v;
}
}
int main(){
std::vector<int > a;
fun(a);
return 0;
}
In some cases, I can't construct an empty container and pass it to the function.
I can't think of any.
I want the class which owns the member function fun to own the
container. Say,

Class A {
public:
void GenerateBigData ();
void getBigData();
private:
std::vector<int > bigData;
}

Basically, the bigData is generated within the class A. When I need it, I just want to access the bigData by calling getBigData. I don't want a duplicated copy of the bigData, a reference will be good.

Then use a reference.

class A {
public:
void GenerateBigData ();
const std::vector<int >& getBigData() const { return
bigData; }
private:
std::vector<int > bigData;
};

int main()
{
A a;
a.GenerateBigDa ta();
const std::vector<int >& data = a.getBigData();
}

[Roland Pibinger]

On Tue, 21 Mar 2006 01:32:53 +0100, loufoque
<lo******@remov e.gmail.com> wrote:

If you compile this with gcc in normal mode, you can see there is no
copying done. (you can disable those optimizations in gcc with
-fno-elide-constructors, and you will therefore see that it is copied twice)
Other modern compilers probably do so too.

RVO is a hack! According to C++ semantics copying is performed. But
with some compilers using some compiler switches under certain
non-portable circumstances one or even two function calls are just
elided.
RVO thwarts language rules and depends on questionable 'optimizations'
beyond the language. I wouldn't call that an 'elegant C++ way'. Quite
the contrary.

Best regards,
Roland Pibinger

[loufoque]

Roland Pibinger a écrit :

RVO is a hack! According to C++ semantics copying is performed.
According to this [1], it is said in the specification that
implementations may optimize it.
The first form is already optimized by old pre-standard C++ compilers
like MSVC6.

[1] http://nkari.uw.hu/Tutorials/CPPTips/ret_val_opt

I actually searched it in the specification to be sure.
Unfortunetely I don't have the official one, so I used the current
working draft for the next version. (I probably wouldn't have the right
to paste the official anyway)
Here we go :

<bigquote>

When certain criteria are met, an implementation is allowed to omit the
copy construction of a class object, even if
the copy constructor and/or destructor for the object have side effects.
In such cases, the implementation treats the
source and target of the omitted copy operation as simply two different
ways of referring to the same object, and the
destruction of that object occurs at the later of the times when the two
objects would have been destroyed without the
optimization. This elision of copy operations is permitted in the
following circumstances (which may be combined
to eliminate multiple copies):

— in a return statement in a function with a class return type, when the
expression is the name of a non-volatile
automatic object with the same cv-unqualified type as the function
return type, the copy operation can be omitted
by constructing the automatic object directly into the function's return
value

— when a temporary class object that has not been bound to a reference
would be copied to a class object with
the same cv-unqualified type, the copy operation can be omitted by
constructing the temporary object directly into
the target of the omitted copy

[ Example:
class Thing {
public :
Thing ();
~ Thing ();
Thing ( const Thing &);
};

Thing f () {
Thing t;
return t;
}

Thing t2 = f();

Here the criteria for elision can be combined to eliminate two calls to
the copy constructor of class Thing: the copying
of the local automatic object t into the temporary object for the return
value of function f() and the copying of that
temporary object into object t2. Effectively, the construction of the
local object t can be viewed as directly initializing
the global object t2, and that object’s destruction will occur at
program exit. —end example ]

</bigquote>

But
with some compilers
Probably most of them.
Unfortunetely I only own two C++ compilers, gcc and icc to test it out
(it was optimized for both of them)
You are free to test it with all the C++ compilers you have.

using some compiler switches
using no switch.
The switch is to disable the optimization.

under certain
non-portable circumstances
The code I gave is always optimized whatever the platform and the
circumstances are with the compilers that perform such optimizations.
I wouldn't call that an 'elegant C++ way'. Quite
the contrary.

It is elegant because it doesn't use pointers which should be avoided
whenever possible. (they're pure evil)

[Noah Roberts]

zl2k wrote:

On Mon, 20 Mar 2006 12:32:48 -0800, BigBrian wrote:

loufoque wrote:

BigBrian a écrit :

> That may be, but then if performance is an issue, you won't have to
> assume that your compiler is smart enough to optimize.

If performance is an issue, use a performant compiler, that will indeed
optimize correctly.

It's a waste of time trying the write fast code with a compiler that
doesn't translate C/C++ code into the most efficient machine code it could.

I disagree, especially in this case. Why return a huge object by value
and just hope the compiler does the optimization, when there are other
options that are just as easy to implement and then you *know* you
won't have this as a performance issue.

Also, using a different compiler isn't always an option.

-Brian

So what is the straight forward way to solve the problem (without passing
an empty container into the fun and porpulize it inside)?

Well, passing in a reference in a pretty straight forward way to do it.
Other option would be returning an auto_ptr<vector <X> >. This allows
you to create a vector on the heap but still not worry about who needs
to destroy it.

[Alexei Zakharov]

loufoque wrote:

BigBrian a écrit :

Why return a huge object by value
and just hope the compiler does the optimization, when there are
other options that are just as easy to implement and then you *know*
you won't have this as a performance issue.

Because those options are ugly.
I recommend the elegant C++ way.

I second that. And besides, C++0x "rvalue reference" proposal will make the
elegant C++ way have the optimal performance regardless of compiler
optimizations.

[Rolf Magnus]

Roland Pibinger wrote:

On Tue, 21 Mar 2006 01:32:53 +0100, loufoque
<lo******@remov e.gmail.com> wrote:

If you compile this with gcc in normal mode, you can see there is no
copying done. (you can disable those optimizations in gcc with
-fno-elide-constructors, and you will therefore see that it is copied
twice) Other modern compilers probably do so too.
RVO is a hack! According to C++ semantics copying is performed.

According to the C++ standard, copying may be performed, but doesn't need
to. This is an option.
But with some compilers
probably most nowadays and even older ones
using some compiler switches
probably even without them or with standard optimization switches.
under certain non-portable circumstances
? What's unportable about those circumstances?
one or even two function calls are just elided.
No. The returned object is just not copied but used directly. This means
that no additional storage is acquired, no copy of the object is made
(which includes but isn't limited to eliding the copy constructor), and of
course only one object is destroyed instead of two. So it's much more than
just eliding a function call or two.
RVO thwarts language rules and depends on questionable 'optimizations'
beyond the language.
It's not at all beyond the language. It's part of it.
I wouldn't call that an 'elegant C++ way'. Quite the contrary.

void func1(const MyClass& obj);
MyClass func2();

func1(func2());

looks more elegant to me than:

void func1(const MyClass& obj);
void func2(MyClass& obj);

MyClass x;
func2(x);
func1(x);

and if you consider operators, you don't even have any choice:

MyClass& operator+(const MyClass& lhs, const MyClass& rhs);

Would you instead prefer this?

void add(MyClass& result, const MyClass& lhs, const MyClass& rhs);

Which one looks more like an "elegant C++ way" to you?