Protected Abstract Class Contructors

[talkingpidgin]

I am trying to figure out why it is not conventional to use protected
constructors in abstract classes since the only time they should be
called is by the constructors of it's derived classes. Is it simply
because it's not strictly necessary since an abstract class can't be
instantiated anyways? It just seems like it would be clearer to make
the ctor protected so I figured there must be some reason for it.

Also I am trying to put together a list of when protected ctors in
abstract classes would actually be practical/necessary. I know there
has been a couple previous threads on this but they are not very clear.
I will start by listing what I have interpreted from them.

-Singleton interfaces. There is a lot of talk of singleton classes. I
think this is because an abstract protected ctor would allow you to
create any of an abstract base class' derived classes, but only one of
those derived classes. i.e. If all derived classes are a "type" of the
base class, then doing this would only let you create one object of a
certain type. Please tell me if I am on track with this since I have
read about singleton classes but I don't have experience implementing
them.

I will list more tomorrow when I have time to go over the previous
posts again.

[Cy Edmunds]

<ta***********@gmail.comwrote in message
news:11**********************@h54g2000cwb.googlegr oups.com...

>I am trying to figure out why it is not conventional to use protected
constructors in abstract classes since the only time they should be
called is by the constructors of it's derived classes. Is it simply
because it's not strictly necessary since an abstract class can't be
instantiated anyways? It just seems like it would be clearer to make
the ctor protected so I figured there must be some reason for it.

Also I am trying to put together a list of when protected ctors in
abstract classes would actually be practical/necessary. I know there
has been a couple previous threads on this but they are not very clear.
I will start by listing what I have interpreted from them.

-Singleton interfaces. There is a lot of talk of singleton classes. I
think this is because an abstract protected ctor would allow you to
create any of an abstract base class' derived classes, but only one of
those derived classes. i.e. If all derived classes are a "type" of the
base class, then doing this would only let you create one object of a
certain type. Please tell me if I am on track with this since I have
read about singleton classes but I don't have experience implementing
them.

I will list more tomorrow when I have time to go over the previous
posts again.

Abstract base classes probably shouldn't have constructors at all. Whatever
you do in the constructor is effectively implementation and an abstract base
class should be pure interface. A class derived from an abstract base class
which doesn't fully implement the interface doesn't really need a protected
constructor since no objects of that type can be declared anyway.

// abstract base class
class IThing
{
public:
virtual int afunc() const = 0;
virtual double bfunc() const = 0;
virtual ~IThing() {}
};

// partial implementation
class BThing : public IThing
{
private:
int a;
public:
BThing(int ia) : a(ia) {} // could be protected, but why?
virtual int afunc() const {return a;}
};

Cy

[Jeff Dege]

On Tue, 28 Nov 2006 01:21:42 +0000, Cy Edmunds wrote:

>
Abstract base classes probably shouldn't have constructors at all. Whatever
you do in the constructor is effectively implementation and an abstract base
class should be pure interface. A class derived from an abstract base class
which doesn't fully implement the interface doesn't really need a protected
constructor since no objects of that type can be declared anyway.

Abstract-as-interface is a design pattern, and I don't think that
abstracts can never be reasonably used outside that pattern.

On occasion, I've not only provided implementions for methods in abstract
classes, I've provided implementations for pure virtual methods in
abstract classes. Not often, but a couple of times it seemed the best
place to put the code.

The derived classes _had_ to provide their own implementations of the
method, the design required it. But nearly all of what needed to be done
in those derived implementations was identical, and could be put in the
base class.
#include <iostream>
using namespace std;

class Foo {
public:
virtual void foo() = 0;
};

void Foo::foo() {
cout << "Foo::foo()" << endl;
}

class Bar : public Foo {
public:
virtual void foo() {
Foo::foo();
cout << "Bar::foo()" << endl;
}
};

int main(int, char**) {
Bar b;
b.foo();
return 0;
}

--
The other day I was talking with a Democrat friend about the election.
She'd remarked, with equal amounts of sarcasm and good-natured ribbing,
that the GOP had two years to build utopia. I thought about that later
while walking Jasper around the block, and thought, no; they're not about
building utopia. Personally, I'm interested in keeping other people from
building Utopia, because the more you believe you can create heaven on
earth the more likely you are to set up guillotines in the public square
to hasten the process.
- James Lileks