In article <3A5F21D9.828DC377@spamcop.net>,
  Ron Natalie <ron@spamcop.net> wrote:
>
>
> Roger Orr wrote:
> >
> > extern void function( vector<int> & vec );
> >
> > Vec<int> v;
> >
> > function( v ); // any uses of operator[] will not be range checked.
> >
> But fucntion() won't be expecting them to be range checked either.
> It knows it's using a vector<int> and that [] is not rangechecked.
> It's only people who know they are using Vec<int> that can let their
> guard down.

Yes, I know - but this is only because operator[] is non-virtual.
Many programmers (but not on this forum!) might 'hope' the calls to
operator[] would be range checked.
Depending upon the skill level of your team you might view Vec<> as
'dangerous' for this reason.
--
Roger Orr. MVP in C++ for Brainbench at http://www.brainbench.com


Sent via Deja.com
http://www.deja.com/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

On Fri, 12 Jan 2001 16:44:53 GMT, Ron Natalie wrote:
> But fucntion() won't be expecting them to be range checked either.

But function's caller probably will.

Scott

--
I've scheduled more public seminars.  Check out
http://www.aristeia.com/seminars/ for details.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <93id26$bds$1@watserv3.uwaterloo.ca>,
  afnevrau@student.math.uwaterloo.ca (Adam Frank Nevraumont) wrote:
> In article <PAdWcgDlujV6EwJd@ntlworld.com>,
> Francis Glassborow  <francisG@robinton.demon.co.uk> wrote:
> >In article <3A54C098.C931A822@jps.net>, Dennis Yelle
<dennis51@jps.net>
> >writes
> >>On page 53 of TC++PL3d, Stroustrup defines a range checked
> >>vector template class Vec as follows:
> >>
> >>----------------------------------------------------
> >>  template< class T> class Vec : public vector<T> {
> >>  public:
> >>    Vec() : vector<T>() {}
> >>    Vec( int s) : vector<T>(s) {}
> >>    T& operator[](int i) { return at(i); }              // range
checked
> >>    const T& operator[](int i) const { return at(i); }  // range
checked
> >>  };
[snip]
> In any case, what, under the standard, can go wrong with the Vec<T>?

Others have mentioned the problems with dynamic polymorphism, there is
another with static polymorphism:

    void f() {
        Vec<int> a;
        Vec<int> b;

        // . . .
        std::swap(a, b);  // calls the generic implementation of swap
        // . . .
    }

Here std::swap is an example of a template function that is overloaded
for std::vector - to give a non-throwing (and presumably efficient)
version.
--
Alan Griffiths                        http://www.octopull.demon.co.uk/
Senior Systems Consultant, Experian   tel: +44 115 968 5118
Chair, Association of C and C++ Users http://accu.org/


Sent via Deja.com
http://www.deja.com/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <PAdWcgDlujV6EwJd@ntlworld.com>,
Francis Glassborow  <francisG@robinton.demon.co.uk> wrote:
>In article <3A54C098.C931A822@jps.net>, Dennis Yelle <dennis51@jps.net>
>writes
>>On page 53 of TC++PL3d, Stroustrup defines a range checked
>>vector template class Vec as follows:
>>
>>----------------------------------------------------
>>  template< class T> class Vec : public vector<T> {
>>  public:
>>    Vec() : vector<T>() {}
>>    Vec( int s) : vector<T>(s) {}
>>    T& operator[](int i) { return at(i); }              // range checked
>>    const T& operator[](int i) const { return at(i); }  // range checked
>>  };
>>-----------------------------------------------------
>>
>>Is the code above wrong?
>
>For real use? Yes (and when Bjarne explains why I am wrong I will buy
>him a drink - I am told the beer in Copenhagen is quite good:)

The code above is not wrong.

No data is stored in the class Vec<T>, all that is done is that member
functions are redirected.  Hence, the non-virtual dtor of vector<T> is
sufficient.

A Vec<T> _is a_ vector<T>, it is just a different way of looking at it.
A vector<T> _is a_ Vec<T>, in the same way a Vec is a vector, wierdly
enough, although the language doesn't quite support it.

I would be leery about using the above Vec<T> without declairing a copy-
constructor, but my instincts tell me that is just because I don't quite
have enough faith in those annoying implicitly declaired copy constructors.

In any case, what, under the standard, can go wrong with the Vec<T>?

--
Adam at nevraumont.ca            'Me transmitte sursum, Caledoni!' -- JTK
'If you're a capitalist and you have the best goods and they're free,
 you don't have to proselytize, you just have to wait.' -- MOGLEN
Hi.  Im the signature immune system.  Why dont you copy me into your .sig?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Part of what can go wrong with it is that someone can attempt to delete it
through a pointer to vector<T>.  The standard in 5.3.5/3 states that doing
so results in undefined behavior.  As soon as I read the standard I
submitted a defect report claiming the behavior should only be undefined if
a derived class had specified additional data members or an explicit
destructor, which would have made the example shown acceptable.  Every
implementation I've seen already produces 'correct' behavior in the scenario
I describe, however my defect report was rejected.

"Adam Frank Nevraumont" <afnevrau@student.math.uwaterloo.ca> wrote in
message news:93id26$bds$1@watserv3.uwaterloo.ca...
> In article <PAdWcgDlujV6EwJd@ntlworld.com>,
> Francis Glassborow  <francisG@robinton.demon.co.uk> wrote:
> >In article <3A54C098.C931A822@jps.net>, Dennis Yelle <dennis51@jps.net>
> >writes
> >>On page 53 of TC++PL3d, Stroustrup defines a range checked
> >>vector template class Vec as follows:
> >>
> >>----------------------------------------------------
> >>  template< class T> class Vec : public vector<T> {
> >>  public:
> >>    Vec() : vector<T>() {}
> >>    Vec( int s) : vector<T>(s) {}
> >>    T& operator[](int i) { return at(i); }              // range checked
> >>    const T& operator[](int i) const { return at(i); }  // range checked
> >>  };
> >>-----------------------------------------------------
> >>
> >>Is the code above wrong?
> >
> >For real use? Yes (and when Bjarne explains why I am wrong I will buy
> >him a drink - I am told the beer in Copenhagen is quite good:)
>
> The code above is not wrong.
>
> No data is stored in the class Vec<T>, all that is done is that member
> functions are redirected.  Hence, the non-virtual dtor of vector<T> is
> sufficient.
> ...
>
> In any case, what, under the standard, can go wrong with the Vec<T>?
>


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <93id26$bds$1@watserv3.uwaterloo.ca>, Adam Frank Nevraumont
<afnevrau@student.math.uwaterloo.ca> writes
>In article <PAdWcgDlujV6EwJd@ntlworld.com>,
>Francis Glassborow  <francisG@robinton.demon.co.uk> wrote:
>>In article <3A54C098.C931A822@jps.net>, Dennis Yelle <dennis51@jps.net>
>>writes
>>>On page 53 of TC++PL3d, Stroustrup defines a range checked
>>>vector template class Vec as follows:
>>>
>>>----------------------------------------------------
>>>  template< class T> class Vec : public vector<T> {
>>>  public:
>>>    Vec() : vector<T>() {}
>>>    Vec( int s) : vector<T>(s) {}
>>>    T& operator[](int i) { return at(i); }              // range checked
>>>    const T& operator[](int i) const { return at(i); }  // range checked
>>>  };
>>>-----------------------------------------------------
>>>
>>>Is the code above wrong?
>>
>>For real use? Yes (and when Bjarne explains why I am wrong I will buy
>>him a drink - I am told the beer in Copenhagen is quite good:)
>
>The code above is not wrong.
>
>No data is stored in the class Vec<T>, all that is done is that member
>functions are redirected.  Hence, the non-virtual dtor of vector<T> is
>sufficient.

Perhaps you were misled by my 'For real use?' Under the language rules,
any attempt to delete a Vec<> through a vector<T>* is undefined. There
are then further things you must consider because the mechanisms of the
STL depend on iterators, so are you sure that those must work as you
expected?

I did not lightly criticise BS code:)


Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Adam Frank Nevraumont wrote:
>
> In any case, what, under the standard, can go wrong with the Vec<T>?
>

vector<T>* tp = new Vec<T>;
delele  tp;

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

On Wed, 10 Jan 2001 13:34:44 CST,
afnevrau@student.math.uwaterloo.ca (Adam Frank Nevraumont) wrote:

>In article <PAdWcgDlujV6EwJd@ntlworld.com>,
>Francis Glassborow  <francisG@robinton.demon.co.uk> wrote:
>>In article <3A54C098.C931A822@jps.net>, Dennis Yelle <dennis51@jps.net>
>>writes
>>>On page 53 of TC++PL3d, Stroustrup defines a range checked
>>>vector template class Vec as follows:
>>>
>>>----------------------------------------------------
>>>  template< class T> class Vec : public vector<T> {
>>>  public:
>>>    Vec() : vector<T>() {}
>>>    Vec( int s) : vector<T>(s) {}
>>>    T& operator[](int i) { return at(i); }              // range checked
>>>    const T& operator[](int i) const { return at(i); }  // range checked
>>>  };
>>>-----------------------------------------------------
>>>
>>>Is the code above wrong?
>>
>>For real use? Yes (and when Bjarne explains why I am wrong I will buy
>>him a drink - I am told the beer in Copenhagen is quite good:)
>
>The code above is not wrong.
>
>No data is stored in the class Vec<T>, all that is done is that member
>functions are redirected.  Hence, the non-virtual dtor of vector<T> is
>sufficient.
>
>A Vec<T> _is a_ vector<T>, it is just a different way of looking at it.
>A vector<T> _is a_ Vec<T>, in the same way a Vec is a vector, wierdly
>enough, although the language doesn't quite support it.
>
>I would be leery about using the above Vec<T> without declairing a copy-
>constructor, but my instincts tell me that is just because I don't quite
>have enough faith in those annoying implicitly declaired copy constructors.
>
>In any case, what, under the standard, can go wrong with the Vec<T>?

The usual problem.  Consider

 std::vector<int>* v = new Vec<int>;
 delete v; // undefined behavior

It's arguable whether this is a severe enough problem to say that
Vec is unusable (i.e., whether documenting that a Vec must never
be deleted using a pointer to std::vector is sufficient), but
there certainly is a potential problem.
--
Michael M Rubenstein

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <93id26$bds$1@watserv3.uwaterloo.ca>,
  afnevrau@student.math.uwaterloo.ca (Adam Frank Nevraumont) wrote:
[snip]
> >>On page 53 of TC++PL3d, Stroustrup defines a range checked
> >>vector template class Vec as follows:
> >>
> >>----------------------------------------------------
> >>  template< class T> class Vec : public vector<T> {
> >>  public:
> >>    Vec() : vector<T>() {}
> >>    Vec( int s) : vector<T>(s) {}
> >>    T& operator[](int i) { return at(i); }              // range
checked
> >>    const T& operator[](int i) const { return at(i); }  // range
checked
> >>  };
[snip]
> In any case, what, under the standard, can go wrong with the Vec<T>?

It depends what you mean by 'go wrong' ... anything like this won't do
what you might hope:-

extern void function( vector<int> & vec );

Vec<int> v;

function( v ); // any uses of operator[] will not be range checked.

--
Roger Orr. MVP in C++ for Brainbench at http://www.brainbench.com


Sent via Deja.com
http://www.deja.com/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Roger Orr wrote:
>
> extern void function( vector<int> & vec );
>
> Vec<int> v;
>
> function( v ); // any uses of operator[] will not be range checked.
>
But fucntion() won't be expecting them to be range checked either.
It knows it's using a vector<int> and that [] is not rangechecked.
It's only people who know they are using Vec<int> that can let their
guard down.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A54C098.C931A822@jps.net>, Dennis Yelle <dennis51@jps.net>
writes
>On page 53 of TC++PL3d, Stroustrup defines a range checked
>vector template class Vec as follows:
>
>----------------------------------------------------
>  template< class T> class Vec : public vector<T> {
>  public:
>    Vec() : vector<T>() {}
>    Vec( int s) : vector<T>(s) {}
>    T& operator[](int i) { return at(i); }              // range checked
>    const T& operator[](int i) const { return at(i); }  // range checked
>  };
>-----------------------------------------------------
>
>Is the code above wrong?

For real use? Yes (and when Bjarne explains why I am wrong I will buy
him a drink - I am told the beer in Copenhagen is quite good:)


Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A54305F.2412D3B8@grad.hr>, Kresimir Fresl <fresl@grad.hr>
writes
>fit into this (almost religious ;O) adherence to `inheritence
>with virtual functions only' (at least with virtual destructor)?

They should either have a virtual dtor or a protected one.


Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Francis Glassborow wrote:

>
> For real use? Yes (and when Bjarne explains why I am wrong I will buy
> him a drink - I am told the beer in Copenhagen is quite good:)

Too bad, Bjarne is in New Jersey, where the beer is not good at all.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A564059.44431ADF@spamcop.net>, Ron Natalie
<ron@spamcop.net> writes
>Too bad, Bjarne is in New Jersey, where the beer is not good at all.

But he will not be the next time I see him (in April)

>

Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Kresimir Fresl <fresl@grad.hr> writes:

|>  Some time ago I asked the following question in
|>  `comp.lang.c++.moderated', but no one replies, so here it is again:

|>  How mixins, as described in, eg.:

|>    M. VanHils & D. Notkin:=20
|>      `Using C++ Templates to Implement Role-Based Designs'
|>      `Using Role Components to Implement Collaboration-Based Designs'
|>    Y. Smaragdakis & D. Batory:
|>      `Implementing Reusable Object-Oriented Components'
|>      `Implementing Layered Designs with Mixin Layers'
|>      `Mixin-Based Programming in C++'
|>    U. Eisenecker, F. Blinn, K. Czarnecki:
|>      `A Solution to the Constructor-Problem of Mixin-Based
|>       Programming in C++'
|>      (http://www.oonumerics.org/tmpw00/eisenecker.html)

|>  fit into this (almost religious ;O) adherence to `inheritence=20
|>  with virtual functions only' (at least with virtual destructor)?

I've not seen any of these articles, but the mixin's I've written all
make extensive use of virtual functions.  I don't see how it could be
otherwise; the user of the mixin normally only sees the base class
anyway.

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

James Kanze wrote:

> Kresimir Fresl <fresl@grad.hr> writes:

> |>  How mixins, as described in, eg.:
[list of articles deleted]
> |>  fit into this (almost religious ;O) adherence to `inheritence
> |>  with virtual functions only' (at least with virtual destructor)?
>
> I've not seen any of these articles,

Maybe you should ;O)

> but the mixin's I've written all
> make extensive use of virtual functions.

There are different types of mixins i.e. different ways to
implement a mixin; to quote from
  `http://www.oonumerics.org/tmpw00/eisenecker.html':

``One possibility to model mixins in OO languages is to use
  classes and multiple inheritance. In this model, a mixin is
  represented as a class, which is then referred to as a mixin
  class, and we derive a composed class from a number of mixin
  classes using multiple inheritance. Another possibility is to
  use parameterized inheritance. In this case, we can represent
  a mixin as a class template derived from its parameter, e.g.:
    template<class Base>
    class Printing : public Base
    {...}
  Indeed, some authors (e.g., [BC90]) define mixins as `abstract
  subclasses' (i.e., subclasses without a concrete superclass).
  Mixins based on parameterized inheritance in C++ have been
  used to implement highly configurable collaboration-based and
  layered designs (e.g., see [VN96, SB98]).''

  [BC90] Bracha, Cook: Mixin-Based Inheritance
  [SB98] Smaragdakis, Batory: Implementing Layered Designs with
         Mixin Layers
  [VN96] VanHils, Notkin: Using Role Components to Implement
         Collaboration-Based Designs
  (All mentioned articles can be found with e.g. Google search.)

I have in mind the latter kind of mixins.

> I don't see how it could be otherwise; the user of the
> mixin normally only sees the base class anyway.

Not neccessarily; take a look at definitions and uses of
visitors and vertex and edge properties in the Boost
Graph Library (http://www.boost.org/); simplest example
is, probably, file/program `edge_property.cpp' in the
examples directory).


fres

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Ron Natalie wrote:
>
> Julian Smith wrote:
> >
> >
> > Sure it's dangerous to derive from a class that has no virtual
> > destructor, but having lots of boiler plate code isn't perfect either.
>
> The danger is limitted.  Are you really going to do something like:
>
>         vector<T>* x = new MyVector<T>;
>         delete x;
>
> ???

Of course, though not that directly. The 'new' statement would generally
occur in one piece of code that is specific to MyVector, and would
probably be initially assigned to a MyVector<T>* pointer. It would only
get stored in a std::vector<T>* pointer somewhere later along the line,
and the 'delete' expression would occur in code associated with that
pointer, rather than with the initial one.

A perfectly ordinary case where you might want to do this is in a
container< vector<T>* >, which has been extended beyond the container
requirements to automatically deallocate the pointed-at vector any time
a pointer itself gets erased. This is a standard technique for emulating
a container of polymorphic objects, but it won't actually allow
polymorphism unless the base class has a virtual destructor.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Francis Glassborow wrote:

> Kresimir Fresl <fresl@grad.hr> writes

[How mixins]
> >fit into this (almost religious ;O) adherence to `inheritence
> >with virtual functions only' (at least with virtual destructor)?

> They should either have a virtual dtor or a protected one.

But `they'[*], at least in type of mixins I am talking about
(and, of course, this is not the only type of mixins),
have neither virtual dtor nor a protected one: for example,
this kind of mixins is used to implement vertex and edge
properties as well as visitors in the Boost Graph Library:

  `http://www.boost.org/libs/graph/doc/table_of_contents.html'

fres



[*] In fact, not `they', but their unspecified base class(es);
to quote from  `http://www.oonumerics.org/tmpw00/eisenecker.html':

``A mixin is a fragment of a class in the sense that it is
  intended to be composed with other classes or mixins. [...]
  Another possibility is to use parametrized inheritance. In
  this case, we can represent a mixin as a class template
  derived from its parameter [...] Indeed, some authors (...)
  define mixins as `abstract subclasses' (i.e., subclasses
  without a concrete superclass).''

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Francis Glassborow wrote:
>
> In article <3A564059.44431ADF@spamcop.net>, Ron Natalie
> <ron@spamcop.net> writes
> >Too bad, Bjarne is in New Jersey, where the beer is not good at all.
>
> But he will not be the next time I see him (in April)
>
Ah!  By the way, if either one of you makes it to the DC area,
I'll show you some very beer.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A5895C4.B09D9931@grad.hr>,
  Kresimir Fresl <fresl@grad.hr> wrote:
> Francis Glassborow wrote:
>
> > Kresimir Fresl <fresl@grad.hr> writes
>
> [How mixins]
> > >fit into this (almost religious ;O) adherence to `inheritence
> > >with virtual functions only' (at least with virtual destructor)?
>
> > They should either have a virtual dtor or a protected one.
>
> But `they'[*], at least in type of mixins I am talking about
> (and, of course, this is not the only type of mixins),
> have neither virtual dtor nor a protected one:
[snip]

Then there is the possibility of error in their use.

If you have:
template <class Base>
PhoneContact : public Base
{
};

then code like:-

Customer *c = new PhoneContact<Customer>("some args");
...
delete c;

will not correctly destruct the created object.

A virtual dtor _will_ ensure the object gets created properly.
A protected dtor will _prevent_ the code compiling.

I presume those who use the generic programming paradigm wouldn't
usually make this class of error - but it is still there.

BTW what could we call this sort of mixin programming - it seems like
polymorphism using templates rather than abstract base classes -
 "Compile-time polymorphism", perhaps?

--
Roger Orr. MVP in C++ for Brainbench at http://www.brainbench.com


Sent via Deja.com
http://www.deja.com/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Roger Orr wrote:

> Kresimir Fresl <fresl@grad.hr> wrote:

> > But `they'[*], at least in type of mixins I am talking about
> > (and, of course, this is not the only type of mixins),
> > have neither virtual dtor nor a protected one:

> Then there is the possibility of error in their use.

I am well aware of that. That's what documentation is for.
I also know that ``nobody'' reads documentation [that's why
e.g. some programmers put raw pointers into std::containers and
then wonder why pointed objects are not automaticly/automagicly
destroyed with them; or why some programmers put std::auto_ptrs
into std::containers].

> If you have:
> template <class Base>
> PhoneContact : public Base
> {
> };
>
> then code like:-
>
> Customer *c = new PhoneContact<Customer>("some args");
> ...
> delete c;
>
> will not correctly destruct the created object.

I know. Mixins (of the type I am talking about) are simply
not supposed to be used for run-time polymorphism.

> A virtual dtor _will_ ensure the object gets created properly.

And will induce overhead of one vtable pointer (or something
similar) per object. Maybe it's not significant overhead. But
maybe it is (e.g. we `ran' on PCs some FE models with more than
100000 degrees of freedom).

> A protected dtor will _prevent_ the code compiling.

And will prevent creation of the base class object.
Mixins add `some small functionality slice' to `stand-alone'
classes which in many cases can be used without that addition.

> I presume those who use the generic programming paradigm
> wouldn't usually make this class of error

That's exactly my point. In fact, in my programs [and in
generic libraries I am using (e.g. Boost Graph Library,
Matrix Template Library, Iterative Template Library,
see `http://www.lsc.nd.edu/research/')] there is (almost)
no run-time polymorphism.

> - but it [this class of error] is still there.

... as are many other sources of errors.

> BTW what could we call this sort of mixin programming - it seems
> like polymorphism using templates rather than abstract base
> classes - "Compile-time polymorphism", perhaps?

I am not quite sure that this is polymorphism (in the
usual sense of the word). Or, maybe, it is polymorphism
turned upside down. Mixins are usually added to the base
classes because we need some functionality which those
classes do not have (i.e. mixins add functionality, they
don't `change' it as virtual functions often do) and code
is then written in terms of `leaf' classes (base with mixin).
For example, breadth first search algorithm in Boost Graph
Library expects that graph vertices have color property
-- you can't use BFS algorithm if vertices in your graph
don't have that property; it is therefore added to other
properties vertices might have. On the other hand, it is
completely irelevant (and here polymorphism slunk into
the game) what other, if any, properties vertices have.
(All this is perhaps too simplified, superficial view.)

fres

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Ron Natalie" <ron@spamcop.net> wrote...
> The danger is limitted.  Are you really going to do something like:
>
> vector<T>* x = new MyVector<T>;
> delete x;

The danger may be limited, but inheritance implies an "is a" relationship
(as others in this thread have pointed out, I believe).

I'm well-aware that inheritance has uses beyond defining an is-a
relationship; for example, containment often requires a plethora of simple
"wrapper" methods that may not be required when using inheritance. But the
"is-a" relationship comes with inheritance, even if there is no intent to
use said relationship.

Generally, I believe it is a "bad" idea to inherit from a class that does
not include a virtual or protected destructor -- but as with all rules, it
is meant to be broken when circumstances warrant. If a class derived from
vector<> is never going to be used as a vector<>, and documentation makes
this clear, I have no problem with such.

--
Scott Robert Ladd
http://www.coyotegulch.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Francis Glassborow" <francis.glassborow@ntlworld.com>:
> In article <92qvdu$d27$07$1@news.t-online.com>, Christian Parpart
> <cparpart@surakware.com> writes
> >I don't know if this question is answered in the standard. At least, I
> >couldn't find anything about it. So here it is: are there any problems
when
> >trying to derive a class from one of the STL's class templates, e.g.
> >std::list?
>
> As always, when deriving from a class look at the base class dtor, if it
> is not declared virtual, assume that you are not intended to derive from
> it and do not do so.

I never said I wanted to derived it to use it polymorphically.

sm


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Frank Barwich" <frenki@gmx.de> wrote in message
news:92rlc2$877tb$1@ID-38766.news.dfncis.de...
> Hello Christian,
>
> > I don't know if this question is answered in the standard. At least, I
> > couldn't find anything about it. So here it is: are there any problems
> when
> > trying to derive a class from one of the STL's class templates, e.g.
> > std::list?
>
> Yes, there is a problem: The STL-Containers have no virtual destructors.

On the other hand, in the SGI implementation several have protected data
members, which suggests that private or protected inheritance is OK.

Joe Gottman.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <92uq5t$8c2$02$1@news.t-online.com>,
  "Sebastian Moleski" <smoleski@surakware.com> wrote:
> "Francis Glassborow" <francis.glassborow@ntlworld.com>:
> > In article <92qvdu$d27$07$1@news.t-online.com>, Christian Parpart
> > <cparpart@surakware.com> writes
> > >I don't know if this question is answered in the standard. At
least, I
> > >couldn't find anything about it. So here it is: are there any
problems
> when
> > >trying to derive a class from one of the STL's class templates,
e.g.
> > >std::list?
> >
> > As always, when deriving from a class look at the base class dtor,
if it
> > is not declared virtual, assume that you are not intended to derive
from
> > it and do not do so.
>
> I never said I wanted to derived it to use it polymorphically.

Then public inheritance is not the proper construct for you.  Use
either protected/private inheritance or containment, both of which are
safe for use with classes that do not have virtual d-tors.  Public
inheritance should be reserved for "is-a" situations, which means you
are using it polymorphically.

--
William E. Kempf
Software Engineer, MS Windows Programmer


Sent via Deja.com
http://www.deja.com/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <Ouw46.232$jO.19870@bgtnsc06-news.ops.worldnet.att.net>,
  "Joseph Gottman" <joegottman@worldnet.att.net> wrote:
>
> "Frank Barwich" <frenki@gmx.de> wrote in message
> news:92rlc2$877tb$1@ID-38766.news.dfncis.de...
> > Hello Christian,
> >
> > > I don't know if this question is answered in the standard. At
least, I
> > > couldn't find anything about it. So here it is: are there any
problems
> > when
> > > trying to derive a class from one of the STL's class templates,
e.g.
> > > std::list?
> >
> > Yes, there is a problem: The STL-Containers have no virtual
destructors.
>
> On the other hand, in the SGI implementation several have protected
data
> members, which suggests that private or protected inheritance is OK.

First, in situations where a class has protected members but no virtual
d-tor one would normally assume that protected/private inheritance was
meant to be used, but not public inheritance.  Second, since the
standard does not contain these members I'd assume that it was a
mistake in the SGI implementation and that these members should have
been declared private.

--
William E. Kempf
Software Engineer, MS Windows Programmer


Sent via Deja.com
http://www.deja.com/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <92uq5t$8c2$02$1@news.t-online.com>, Sebastian Moleski
<smoleski@surakware.com> writes
>> As always, when deriving from a class look at the base class dtor, if it
>> is not declared virtual, assume that you are not intended to derive from
>> it and do not do so.
>
>I never said I wanted to derived it to use it polymorphically.

Irrelevant. If it does not have a virtual dtor you should not derive
publicly from it. And if you derive privately, why not use aggregation.


Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <w$upjcCvO8U6Ew0a@ntlworld.com>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
> In article <92uq5t$8c2$02$1@news.t-online.com>, Sebastian Moleski
> <smoleski@surakware.com> writes
> >> As always, when deriving from a class look at the base class dtor,
if it
> >> is not declared virtual, assume that you are not intended to
derive from
> >> it and do not do so.
> >
> >I never said I wanted to derived it to use it polymorphically.
>
> Irrelevant. If it does not have a virtual dtor you should not derive
> publicly from it. And if you derive privately, why not use
aggregation.

I guess the reason it's tempting to use inheritance is that it's a pain
to write lots of fowarding member functions to a contained class's
member functions (or using declarations to a privately-inherited base
class's members).

Sure it's dangerous to derive from a class that has no virtual
destructor, but having lots of boiler plate code isn't perfect either.

I wonder whether it would be useful to introduce a set of inheritance-
friendly standard containers that contain virtual destructors and
boiler-plate forwarding code to private instances of the conventional
containers. Something like (ignoring allocators for now):

#include <vector>
template< class T>
class polyvector // like std::vector, but can be inherited from.
{
  private:
    std::vector<T> m_container;
  public:
    typedef size_type std::vector<T>::size_type;
    typedef iterator std::vector<T>::iterator;
    ...
    explicit polyvector( size_type n) : m_container( n) {}
    iterator begin() { return m_container.begin(); }
    size_type size() const { return m_container.size(); }
    ...
    virtual ~polyvector() {}
};

There might even be a way of specifying the raw container-type as a
template parameter, with the interface being a union of all the
possible container interfaces. This would only work if there are no
inconsistent container member function names - i.e. ones with same name
but different parameter types - and I've no idea whether this is the
case or not.

- Julian

--
http://www.op59.net/


Sent via Deja.com
http://www.deja.com/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <w$upjcCvO8U6Ew0a@ntlworld.com>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
> In article <92uq5t$8c2$02$1@news.t-online.com>, Sebastian Moleski
> <smoleski@surakware.com> writes
> >> As always, when deriving from a class look at the base class dtor,
if it
> >> is not declared virtual, assume that you are not intended to
derive from
> >> it and do not do so.
> >
> >I never said I wanted to derived it to use it polymorphically.
>
> Irrelevant. If it does not have a virtual dtor you should not derive
> publicly from it. And if you derive privately, why not use
aggregation.

If the goal is to create a "better vector" (or other conatainer) that
has all the functionality of the original as well as additional
functionality then private (or possibly even protected) derivation will
be simpler to implement than aggregation.  Rather than having to write
wrapper functions for all of the vector (or other container)
functionality that defers to the aggregate you can simply pull this
functionality out of the base into the public interface with using
declarations.

The other reason to prefer private (or protected) inheritance over
aggregation is to have access to protected members of the base class.
This doesn't apply here, but still should be mentioned.

--
William E. Kempf
Software Engineer, MS Windows Programmer


Sent via Deja.com
http://www.deja.com/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

> On the other hand, in the SGI implementation several have protected data
> members, which suggests that private or protected inheritance is OK.

I think SGI's practice might be dangerously misleading; the Standard itself
does not specify virtual destructors for containers, and code based on SGI's
implementation of such would not be portable to other Standard-conforming
platforms.

In other (and perhaps clearer!) words: Since the Standard does not specify
virtual destructors, portable code should not extend Standard container
classes.

--
Scott Robert Ladd
http://www.coyotegulch.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Julian Smith wrote:
>
>
> Sure it's dangerous to derive from a class that has no virtual
> destructor, but having lots of boiler plate code isn't perfect either.

The danger is limitted.  Are you really going to do something like:

 vector<T>* x = new MyVector<T>;
 delete x;

???

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Francis Glassborow wrote:
>
> In article <92uq5t$8c2$02$1@news.t-online.com>, Sebastian Moleski
> <smoleski@surakware.com> writes
> >> As always, when deriving from a class look at the base class dtor, if it
> >> is not declared virtual, assume that you are not intended to derive from
> >> it and do not do so.
> >
> >I never said I wanted to derived it to use it polymorphically.
>
> Irrelevant. If it does not have a virtual dtor you should not derive
> publicly from it. And if you derive privately, why not use aggregation.

That is a very strong statement.

On page 53 of TC++PL3d, Stroustrup defines a range checked
vector template class Vec as follows:

----------------------------------------------------
  template< class T> class Vec : public vector<T> {
  public:
    Vec() : vector<T>() {}
    Vec( int s) : vector<T>(s) {}
    T& operator[](int i) { return at(i); }              // range checked
    const T& operator[](int i) const { return at(i); }  // range checked
  };
-----------------------------------------------------

Is the code above wrong?

Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:
http://table.jps.net/~vert/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Francis Glassborow wrote:

> Sebastian Moleski writes
> >> As always, when deriving from a class look at the base class dtor, if it
> >> is not declared virtual, assume that you are not intended to derive from
> >> it and do not do so.
> >
> >I never said I wanted to derived it to use it polymorphically.
>
> Irrelevant. If it does not have a virtual dtor you should not derive
> publicly from it. And if you derive privately, why not use aggregation.

Some time ago I asked the following question in `comp.lang.c++.moderated',
but no one replies, so here it is again:

How mixins, as described in, eg.:

  M. VanHils & D. Notkin:
    `Using C++ Templates to Implement Role-Based Designs'
    `Using Role Components to Implement Collaboration-Based Designs'
  Y. Smaragdakis & D. Batory:
    `Implementing Reusable Object-Oriented Components'
    `Implementing Layered Designs with Mixin Layers'
    `Mixin-Based Programming in C++'
  U. Eisenecker, F. Blinn, K. Czarnecki:
    `A Solution to the Constructor-Problem of Mixin-Based
     Programming in C++'
    (http://www.oonumerics.org/tmpw00/eisenecker.html)

fit into this (almost religious ;O) adherence to `inheritence
with virtual functions only' (at least with virtual destructor)?

fres

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Hi,

I don't know if this question is answered in the standard. At least, I
couldn't find anything about it. So here it is: are there any problems when
trying to derive a class from one of the STL's class templates, e.g.
std::list?

cp


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Hello Christian,

> I don't know if this question is answered in the standard. At least, I
> couldn't find anything about it. So here it is: are there any problems
when
> trying to derive a class from one of the STL's class templates, e.g.
> std::list?

Yes, there is a problem: The STL-Containers have no virtual destructors.

Bye
Frank


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <92qvdu$d27$07$1@news.t-online.com>, Christian Parpart
<cparpart@surakware.com> writes
>I don't know if this question is answered in the standard. At least, I
>couldn't find anything about it. So here it is: are there any problems when
>trying to derive a class from one of the STL's class templates, e.g.
>std::list?

As always, when deriving from a class look at the base class dtor, if it
is not declared virtual, assume that you are not intended to derive from
it and do not do so.


Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]