Hi,

Looking at stl_slist.h I found that the destructor of the slist
template class was not virtual.

Doesn't that prevents user from deriving a class from it
with some dynamically allocated data member ?

--
Marc Ferry
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

No, this does not prevent you from deriving from slist but this is an
indication from the authors of slist saying it is not welcome to derive from
this class. In other words, slist has not been designed to be derived. The
absence of virtual destructor is an indication of this. Its consequence are
resource leaks if you attempt to delete your derived class from a slist
pointer

Hope this helps,


Marc Ferry wrote:

> Hi,
>
> Looking at stl_slist.h I found that the destructor of the slist
> template class was not virtual.
>
> Doesn't that prevents user from deriving a class from it
> with some dynamically allocated data member ?

[ moderator's note: excessive quoting deleted. -sdc ]

--
Sebastien Marc
Project Leader
Sailfish systems
44 Wall Street
New York, NY
(212) 607 3013



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Marc Ferry <marc@netmansys.fr> wrote:

>Hi,
>
>Looking at stl_slist.h I found that the destructor of the slist
>template class was not virtual.
>
>Doesn't that prevents user from deriving a class from it
>with some dynamically allocated data member ?

It depends. I will not discuss the philosophical merits of this, but
I'm certain this will behave correctly, given the right headers and so
on:

class SurferList : private slist<Surfer>
{
public:
  SurferList() : gremmy(new Surfer) {}
  ~SurferList() { delete gremmy; }
  void Append(const Surfer& kahuna)
  {
    append(kahuna);
  }
};

int main()
{
  SurferList *surferList = new SurferList;
  //slist<Surfer>* bptr = surferList; // won't compile
  delete surferList;
}

This is a plausible way to derive from a template container. The
clients of SurferList have access to a destructor that does what it
should. They don't have the ability to treat SurferList as an slist,
so they can't delete an slist that would have needed a virtual
destructor.


--
Mike Enright
enrightm@acm.org (Email replies cheerfully ignored, use the news group)
http://www.users.cts.com/sd/m/menright/
Cardiff-by-the-Sea, California, USA



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi,

if this article is not appropriate for fr.comp.lang.c++ (after all it is not
in French and I'm not capable of writing it in both English and French),
please excuse the intrusion: The original article was crossposted to this
newsgroup...

In article <36C46E78.7085E358@netmansys.fr>,
  Marc Ferry <marc@netmansys.fr> wrote:
> Looking at stl_slist.h I found that the destructor of the slist
> template class was not virtual.

'slist'? There is no 'slist' in the standard... The implementer of this class
is thus free to implement it however she/he sees fit. To stick to conventions
of the container classes defined in the standard, the class would contain no
virtual function at all: The standard container classes are not intended to
be used as base class (and I still have to see a convincing reason to derive
from any of them). Correspondingly, there is no need to make the destructor
virtual.

> Doesn't that prevents user from deriving a class from it
> with some dynamically allocated data member ?

No. The rule you have in mind says the following: If you delete an object
through a pointer pointing to some class 'T' and if 'T' has no virtual
destructor, the dynamic type of the object has to be 'T'. That is, the
pointer really has to point to a 'T' object and not to an object of a derived
class. If this rule is violated, undefined behavior is the result. Not
calling the destructor of the derived class is one possible result.
Formatting the hard disk or starting World War III are other potential
outcomes... Fortunetly, these are less likely!

Thus, you can derive from a class without a virtual destructor as long as you
make sure that objets of this type are never deleted through a pointer to the
corresponding base class. In a well designed library I would take the missing
virtual destructor as a strong indication that the class is not intended to be
used as base class.
--
<mailto:dietmar.kuehl@claas-solutions.de>
homepage: <http://www.informatik.uni-konstanz.de/~kuehl>

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]