efficiency of vector::push_ba ck?

[Mark P]

Say I have objects of class C which are fairly large. Then consider:

vector<C> vc;
vc.push_back(C( ));

Naively this would seem to construct a temporary object C(), copy it
into the space owned by the vector, and then delete the temporary object.

I realize this is implementation dependent, but will most modern
compilers optimize away the creation of the temporary object, or is
there a compelling reason why this is not possible?

Thanks,
Mark

[Alvin]

Mark P wrote:

Say I have objects of class C which are fairly large. Then consider:

vector<C> vc;
vc.push_back(C( ));

Naively this would seem to construct a temporary object C(), copy it
into the space owned by the vector, and then delete the temporary object.

I realize this is implementation dependent, but will most modern
compilers optimize away the creation of the temporary object, or is
there a compelling reason why this is not possible?

Thanks,
Mark

I believe what happens is the:

1. vc is created with 0 capacity.
2. When push_back is called a temporary C object is constructed.
3. vc is then grown to capacity of 1.
4. As the vector is grown, another C object is constructed. This one is
inside of vc
5. Then the temporary C object (created by the call to push_back in 2) is
then copied (via the operator= or copy constructor into the C object that
is inside the vector (created in 4).

[Jonathan Mcdougall]

>Say I have objects of class C which are fairly

large. Then consider: vector<C> vc;
vc.push_back(C ()); Naively this would seem to construct a temporary
object C(), copy it into the space owned by the
vector, and then delete the temporary object. I realize this is implementation dependent, but
will most modern compilers optimize away the
creation of the temporary object, or is there a
compelling reason why this is not possible?

If constructing and copying objects of class C is
expensive, do not store them by value.
std::vector is usually implemented using a
dynamic array, so when it has to allocate memory,
it will copy its elements. Use pointers instead.

std::vector<C*> vc;
vc.push_back(ne w C);

--
Jonathan
[FAQ] - http://www.parashift.com/c++-faq-lite/

[E. Robert Tisdale]

Mark P wrote:

Say I have objects of class C which are fairly large.
Then consider:

vector<C> vc;
vc.push_back(C( ));

Naively, this would seem to construct a temporary object C(),
copy it into the space owned by the vector
and then delete the temporary object.
Yes, but...
I realize [that] this is implementation dependent
but will most modern compilers optimize away
the creation of the temporary object
or is there a compelling reason why this is not possible? cat main.cc #include <iostream>
#include <vector>

class C {
private:
// representation
int I;
public:
// operators
friend
std::ostream& operator<<(std: :ostream& os, const C& c) {
return os << c.I;
}
// constructors
C(int i = 0): I(i) {
std::cerr << "C::C(int)" << std::endl;
}
C(const C& c): I(c.I) {
std::cerr << "C::C(const C&)" << std::endl;
}
~C(void) {
std::cerr << "C::~C(void )" << std::endl;
}
};

int main(int argc, char* argv[]) {
std::vector<C> vc;
vc.push_back(C( ));
return 0;
}
g++ -Wall -ansi -pedantic -O3 -o main main.cc
./main

C::C(int)
C::C(const C&)
C::~C(void)
C::~C(void)

Since the constructors, destructors and the push_back function
are all defined to be inline functions
the compiler can optimize away everything
except the diagnostic messages to standard error.

[Mark P]

E. Robert Tisdale wrote:

Mark P wrote:

Say I have objects of class C which are fairly large.
Then consider:

vector<C> vc;
vc.push_back(C( ));

Naively, this would seem to construct a temporary object C(),
copy it into the space owned by the vector
and then delete the temporary object.

Yes, but...

I realize [that] this is implementation dependent
but will most modern compilers optimize away
the creation of the temporary object
or is there a compelling reason why this is not possible?

> cat main.cc

#include <iostream>
#include <vector>

class C {
private:
// representation
int I;
public:
// operators
friend
std::ostream& operator<<(std: :ostream& os, const C& c) {
return os << c.I;
}
// constructors
C(int i = 0): I(i) {
std::cerr << "C::C(int)" << std::endl;
}
C(const C& c): I(c.I) {
std::cerr << "C::C(const C&)" << std::endl;
}
~C(void) {
std::cerr << "C::~C(void )" << std::endl;
}
};

int main(int argc, char* argv[]) {
std::vector<C> vc;
vc.push_back(C( ));
return 0;
}

> g++ -Wall -ansi -pedantic -O3 -o main main.cc
> ./main

C::C(int)
C::C(const C&)
C::~C(void)
C::~C(void)

Since the constructors, destructors and the push_back function
are all defined to be inline functions
the compiler can optimize away everything
except the diagnostic messages to standard error.

I don't understand your conclusions here. It appears that the
temporaary is constructed and then copied rather than being constructed
"in place" within the vector. How do you know that everything but the
std error messages is optimized away?

[Jean-Sebastien Samson]

> I realize this is implementation dependent, but will most modern compilers

optimize away the creation of the temporary object, or is there a
compelling reason why this is not possible?

Some compilers might have done that in the past. But it is now forbidden by
the standard (since there are situations where you rely on the exact number
of copy). The only copy they are allowed to optimize away is the return
value of a function. Ex: CObj obj = fun();
--
JS

[Francis Glassborow]

In article <11************ *********@f14g2 000cwb.googlegr oups.com>,
Jonathan Mcdougall <jo************ ***@gmail.com> writes

If constructing and copying objects of class C is
expensive, do not store them by value.
std::vector is usually implemented using a
dynamic array, so when it has to allocate memory,
it will copy its elements. Use pointers instead.

std::vector<C* > vc;
vc.push_back(n ew C);

However if you store raw pointers you will have a memory leak if an
exception gets thrown across the point at which you define vc. Use a
suitable smart pointer instead.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

[Francis Glassborow]

In article <42************ *********@news. free.fr>, Jean-Sebastien Samson
<js***@yahoo.fr > writes

I realize this is implementation dependent, but will most modern compilers
optimize away the creation of the temporary object, or is there a
compelling reason why this is not possible?

Some compilers might have done that in the past. But it is now forbidden by
the standard (since there are situations where you rely on the exact number
of copy). The only copy they are allowed to optimize away is the return
value of a function. Ex: CObj obj = fun();

No. While there is rather more restriction on when a copy may be
optimised away it is nowhere near as strict as that.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

[Robert W Hand]

On Fri, 13 May 2005 07:47:51 GMT, Mark P <no*@my.real.em ail> wrote:

E. Robert Tisdale wrote:

Mark P wrote:

Say I have objects of class C which are fairly large.
Then consider:

vector<C> vc;
vc.push_back(C( ));

<snip> Since the constructors, destructors and the push_back function
are all defined to be inline functions
the compiler can optimize away everything
except the diagnostic messages to standard error.

I don't understand your conclusions here. It appears that the
temporaary is constructed and then copied rather than being constructed
"in place" within the vector. How do you know that everything but the
std error messages is optimized away?

I always thought that the point of optimization was invisibility to
the user, other than perhaps execution time or program size. It would
be quite surprising to find that the result of a calculation varied
with turning on and off compiler optimization switches.

By requiring the program to print error messages logging the execution
path, the compiler cannot optimize away "everything ".
--

Best wishes,

Bob

[Francis Glassborow]

In article <j0************ *************** *****@4ax.com>, Robert W Hand
<rw****@NOSPAMo peramail.com> writes

I always thought that the point of optimization was invisibility to
the user, other than perhaps execution time or program size. It would
be quite surprising to find that the result of a calculation varied
with turning on and off compiler optimization switches.

By requiring the program to print error messages logging the execution
path, the compiler cannot optimize away "everything ".

But C++ gives specific authorisation wrt copy ctors. Under that licence
side effects of a copy ctor are not required to happen (and may also
happen at semi-arbitrary points if the compiler determines that it
wishes to create a temporary copy)

--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects