Darren New <dne### [at] sanrrcom> wrote:
> >   The temporary given as parameter is created only once, not 64 times.

> So the declaration is essentially hoisted from out of the loop? Makes sense.

  Ok, it may be possible that it is created in each loop, depending on how
you are creating it, so I may have exaggerated that bit, and it may indeed
be created 64 times.

  You could manually optimize it and create it only once outside the loops,
to make sure. (If, for example, each sprite is otherwise identical but with
different coordinates, you could simply change the coordinates and push it
into the vector.)

  OTOH in this case it probably doesn't matter.

> >   What is done 64 times is calling the copy constructor of hgeSprite

> OK. I know the assignment operator, and the constructor, but I never heard 
> of a copy constructor. <google> Oh, I see. It's a constructor with a 
> particular type for the argument. OK.

  The difference between the copy constructor and an the assignment operator
is that in the latter case the object being assigned to has already been
constructed in the past, and now it's assigned a new value. With the copy
constructor the object in question is directly initialized with the given
object.

  Copy constructors are called, for example, when you pass an object to
a function by value.

  (In some situations the compiler may be able to optimize the copy
constructor call away.)

> > a copy constructor should not be significantly slower than calling the
> > regular constructor.

> It doesn't look like it, but doesn't it have to "construct" the temporary, 
> then invoke the copy constructor? It's not like the compiler can construct 
> directly into the array element that std::vector allocated, can it?

  Actually it is perfectly possible to construct into an array element
directly. (A programmer can do that himself by using so-called placement
new.)

  Whether or not the compiler is smart enough to optimize it like that
is another question.

> And 
> wouldn't it have to call the destructor on the temporary 64 times after it 
> was copied (assuming it has a destructor)?

  If the temporary is created 64 times, then it will be destroyed 64 times
as well, of course.

> It looks like the code you wrote initializes a temporary, then passes it (by 
> address, presumedly) to std::vector.push_back(), which then has to copy it 
> into an internal array. Then the code reinitializes the same temporary for 
> the next iteration (assuming the code is even a little smartly compiled). If 
> the sprite has a destructor, doesn't it need to call that before freeing the 
> temporary? How can the compiler know the ... Oh, is std::vector inlined 
> enough that the compiler can see it's getting inserted directly into a 
> particular array element? If so, that would make sense, yes.

  Being a template class, all member functions of std::vector are inlined.
(This might change with export templates, but things like push_back() will
probably always be inline, for efficiency.)

  As I said, you may be right in that the temporary is created 64 times,
though. You could hand-optimize it by creating it once outside the loops.

-- 
                                                          - Warp

Post a reply to this message