|
P: n/a
|
HI
If I define the class DoubleMap such that
struct DoubleMap : public std::map<std::string, double>{};
Is there any overhead in calling std::map member functions ?
Moreover are STL containers destructors virtual >
N
| |
Share this Question
|
P: n/a
|
BTW .. I know I can do a typedef
so let me re-define DoubleMap to clarify my question .
template<typename Key>
struct DoubleMap : public std::map<Key, double>{};
Nind...@yahoo.co.uk wrote:
HI
If I define the class DoubleMap such that
struct DoubleMap : public std::map<std::string, double>{};
Is there any overhead in calling std::map member functions ?
Moreover are STL containers destructors virtual >
N
| |
|
P: n/a
|
again sorry ..... lets suppose I have put in the necessary
constructors.
the is
template<typename Key>
struct DoubleMap : public std::map<Key, double>{
DoubleMap():std::map<Ky,double>(){}
}; Ni*****@yahoo.co.uk wrote:
BTW .. I know I can do a typedef
so let me re-define DoubleMap to clarify my question .
template<typename Key>
struct DoubleMap : public std::map<Key, double>{};
Nind...@yahoo.co.uk wrote:
HI
If I define the class DoubleMap such that
struct DoubleMap : public std::map<std::string, double>{};
Is there any overhead in calling std::map member functions ?
Moreover are STL containers destructors virtual >
N
| |
|
P: n/a
| Ni*****@yahoo.co.uk wrote:
BTW .. I know I can do a typedef
so let me re-define DoubleMap to clarify my question .
template<typename Key>
struct DoubleMap : public std::map<Key, double>{};
Nind...@yahoo.co.uk wrote:
Oops: (a) please note that top-posting is frowned upon in this group by
virtually all regulars.
>HI
If I define the class DoubleMap such that
struct DoubleMap : public std::map<std::string, double>{};
Is there any overhead in calling std::map member functions ?
No.
>Moreover are STL containers destructors virtual >
No. That means you should not use pointers to STL containers
polymorphically.
Also note that public inheritance can yield funny results when you have
functions with signature
STL_container<Tdo_something ( STL_container<Tconst & );
In this case, your derived classes will match, but the return type will
probably not be what you expect. Note that private inheritance does not
involve any of this trickyness.
>>
N
Oops: Also: please do not quote signatures.
Best
Kai-Uwe Bux | |
|
P: n/a
|
Kai-Uwe Bux wrote:
>Nind...@yahoo.co.uk wrote:
>>Moreover are STL containers destructors virtual >
No. That means you should not use pointers to STL containers
polymorphically.
I think you wanted to say "you should not *delete* pointers to your
classes through pointers to STL containers from which your classes
derive". Standard containers don't have virtual functions (AFAICR),
so using them polimorphically is kind of impossible.
[..]
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask | |
|
P: n/a
|
sorry am a newbie .. what is top-posting and did I do it ?
Kai-Uwe Bux wrote:
Ni*****@yahoo.co.uk wrote:
BTW .. I know I can do a typedef
so let me re-define DoubleMap to clarify my question .
template<typename Key>
struct DoubleMap : public std::map<Key, double>{};
Nind...@yahoo.co.uk wrote:
Oops: (a) please note that top-posting is frowned upon in this group by
virtually all regulars.
HI
If I define the class DoubleMap such that
struct DoubleMap : public std::map<std::string, double>{};
Is there any overhead in calling std::map member functions ?
No.
Moreover are STL containers destructors virtual >
No. That means you should not use pointers to STL containers
polymorphically.
Also note that public inheritance can yield funny results when you have
functions with signature
STL_container<Tdo_something ( STL_container<Tconst & );
In this case, your derived classes will match, but the return type will
probably not be what you expect. Note that private inheritance does not
involve any of this trickyness.
>
N
Oops: Also: please do not quote signatures.
Best
Kai-Uwe Bux
| |
|
P: n/a
| Ni*****@yahoo.co.uk wrote:
sorry am a newbie .. what is top-posting and did I do it ?
You did again! ;)
top-post is when you post your reply on top of the sender's text. I put
my reply below your text, and that's the way it should be. We can then
read it in the same order it was posted.
cheers,
--renato
--
Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm | |
|
P: n/a
|
Renato Golin wrote:
Ni*****@yahoo.co.uk wrote:
sorry am a newbie .. what is top-posting and did I do it ?
You did again! ;)
top-post is when you post your reply on top of the sender's text. I put
my reply below your text, and that's the way it should be. We can then
read it in the same order it was posted.
cheers,
--renato
--
Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm
Oh I see .. so this correct right ? | |
|
P: n/a
| Ni*****@yahoo.co.uk wrote:
Renato Golin wrote:
>top-post is when you post your reply on top of the sender's text. I put
my reply below your text, and that's the way it should be. We can then
read it in the same order it was posted.
Oh I see .. so this correct right ?
Almost... ;)
It's also a good practice to delete the sender's signature so your reply
goes exactly below my text, as in questions and answers. See how I
trimmed the text up there? Some would even remove my text and let only
the line you wrote, but that can also affect the logic flow.
With multiple questions post every answer below the right question.
cheers,
--renato
--
Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm | |
|
P: n/a
|
Victor Bazarov wrote:
Kai-Uwe Bux wrote:
>>Nind...@yahoo.co.uk wrote:
Moreover are STL containers destructors virtual >
No. That means you should not use pointers to STL containers
polymorphically.
I think you wanted to say "you should not *delete* pointers to your
classes through pointers to STL containers from which your classes
derive".
Yes, thanks.
Standard containers don't have virtual functions (AFAICR),
so using them polimorphically is kind of impossible.
I was using the phrase "to use polymorphically" more loosely. To me, the
very fact that a B* may have a different dynamic type qualifies as
polymorphic use. I don't know whether there is some standard terminology
that settles this language issue. However, the wording you proposed is
definitely less ambiguous.
Best
Kai-Uwe Bux | |
|
P: n/a
|
Kai-Uwe Bux wrote:
Victor Bazarov wrote:
Kai-Uwe Bux wrote:
>Nind...@yahoo.co.uk wrote:
Moreover are STL containers destructors virtual >
No. That means you should not use pointers to STL containers
polymorphically.
I think you wanted to say "you should not *delete* pointers to your
classes through pointers to STL containers from which your classes
derive".
Yes, thanks.
Standard containers don't have virtual functions (AFAICR),
so using them polimorphically is kind of impossible.
I was using the phrase "to use polymorphically" more loosely. To me, the
very fact that a B* may have a different dynamic type qualifies as
polymorphic use. I don't know whether there is some standard terminology
that settles this language issue. However, the wording you proposed is
definitely less ambiguous.
Actualy I have been thinking about this. I don't think its a ver bad
idea inheriting from STL containers. Firstly they don't have virtual
destructors, so it is very unlikely they were designed to be base
classes. Not having virtual destuctors makes them very error prone.
Secondly isn't ( when we have a choice) composition better than
inheritence since it is a weaker dependency so then doesn't that
naturaly lead to some sort of pmpl or bridge pattern instead ? Why not
use a pmpl or bridge ? well because there is alot more typing involved,
but this is a price I am willing to pay.
I also think its very easy to overlook the lack of virtual destructor
and use the derived class a template parameter to a smart pointer, not
good. I think I will avoid inheriting from STL containers. | |
|
P: n/a
|
Nindi wrote:
>
I also think its very easy to overlook the lack of virtual destructor
and use the derived class a template parameter to a smart pointer, not
good.
This will work just fine with TR1's shared_ptr. It remembers the type
you passed to it, and deletes it appropriately.
struct S : vector<int{};
std::tr1::shared_ptr<vector<int>sp(new S);
There's no problem when this goes out of scope: S::~S() is used to
destroy the object.
--
-- Pete
Roundhouse Consulting, Ltd. -- www.versatilecoding.com
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see www.petebecker.com/tr1book. | |
|
P: n/a
|
Nindi wrote:
Kai-Uwe Bux wrote:
>Victor Bazarov wrote:
>>Kai-Uwe Bux wrote:
Nind...@yahoo.co.uk wrote:
>Moreover are STL containers destructors virtual >
No. That means you should not use pointers to STL containers
polymorphically.
I think you wanted to say "you should not *delete* pointers to your
classes through pointers to STL containers from which your classes
derive".
Yes, thanks.
>>Standard containers don't have virtual functions (AFAICR),
so using them polimorphically is kind of impossible.
I was using the phrase "to use polymorphically" more loosely. To me,
the very fact that a B* may have a different dynamic type qualifies
as polymorphic use. I don't know whether there is some standard
terminology that settles this language issue. However, the wording
you proposed is definitely less ambiguous.
Actualy I have been thinking about this. I don't think its a ver bad
idea inheriting from STL containers.
The statement above goes out of tune with what you say after it.
Firstly they don't have virtual
destructors, so it is very unlikely they were designed to be base
classes. Not having virtual destuctors makes them very error prone.
Secondly isn't ( when we have a choice) composition better than
inheritence since it is a weaker dependency so then doesn't that
naturaly lead to some sort of pmpl or bridge pattern instead ? Why
not use a pmpl or bridge ? well because there is alot more typing
involved, but this is a price I am willing to pay.
I also think its very easy to overlook the lack of virtual destructor
and use the derived class a template parameter to a smart pointer, not
good. I think I will avoid inheriting from STL containers.
Motorcycles do not have safety belts. Nor do they (at least those that
I know of) have airbags. Yet people ride them and enjoy all the nice
things one can enjoy while riding on a motorcycle (compared to cars or
trucks or buses).
Absence of a virtual destructor is NOT a valid reason not to derive
from a class IMO. It is usually just an excuse. You can quote me on
that.
Absence of virtual functions (d-tors or otherwise) means the class is
not intended to be used polymorphically. Polymoprhic use cannot go
without deriving. Deriving, however, can very simply survive and be
successfully used without polymorphic use.
If you're afraid to make a mistake, by all means, don't inherit from
standard containers (or any other classes).
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask | |
|
P: n/a
|
Victor Bazarov wrote:
Nindi wrote:
Kai-Uwe Bux wrote:
Victor Bazarov wrote:
Kai-Uwe Bux wrote:
Nind...@yahoo.co.uk wrote:
Moreover are STL containers destructors virtual >
No. That means you should not use pointers to STL containers
polymorphically.
I think you wanted to say "you should not *delete* pointers to your
classes through pointers to STL containers from which your classes
derive".
Yes, thanks.
Standard containers don't have virtual functions (AFAICR),
so using them polimorphically is kind of impossible.
I was using the phrase "to use polymorphically" more loosely. To me,
the very fact that a B* may have a different dynamic type qualifies
as polymorphic use. I don't know whether there is some standard
terminology that settles this language issue. However, the wording
you proposed is definitely less ambiguous.
Actualy I have been thinking about this. I don't think its a ver bad
idea inheriting from STL containers.
The statement above goes out of tune with what you say after it.
Firstly they don't have virtual
destructors, so it is very unlikely they were designed to be base
classes. Not having virtual destuctors makes them very error prone.
Secondly isn't ( when we have a choice) composition better than
inheritence since it is a weaker dependency so then doesn't that
naturaly lead to some sort of pmpl or bridge pattern instead ? Why
not use a pmpl or bridge ? well because there is alot more typing
involved, but this is a price I am willing to pay.
I also think its very easy to overlook the lack of virtual destructor
and use the derived class a template parameter to a smart pointer, not
good. I think I will avoid inheriting from STL containers.
Motorcycles do not have safety belts. Nor do they (at least those that
I know of) have airbags. Yet people ride them and enjoy all the nice
things one can enjoy while riding on a motorcycle (compared to cars or
trucks or buses).
Absence of a virtual destructor is NOT a valid reason not to derive
from a class IMO. It is usually just an excuse. You can quote me on
that.
Absence of virtual functions (d-tors or otherwise) means the class is
not intended to be used polymorphically. Polymoprhic use cannot go
without deriving. Deriving, however, can very simply survive and be
successfully used without polymorphic use.
If you're afraid to make a mistake, by all means, don't inherit from
standard containers (or any other classes).
Firstly I would like toapologies for a typo, it should have been
'I DO think its a very bad idea inheriting from STL containers.'
Secondly if there is a more safer and cleaner alternative then I think
by definition its better.
Thirdly, if I am driving a car around town and I choose NOT to wear a
seat belt simply because I always drive below the speed limit with the
utmost due care, it does not eliminate the possibility of a fatal
outcome from the actions of the people I share the road with. Here, as
in the case of deriving from STL containers I have a choice, to wear a
seat belt, or use composition. When I ride a motorbike, I have no such
a choice, so I make do with those restrictions. On the othe hand I
choose to wear a helmet.
I would like to see an example when I should derive from an STL
container and should NOT use composition instead.
'.. provides no virtual functions (other than the destructor which
we'll get to in a minute). This means it is not intended to be used
polymorphically, which is a strong hint against public inheritence.'
Exceptional C++, p82
Sutter
Yes he says PUBLIC inheritence, so maybe there is a case for non-public
inheritence. I think not, these are also mercilessly slaughtered in the
book except in a few special cases, which I am sure do not apply here.
N | |
|
P: n/a
|
Nindi wrote:
Victor Bazarov wrote:
....
'.. provides no virtual functions (other than the destructor which
we'll get to in a minute). This means it is not intended to be used
polymorphically, which is a strong hint against public inheritence.'
Exceptional C++, p82
Sutter
Yes he says PUBLIC inheritence, so maybe there is a case for non-public
inheritence. I think not, these are also mercilessly slaughtered in the
book except in a few special cases, which I am sure do not apply here.
Herb is wrong.
If inheriting an STL class does what you need it to do then do it.
I still have had no-one answer my question regarding the practical
difference in the argument of composition vs inheritance when it comes
to this argument.
I'm not saying you should do it, I'm simply saying that there is no good
reason I see not to do it. The arguments against it do not hold water IMHO. | |
|
P: n/a
|
Gianni Mariani wrote:
Nindi wrote:
>Victor Bazarov wrote:
...
>'.. provides no virtual functions (other than the destructor which
we'll get to in a minute). This means it is not intended to be used
polymorphically, which is a strong hint against public inheritence.'
Exceptional C++, p82
Sutter
Yes he says PUBLIC inheritence, so maybe there is a case for non-public
inheritence. I think not, these are also mercilessly slaughtered in the
book except in a few special cases, which I am sure do not apply here.
Well, I know that std::priority_queue is *designed* to be inherited from
(whether publicly or privately is up for debate). How do I know this?
The internal container is a protected member. | | This discussion thread is closed Replies have been disabled for this discussion. | |  Question stats - viewed: 3289
- replies: 15
- date asked: Nov 10 '06
|
