Re: Templated containers of inherited objects
On Feb 17, 1:12 pm, rpbg...@yahoo.com (Roland Pibinger) wrote:
On 16 Feb 2007 17:29:09 -0800, paul joseph wrote:
On Feb 16, 1:05 pm, rpbg...@yahoo.com (Roland Pibinger) wrote:
STL does not support object-oriented programming.
I think that this comment is misleading. If I understand the point of
the statement, its that using objects that use polymorphism in a
container isn't supported.
Just look at the containers, iterators and algorithms. No algorithm
works with (pointers to) objects (except random_shuffle).
This examples shows how to use std::sort on a std::vector or pointers.
As well as a trivial example of std::for_each to print the vector.
#include <iostream>
#include <vector>
class A
{
public:
A( int val )
{
_val = val ;
}
~A() {}
int
value()
{
return _val ;
}
private:
int _val ;
} ;
bool
compare( A* lhs, A* rhs )
{
return lhs->value() < rhs->value() ;
}
void
echo( A* a )
{
std::cout << a->value() << std::endl ;
}
int
main( int argc, char* argv[] )
{
std::vector< A* > vec ;
for( int i = 10 ; i > 0 ; i-- )
{
A* a = new A( i ) ;
vec.push_back( a ) ;
}
std::cout << "Before sort:" << std::endl ;
std::for_each( vec.begin(), vec.end(), echo ) ;
std::sort( vec.begin(), vec.end(), compare ) ;
std::cout << "After sort:" << std::endl ;
std::for_each( vec.begin(), vec.end(), echo ) ;
}
Because this isn't the case at all.
Although, objects used with the STL must provide certain concepts,
such as default constructibility, copy constructibility et al.
When dealing with class hierarchies, we must pay special attention to
copy constructibility and other concepts because these can lead to
problems such as slicing as noticed by the OP.
Objects (in the meaning used in object-oriented programing) are
characterized by identity, state and behavior. It makes no sense to
copy or assign objects. Copy constructibility makes only sense for
values and value-oriented libraries like STL.
You're right, wrong, and neither right or wrong. Of course objects are
characterized by their state and behavior. You're absolutely wrong
that it makes no sense to copy or assign objects, there are instances
where this may be true, but its just plain wrong to say never. I use
it quite a bit.
And the last bit that copy constructibility only makes sense in the
STL isn't quite right, although I don't tend to use it alot in my own
code, thats mostly becuase I don't write code that requires this
concept.
Using pointers is a perfectly valid method of fixing this issue.
If it needs fixing it must be broken.
STL containers,
iterators and algorithms are designed only for values, not for
(pointers to) objects.
This is just wrong. A pointer *is* a value. Its a memory address. STL
containers will work just fine with pointers.
A pointer is not a value, otherwise one could just use an int instead.
A pointer in C/C++ has the combined meaning of reference and address.
You can use an int for a pointer! (Disclaimer: Its very ill advised,
bad C++, and requires that an int be the same size as the pointer you
wish to obfuscate.)
Objects on the other hand must provide the required concepts as
mentioned before.
The 'required concepts' make sense only for values, not objects.
The entire point of the STL is to provide a system
that allows for use with any custom type. They'd be pretty pointless
if they could only hold things like int, float, char* et al.
... and 'concrete types' as Stroustrup calls them.
Workarounds exist but with 'Standard' STL there
always remains an 'impedance mismatch' when objects are used.
I'm not entirely certain what 'impedance mismatch' means. Although it
kinda reminds me of studying power amplifiers...
It means the mismatch that becomes evident when you try to use objects
with the value-based STL library.
But the point that needs to be made here is that using smart pointers
in a container is not a work around. Smart pointers are a means to
perform resource control.
Since 'smart pointers' only try to imitate real pointers the
'impedance mismatch' is the same.
I'm unsure as to how I should respond to this.
Yes, smart pointers only imitate real pointers. They are actually
objects that use a little voodoo to track the resources they own (The
underlying raw pointer). Because they are objects, they can be copied
and assigned. Writing code without smart pointers is ill-advised in my
opinion.
The only 'mismatch' that occurs with the objects used in the STL is
when the object doesn't support something required of it. The
algorithms in the STL were designed to work with any user defined type
as long as those types support a few basic operations. Obviously, if
something doesn't meet these requirements it won't work. You'll find
this happens alot when requirements aren't met.
In general, STL is the attempt introduce the functional paradigm into
the C++ language as counterpart to the object-oriented paradigm. This
attempt has produced much misunderstanding and confusion.
Obviously the STL can be misunderstood...
Best wishes,
Roland Pibinger