STL list's assignment operator

[Christian Christmann]

Hi,

reading the output of gprof for one of my projects, I found that the
STL list assignment operator consumes a larger fraction of the
program's execution time. The exact entry in gprof's output looks
as follows:

std::list<MyClass*, std::allocator<MyClass*> >:perator=
(std::list<MyClass*, std::allocator<MyClass*> > const&) >

Since I don't know the source code for STL lists, I assume that
calling the assignment operator means that for each element
of the STL list the element's assignment operator is called. If
this is right, I don't understand why this works at all since I
explicitly disallow copying of MyClass objects by defining its
assignment operator private:

class MyClass:
private:
MyClass& operator=( const& MyClass );

So, the compiler does not create an default assignment operator
automatically. Thus, IMHO, STL list's operator= should fail.

Any ideas why this still works?

Regards,
Chris

 

[Markus Schoder]

Hi,

reading the output of gprof for one of my projects, I found that the
STL list assignment operator consumes a larger fraction of the
program's execution time. The exact entry in gprof's output looks
as follows:

std::list<MyClass*, std::allocator<MyClass*> >:perator=
(std::list<MyClass*, std::allocator<MyClass*> > const&) >

Since I don't know the source code for STL lists, I assume that
calling the assignment operator means that for each element
of the STL list the element's assignment operator is called. If
this is right, I don't understand why this works at all since I
explicitly disallow copying of MyClass objects by defining its
assignment operator private:

class MyClass:
private:
MyClass& operator=( const& MyClass );

So, the compiler does not create an default assignment operator
automatically. Thus, IMHO, STL list's operator= should fail.

Any ideas why this still works?

Your list seems to hold MyClass _pointers_ so only the pointers are
assigned not the objects themselves.

 

[Roland Pibinger]

reading the output of gprof for one of my projects, I found that the
STL list assignment operator consumes a larger fraction of the
program's execution time. The exact entry in gprof's output looks
as follows:

std::list<MyClass*, std::allocator<MyClass*> >:perator=
(std::list<MyClass*, std::allocator<MyClass*> > const&) >

Since I don't know the source code for STL lists, I assume that
calling the assignment operator means that for each element
of the STL list the element's assignment operator is called.

... and the assignment operator also allocates a new node for each
element in the list (which probably is the performance problem). Try
vector instead (using reserve()).

If
this is right, I don't understand why this works at all since I
explicitly disallow copying of MyClass objects by defining its
assignment operator private:

class MyClass:
private:
MyClass& operator=( const& MyClass );

So, the compiler does not create an default assignment operator
automatically. Thus, IMHO, STL list's operator= should fail.

Any ideas why this still works?

Your list contains pointers. MyClass objects are not copied, only
pointers to MyClass objects. After assignment the pointers in both
lists point to the same objects. This may or may not be what you want.
Note that STL containers use value semantics. They are made to work
with values, not with pointers to objects.

Best regards,
Roland Pibinger

 

[Jerry Coffin]

Hi,

reading the output of gprof for one of my projects, I found that the
STL list assignment operator consumes a larger fraction of the
program's execution time. The exact entry in gprof's output looks
as follows:

std::list<MyClass*, std::allocator<MyClass*> >:perator=
(std::list<MyClass*, std::allocator<MyClass*> > const&) >

Since I don't know the source code for STL lists, I assume that
calling the assignment operator means that for each element
of the STL list the element's assignment operator is called. If
this is right, I don't understand why this works at all since I
explicitly disallow copying of MyClass objects by defining its
assignment operator private:

One possibility would be that it's using a copy constructor to copy the
nodes.