Re: inheritance from STL-container
From: Martin Aupperle (XXXMartin.Aupperle_at_PrimaProgrammXXX.de)
Date: 07/27/04
- Next message: Igor Tandetnik: "Re: inheritance from STL-container"
- Previous message: Jason Winnebeck: "Re: unique"
- In reply to: Jerry Coffin: "Re: inheritance from STL-container"
- Next in thread: Igor Tandetnik: "Re: inheritance from STL-container"
- Reply: Igor Tandetnik: "Re: inheritance from STL-container"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 27 Jul 2004 16:56:01 GMT
>> - providing means for DBC (Design by Contract). For Example: testing
>> whether iterators really point to my container.....
>
>How exactly would inheriting from a container help in that?
>
class D : public B
{
...
void f();
};
void D::f()
{
ASSERT( whatever ); // DBC-precondition
B::f();
ASSERT( something ); // postcondition
}
>> - 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)
>
>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.
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.
>
>> 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
>
>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.
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.
>> - implicit conversions from B to A are not possible (at least not
>> easily). So using a B "instead of" an A is not possible.
>
>How is it not easy?
>
>class B {
> A base;
>public:
> operator A&() { return base; }
>};
>
You can do that, but
A*a = whatever_cast<A*>(b)
B* b = dynamic_cast<B*>(a)
does not work, IMHO.
>> Killer criteria! I want inheritance.
>
>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.
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.
>It seems to me that asking all code to pay a
>penalty to support only poorly-designed code is a poor tradeoff at
>best.
>
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
------------------------------------------------
- Next message: Igor Tandetnik: "Re: inheritance from STL-container"
- Previous message: Jason Winnebeck: "Re: unique"
- In reply to: Jerry Coffin: "Re: inheritance from STL-container"
- Next in thread: Igor Tandetnik: "Re: inheritance from STL-container"
- Reply: Igor Tandetnik: "Re: inheritance from STL-container"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
