473,326 Members | 2,048 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

Deriving from STL containers

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

Nov 10 '06 #1
15 4022
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
Nov 10 '06 #2
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
Nov 10 '06 #3
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
Nov 10 '06 #4
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
Nov 10 '06 #5
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
Nov 10 '06 #6
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
Nov 10 '06 #7

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 ?

Nov 10 '06 #8
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
Nov 10 '06 #9
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
Nov 11 '06 #10

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.

Nov 13 '06 #11
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.
Nov 13 '06 #12
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
Nov 13 '06 #13

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

Nov 13 '06 #14
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.
Nov 19 '06 #15
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.
Nov 20 '06 #16

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

28
by: Steven T. Hatton | last post by:
This may be another question having an obvious answer, but I'm not seeing it. I'm trying to create a class that derives from std::valarray<std::string>. I don't need a template, and I haven't come...
8
by: JustSomeGuy | last post by:
I need to write an new class derived from the list class. This class stores data in the list to the disk if an object that is added to the list is over 1K in size. What methods of the std stl...
3
by: | last post by:
I can not seem to get this to compile with either gcc 3.4 or MSVC++ .NET 2003... (source follows first): ---= BEGIN MyStreamBuffer.h =--- // #IFDEF redundancy left out. #include <streambuf> ...
6
by: Adrian | last post by:
Lint (rightly I believe) complains that deque's destructor is not virtual. So will the following code cause any problems? If I do not derive from Container does that stop problems? Do I manually...
7
by: wangxiaohu | last post by:
I am trying to write a class myVector based on std::vector and add only a sort method. The sort method needs to access the array stored in the base class using iterator. I have following draft...
17
by: mosfet | last post by:
Could someone tell me why it's considered as bad practice to inherit from STL container ? And when you want to customize a STL container, do you mean I need to write tons of code just to avoid to...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.