L
loufoque
BigBrian a écrit :
Because those options are ugly.
I recommend the elegant C++ way.
Because those options are ugly.
I recommend the elegant C++ way.
B
Ben Pope
zl2k said:
Yes. A boost::shared_ptr 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
G
Gavin Deane
Tomás said:
Splendid. I think you have surpassed yourself. Pure, incomprehensible
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
R
Rolf Magnus
zl2k said: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.right, no leak but the returned pointer is invalid.In some cases, I can't construct an empty container and pass it to theIs there anyway that I can get a correct pointer from fun()? I also
thought to use a smart pointer, such as boost::shared_ptr:
boost::shared_ptr< std::vector<int> > getV(){ boost::shared_ptr<
std::vector<int> > v; v->push_back(1); v->push_back(2); return v;
}
}
int main(){
boost::shared_ptr< 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_ptr<T>:
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;
}
function.
I can't think of any.
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.GenerateBigData();
const std::vector<int>& data = a.getBigData();
}
R
Rolf Magnus
zl2k wrote
class A
public
void GenerateBigData()
const std::vector<int>& getBigData() const { retur
bigData;
private
std::vector<int> bigData
}
int main(
A a
a.GenerateBigData()
const std::vector<int>& data = a.getBigData()
I can't think of anyfunction and now I want to return it back to where the function i
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
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
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 afte
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 als
thought to use a smart pointer, such as boost::shared_ptr
boost::shared_ptr< std::vector<int> > getV() boost::shared_pt
std::vector<int> > v; v->push_back(1) v->push_back(2); return v
int main()
boost::shared_ptr< std::vector<int> > v = getV() std::cou
v->at(0)
return 0
I got the following message when run the program
/usr/include/boost/shared_ptr.hpp:253: T
boost::shared_ptr<T>:
std::allocator<int> >]: Assertion `px != 0' failed. Aborte
How can I get it correct? Is there any deep copy when the getV( retur
the shared_ptr
Instead of returning a vector, your function could simply take on b
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 t th
function
Then use a reference
class A
public
void GenerateBigData()
const std::vector<int>& getBigData() const { retur
bigData;
private
std::vector<int> bigData
}
int main(
A a
a.GenerateBigData()
const std::vector<int>& data = a.getBigData()
R
Roland Pibinger
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
L
loufoque
Roland Pibinger a écrit :
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 ]
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 no switch.
The switch is to disable the optimization.
The code I gave is always optimized whatever the platform and the
circumstances are with the compilers that perform such optimizations.
It is elegant because it doesn't use pointers which should be avoided
whenever possible. (they're pure evil)
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 ]
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 no switch.
The switch is to disable the optimization.
The code I gave is always optimized whatever the platform and the
circumstances are with the compilers that perform such optimizations.
It is elegant because it doesn't use pointers which should be avoided
whenever possible. (they're pure evil)
N
Noah Roberts
zl2k said:
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.
A
Alexei Zakharov
loufoque said:
I second that. And besides, C++0x "rvalue reference" proposal will make the
elegant C++ way have the optimal performance regardless of compiler
optimizations.
R
Rolf Magnus
Roland said:
According to the C++ standard, copying may be performed, but doesn't need
to. This is an option.
probably most nowadays and even older ones
probably even without them or with standard optimization switches.
? What's unportable about those circumstances?
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.
It's not at all beyond the language. It's part of it.
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?
R
Rolf Magnus
Roland said:
According to the C++ standard, copying may be performed, but doesn't need
to. This is an option.
probably most nowadays and even older ones
probably even without them or with standard optimization switches.
? What's unportable about those circumstances?
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.
It's not at all beyond the language. It's part of it.
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?
B
BobR
zl2k wrote in message ...
If you can't take the vector to fun(), put fun() in the vector!! <G>
#include <iostream> // C++
#include <ostream> // std::endl
#include <fstream>
#include <vector>
class VecInt : public std::vector<int> { public:
VecInt(std:stream &out){
push_back( 7 );
std::ifstream fin( "graphic.txt" ); // JoeC's file, numbers in
text.
if( fin ){
for( int nud(0); fin >> nud; ){ push_back( nud );}
}
else{ out<<"could not open file"<<std::endl;}
} // VecInt Ctor
// ------------------------------------
void fun(){ at( 0 ) = 99; return;}
// void fun(size_t index){ if(index<size()) at( index ) = 99;}
// ------------------------------------
void Write(std:stream &out = std::cout){
for(const_iterator w = begin(); w != end(); ++w)
out<< *w <<" "; // out << *w << std::endl;
out<<std::endl;
} //Write(ostream&)
private:
// stuff here
}; //class VecInt
// ------------------------------------
int main(){
VecInt Vec1( std::cout );
Vec1.push_back( 77777 );
Vec1.Write( std::cout );
Vec1.fun();
std:fstream fout( "Afile.txt" );
if( fout ){
Vec1.Write( fout );
}
return 0;
} // main()end
[ throw (std::exception)'s removed ]
[ tested on GCC MinGW 3.3.1. corrections welcome ]
If you can't take the vector to fun(), put fun() in the vector!! <G>
#include <iostream> // C++
#include <ostream> // std::endl
#include <fstream>
#include <vector>
class VecInt : public std::vector<int> { public:
VecInt(std:
stream &out){push_back( 7 );
std::ifstream fin( "graphic.txt" ); // JoeC's file, numbers in
text.
if( fin ){
for( int nud(0); fin >> nud; ){ push_back( nud );}
}
else{ out<<"could not open file"<<std::endl;}
} // VecInt Ctor
// ------------------------------------
void fun(){ at( 0 ) = 99; return;}
// void fun(size_t index){ if(index<size()) at( index ) = 99;}
// ------------------------------------
void Write(std:
stream &out = std::cout){for(const_iterator w = begin(); w != end(); ++w)
out<< *w <<" "; // out << *w << std::endl;
out<<std::endl;
} //Write(ostream&)
private:
// stuff here
}; //class VecInt
// ------------------------------------
int main(){
VecInt Vec1( std::cout );
Vec1.push_back( 77777 );
Vec1.Write( std::cout );
Vec1.fun();
std:
fstream fout( "Afile.txt" );if( fout ){
Vec1.Write( fout );
}
return 0;
} // main()end
[ throw (std::exception)'s removed ]
[ tested on GCC MinGW 3.3.1. corrections welcome ]
P
peter koch
zl2k skrev:
I would be quite surprised to see a compiler having any deep copy here.
[snip]
The only sensible thing to do is follow your original hunch and let the
optimizer do the job for you. If you decide that your program is to
slow and if your profiling shows the copy to be the culprit, by all
means return here (or even better to a group dedicated to your
compiler) for more advice.
Until then just don't throw away the way that is most readable and also
probably the fastest in order to replace it with an obscure, slow
algorithm.
I would be quite surprised to see a compiler having any deep copy here.
[snip]
The only sensible thing to do is follow your original hunch and let the
optimizer do the job for you. If you decide that your program is to
slow and if your profiling shows the copy to be the culprit, by all
means return here (or even better to a group dedicated to your
compiler) for more advice.
Until then just don't throw away the way that is most readable and also
probably the fastest in order to replace it with an obscure, slow
algorithm.