Extending stl::list???

[Barry Hynes]

G'Day folks,

Have been working on this problem for quite some time and still no farther
ahead.

Here is my problem...bare with me i am very green

I have to implement a Safe List, that is derived from the STL class List and
uses exception handling.

From the various FAQ's and newsgroups it says that deriving from STL
containers is not wise due to the lack of virtual destructors.

Q1.) What is the purpose of this exercise if it is deemed to be poor
programming practice?

What i invision is a large object (SafeList) that contains my iterators,
stl::list and the various methods to work on the list The user
constructs/destroys this object
in a safe and efficient manner.

Q2.)Could you create a wrapper class for STL::List<> and wrap all you
iterators and any mutating methods that could produce memory error?...

// safeList.h

#ifndef SAFELIST_H
#define SAFELIST_H

#include <list>
#include <iterator>
#include <memory>
#include <stdexcept>
using namespace std;

typedef list<T> S;
typedef list<T>::iterator SI;

template<typename T>
class SafeList : private S {
public:
explicit SafeList(const S*);//No no-arg ctor
virtual ~SafeList();
S* operator->() throw(std::runtime_error);
S* operator*() throw(std::runtime_error);
//methods ..... //
class SafeIterator {
public:
SafeIterator(const SI*);
virtual ~SafeIterator();
SI* operator->() throw (std::runtime_error);
SI* operator*() throw (std::runtime_error);
private:
SI* _mySafeIterator;
SafeIterator(const SafeIterator&);
SafeIterator& operator=(const SafeIterator&);
void operator new(size_t) throw (std::bad_alloc);
void operator delete(void*) throw();
;
private:
S* _mySafeList;
SafeList(const SafeList&);
SafeList& operator = (const SafeList&);
;

any help greatly appreciated

Barry

 

[David Hilsee]

G'Day folks,

Have been working on this problem for quite some time and still no farther
ahead.

Here is my problem...bare with me i am very green

I have to implement a Safe List, that is derived from the STL class List and
uses exception handling.

From the various FAQ's and newsgroups it says that deriving from STL
containers is not wise due to the lack of virtual destructors.

Q1.) What is the purpose of this exercise if it is deemed to be poor
programming practice?

I'm guessing that this is an assignment? If you're going to be graded on
this, then I suggest doing what the instructor told you to do, even if it is
considered bad practice. Often times, instructors don't care so much about
the "proper" way of doing things for their assignments. However, you are
right, public inheritance from standard containers is usually not preferred
because a) they don't have virtual destructors and b) the container is
publicly accessible, exposing implementation details. For example, one
could easily bypass your "safe" member functions by simply accessing the
std::list directly, giving them direct access to "unsafe" functionality that
could cause undefined behavior and preventing you from easily changing the
way you store elements inside SafeList. This isn't much of a problem with
private inheritance.

What i invision is a large object (SafeList) that contains my iterators,
stl::list and the various methods to work on the list The user
constructs/destroys this object
in a safe and efficient manner.

Q2.)Could you create a wrapper class for STL::List<> and wrap all you
iterators and any mutating methods that could produce memory error?...

Assuming you mean std::list, I don't see why not.

// safeList.h

#ifndef SAFELIST_H
#define SAFELIST_H

#include <list>
#include <iterator>
#include <memory>
#include <stdexcept>
using namespace std;

typedef list<T> S;
typedef list<T>::iterator SI;

template<typename T>
class SafeList : private S {
public:
explicit SafeList(const S*);//No no-arg ctor
virtual ~SafeList();
S* operator->() throw(std::runtime_error);
S* operator*() throw(std::runtime_error);
//methods ..... //
class SafeIterator {
public:
SafeIterator(const SI*);
virtual ~SafeIterator();
SI* operator->() throw (std::runtime_error);
SI* operator*() throw (std::runtime_error);
private:
SI* _mySafeIterator;
SafeIterator(const SafeIterator&);
SafeIterator& operator=(const SafeIterator&);
void operator new(size_t) throw (std::bad_alloc);
void operator delete(void*) throw();
;
private:
S* _mySafeList;
SafeList(const SafeList&);
SafeList& operator = (const SafeList&);
;

any help greatly appreciated

The class template doesn't compile and has a few issues (for example, why
would you have a member list and inherit from it as well?), but I'm sure you
were just sketching out an idea in pseudo-C++. It's certainly feasible.
However, as I said before, if this is an assignment, follow the instructions
from the assignment.

 

[barman]

I'm guessing that this is an assignment?

yes

If you're going to be graded on

this, then I suggest doing what the instructor told you to do, even if it
is
considered bad practice.

this is thru correspondence

Often times, instructors don't care so much about

the "proper" way of doing things for their assignments. However, you are
right, public inheritance from standard containers is usually not
preferred
because a) they don't have virtual destructors and b) the container is
publicly accessible, exposing implementation details. For example, one
could easily bypass your "safe" member functions by simply accessing the
std::list directly, giving them direct access to "unsafe" functionality
that
could cause undefined behavior and preventing you from easily changing the
way you store elements inside SafeList. This isn't much of a problem with
private inheritance.


Assuming you mean std::list, I don't see why not.



The class template doesn't compile and has a few issues (for example, why
would you have a member list and inherit from it as well?),

i have no idea...not sure what i am trying to do

but I'm sure you

were just sketching out an idea in pseudo-C++.

yes

It's certainly feasible.

However, as I said before, if this is an assignment, follow the
instructions
from the assignment.

here is the original question

pg 427
Implement a Safe List, that is derived from the STL class List and
uses exception handling.


thanks for the help

Barry