inheritance from STL-container

inheritance from STL-container

Post by Jazper Man » Wed, 30 Jun 2004 22:44:05


hi

1ST THING...
i read 1000 times not to inherit from a STL-container,
- 'cause STL is not desined for that.
- 'cause STL has no protected members
- 'cause you shouldn't do it
- 'cause 'cause 'cause...

why did they design STL not to be devertable? i mean why should somebody
write a class not to be deverted from? i don't think of spezial algorithms
or something.... i mean standard things like STL??? crazy or stupid? can
anybody explain it to me?

2ND THING...
i have to store the filename when i open a fstream... so i mad my own class
and i did NOT devert from fstream :-) (because i was told not to do it. i
don't know excactly why)
so i made some kind of composition class with fstream member. i made a
method to get the internal reference of the fstream, so that i not have to
implement every method within the fstream just to forward it...

my question now: is this a good idea or a bad implementaion???

--- CODE ---
class myFile
{
public:
myFile(string filename) {
m_filename = filename;
m_file.open(m_filename.c_str(), ios::out);
}
~myFile() {
if( m_file.is_open() )
m_file.close();
}
fstream& getStream() {
return m_file;
}
string& getFilename(){
return m_filename;
}
private:
string m_filename;
fstream m_file;
};

/// Usage...
myFile testfile("c:/temp/gaga.txt");
testfile.getStream() << "test output" << endl;

thanx for every comment or hint!
cheers jazper
 
 
 

inheritance from STL-container

Post by Igor Tande » Wed, 30 Jun 2004 22:49:41


Unlike container classes, stream classes are specifically designed to be
derived from. fstream itself is at the bottom of quite an involved class
hierarchy. So you can happily derive from it.
--
With best wishes,
Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken

 
 
 

inheritance from STL-container

Post by James Curr » Wed, 30 Jun 2004 23:16:50


Because the STL was designed for size & speed efficiency. Creating
derivation-safe versions would compromise both of those.

Further, there is little that can be accomplished with a class derived
from an STL class, that can't be achieved just as easily through
containment.

--
Truth,
James Curran
Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com
(note new day job!)
 
 
 

inheritance from STL-container

Post by tom_usene » Thu, 01 Jul 2004 02:48:28

On Tue, 29 Jun 2004 15:44:05 +0200, "Jazper Manto"



If the container classes were designed to be derived from they would
have virtual functions so that you could modify their behaviour. But
that would hurt performance (both time and space), hence the designers
didn't go down that route (and most are grateful for this).


Just derive from fstream. fstream isn't part of the STL, and is
designed to be inherited from. But note that the only virtual method
in fstream is the destructor (IIRC). If you need to change the
behaviour of an fstream (rather than just add functionality), then you
do it using the streambuf and locale components of the library.

Tom
--
C++ FAQ: http://www.yqcomputer.com/ ++-faq-lite/
C FAQ: http://www.yqcomputer.com/ ~scs/C-faq/top.html
 
 
 

inheritance from STL-container

Post by red floy » Thu, 01 Jul 2004 03:39:31


The *base* containers may not be designed for derivation, but some of
the specialized containers are (though most likely private derivation).

Case in point-- std::priority_queue<>. It contains two protected
members: the container and the comparator. If it was not designed for
some form of derivation, there would be no protected members.

I have code like this:

class MyClass { ... };
class Comparator { ...};
class MyPriorityQueue : private std::priority_queue<MyClass,
std::vector<MyClass>,
Comparator>
{
public:
using std::priority_queue<....>::push;
using std::priority_queue<....>::pop;
// usings to bring the whole std::priority_queue<> interface
// into public
do_something_to_the_queue_container();
do_something_else_to_the_container();
};
 
 
 

inheritance from STL-container

Post by Jazper Man » Thu, 01 Jul 2004 17:13:12

> Unlike container classes, stream classes are specifically designed to be

oh, i didn't know that.
thanx for hint!
jazper
 
 
 

inheritance from STL-container

Post by Jazper Man » Thu, 01 Jul 2004 17:15:59

> Because the STL was designed for size & speed efficiency. Creating
ok. this is an answer and a reason i understand now.
thank you, jazper
 
 
 

inheritance from STL-container

Post by Jazper Man » Thu, 01 Jul 2004 17:22:13

> If the container classes were designed to be derived from they would


ok. this is an answer and a reason i understand now.


oh, i didn't know that.

i must be able to override read, write, <<, >> and constructor.
so i can't do this with fstream? do i have to devert from streambuf?

thanx for hint!
jazper
 
 
 

inheritance from STL-container

Post by tom_usene » Thu, 01 Jul 2004 19:33:09

On Tue, 29 Jun 2004 11:39:31 -0700, red floyd < XXXX@XXXXX.COM >



Private inheritence is fine in general anyway. Even public inheritence
is fine as long as you know what you are doing. My argument against it
is that it is usually the wrong approach - if you want to extend the
functionality of a container, you should write generic algorithms, not
derive and add a new member function. If you need to carry extra data
around with a container, then usually private inheritence is the way
to go, since usually you will want to add extra invariants and
restrictions to the container.

Tom
--
C++ FAQ: http://www.yqcomputer.com/ ++-faq-lite/
C FAQ: http://www.yqcomputer.com/ ~scs/C-faq/top.html
 
 
 

inheritance from STL-container

Post by tom_usene » Thu, 01 Jul 2004 20:53:31

On Wed, 30 Jun 2004 10:22:13 +0200, "Jazper Manto"



If you want to change where the output is going and input is coming
from, you use a streambuf derived class. To change formatting and
parsing you modify locale facets.

For lots of information on streambufs, try searching the C++ google
groups for "streambuf" and "basic_streambuf" and read this:
http://www.yqcomputer.com/

Tom
--
C++ FAQ: http://www.yqcomputer.com/ ++-faq-lite/
C FAQ: http://www.yqcomputer.com/ ~scs/C-faq/top.html
 
 
 

inheritance from STL-container

Post by Jazper Man » Fri, 02 Jul 2004 18:33:24

> For lots of information on streambufs, try searching the C++ google

thank you for hint2 :-)
jazper
 
 
 

inheritance from STL-container

Post by XXXMartin. » Tue, 13 Jul 2004 21:45:49

On Tue, 29 Jun 2004 10:16:50 -0400, "James Curran"


What can that be? I only see the virtual destructor that e.g. the
container classes do not have. Besides that, I do not see how
"derivation safety" would make it slower or bigger. Can you pls expl?


IMHO, very much could be accomplished. Couple of things immediately
come to my mind:

- providing means for DBC (Design by Contract). For Example: testing
whether iterators really point to my container.....

- providing for containers of pointers that obey ownership. For
Example: owned objects should be destroyed. (Sometimes I simply do not
want to use smart pointers)

You always can write a new class B that essentialy contains an
existing class A to avoid inheritance. BUT:

- you have to repeat all public member functions of A in B
- does not work for data in A
- implicit conversions from B to A are not possible (at least not
easily). So using a B "instead of" an A is not possible.

Killer criteria! I want inheritance.

-

------------------------------------------------
Martin Aupperle
Die Kunst der Programmierung mit C++
www.PrimaProgramm.de
------------------------------------------------
 
 
 

inheritance from STL-container

Post by tom_usene » Tue, 13 Jul 2004 22:00:33

On Mon, 12 Jul 2004 12:45:49 GMT,




Giving it any virtual functions adds quite a bit of code bloat - each
container instatiation will add an unnecessary vtable and rtti object
to the object code. For a typical small project with, say, 100
container types, that amounts to perhaps 20KB of waste in the final
executable.


The functions aren't virtual, so you can't change them; you can only
"hide" them.


You can't force your derived methods to be called. If a base class
reference is used, the base class methods will be called, breaking
your class. You haven't got an is-a relationship.


From your examples above it seems you want every method of the
container classes to be virtual, which adds a lot of bloat and a bit
performance hit.

The std::containers are building blocks. If you want your own virtual
inheritence heirarchy of containers, feel free to create it using the
std::containers as the basis, just don't make everyone else pay the
performance penalty. Creating a similar heirarchy to the Java
collections one in C++ is pretty easy, and might be useful for some.

Finally, IIRC there is a section in The C++ Programming Language by
Stroustrup describing why the current design was chosen from amongst
the competing ones (including one with virtual functions as you want).

Tom
 
 
 

inheritance from STL-container

Post by Jerry Coff » Fri, 23 Jul 2004 13:36:40

In article < XXXX@XXXXX.COM >,
XXXX@XXXXX.COM says...

[ ... ]


How exactly would inheriting from a container help in that?


I wrote a number of containers like this before the standard came
along. My conclusion is that they're impossible to do well, and any
support for them would be a disadvantage.


At least all those you want to make public in B -- but if this is a
very large number, chances are that A has problems anyway.


The data's usually private, so it's not applicable. If the data IS
public (and should be) then it's trivial to add a reference to B, and
initialize it to the data member of A.


How is it not easy?

class B {
A base;
public:
operator A&() { return base; }
};


You may want it, but it appears to me that there's only an advantage
when either the base or derived class (or generally both) is already
quite poorly designed. It seems to me that asking all code to pay a
penalty to support only poorly-designed code is a poor tradeoff at
best.

--
Later,
Jerry.

The universe is a figment of its own imagination.
 
 
 

inheritance from STL-container

Post by XXXMartin. » Thu, 29 Jul 2004 01:56:01

>> - providing means for DBC (Design by Contract). For Example: testing
class D : public B
{
...
void f();
};

void D::f()
{
ASSERT( whatever ); // DBC-precondition

B::f();

ASSERT( something ); // postcondition
}



I did the same, and I find it convenient to have a container that
stores pointers but also is the owner of the objects.

I did not ask for support of such a container by the Standard. But I
ask for a design that allows me to do it myself.

Pls explain why you find that it is difficult to do well, and also
tell me what you use instead.


Not necessarily. Are you a friend of styleguides that say "a class
must not have more than x members" ? A class must have an (explicit)
destructor, copy constructor etc?

No no, there is absolutely no correlation between size and quality of
a class. E.G. we have a grid that has well over 50 public functions,
not counted the interface for the data model and the selection model
(which can be plugged in). Is that bad? Why do we have problems anyway
here? Would these problems go away if the functionality is divided
into even more classes? I doubt.


You can do that, but

A*a = whatever_cast<A*>(b)
B* b = dynamic_cast<B*>(a)

does not work, IMHO.



Well, I agree that there is something like "design for STL". But I
would not say that designs that do not confirm to that are
automatically poor.

You might tell me pls how you handle ownership in your programs, and
why having the container do it is bad.

I agree. But I do not see why there need to be a tradeoff in the first
place. For example, one could provide a trait that specifies whether
the dtor should be virtual, or not.

-

------------------------------------------------
Martin Aupperle
Die Kunst der Programmierung mit C++
www.PrimaProgramm.de
------------------------------------------------