Pure Abstract Classes

Discussion in 'C++' started by Eric, Dec 6, 2006.

  1. Eric

    Eric Guest

    I was wondering what people thought about the information found at:

    http://g.oswego.edu/dl/mood/C AsIDL.html

    Specifically, I am interested in the following recommendation:

    ----
    Since interface classes cannot be directly instantiated, yet serve as
    virtual base classes for implementations, the constructors should take
    no arguments and should be listed as protected. Also, for similar
    reasons, abstract classes should have a no-op virtual destructor, not
    one listed as ... = 0.
    ----

    Not being familiar with Doug Lea, I am not certain whether his
    recommendations should be treated a genuine Perls of Wisdom or not.

    Is this really the right way to do things? Could it lead to unexpected
    bugs? If so, what should be payed attention to to avoid these bugs?

    The reason I bring this up is that I am working with a pure abstract
    class which really should be one. It seems kinda messy to have to
    declare non-abstract things in it, destroying the purity of the class,
    but doing so would get rid of an annoying compiler warning...and I
    definitely like and prefer warning free compiles as it makes it easy to
    spot warnings that point to real problems.
    Eric, Dec 6, 2006
    #1
    1. Advertising

  2. Eric wrote:
    > I was wondering what people thought about the information found at:
    >
    > http://g.oswego.edu/dl/mood/C AsIDL.html
    >
    > Specifically, I am interested in the following recommendation:
    >
    > ----
    > Since interface classes cannot be directly instantiated, yet serve as
    > virtual base classes for implementations, the constructors should take
    > no arguments and should be listed as protected. Also, for similar
    > reasons, abstract classes should have a no-op virtual destructor, not
    > one listed as ... = 0.
    > ----
    >
    > Not being familiar with Doug Lea, I am not certain whether his
    > recommendations should be treated a genuine Perls of Wisdom or not.
    >
    > Is this really the right way to do things? Could it lead to unexpected
    > bugs? If so, what should be payed attention to to avoid these bugs?
    >
    > The reason I bring this up is that I am working with a pure abstract
    > class which really should be one. It seems kinda messy to have to
    > declare non-abstract things in it, destroying the purity of the class,
    > but doing so would get rid of an annoying compiler warning...and I
    > definitely like and prefer warning free compiles as it makes it easy
    > to spot warnings that point to real problems.


    Sounds close to what I consider "good C++". No unexpected bugs AFAICS.

    "The right way to do things" depends on what your design goals are. If
    it's "C++ As IDL", sure, it's the right way. In our application there
    are almost no pure "interfaces". Even abstract classes can have data
    (state) and may need initialisation other than default.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Dec 6, 2006
    #2
    1. Advertising

  3. On 2006-12-06 21:45, Eric wrote:
    > I was wondering what people thought about the information found at:
    >
    > http://g.oswego.edu/dl/mood/C AsIDL.html
    >
    > Specifically, I am interested in the following recommendation:
    >
    > ----
    > Since interface classes cannot be directly instantiated, yet serve as
    > virtual base classes for implementations, the constructors should take
    > no arguments and should be listed as protected. Also, for similar
    > reasons, abstract classes should have a no-op virtual destructor, not
    > one listed as ... = 0.
    > ----


    The thing about the destructor is true, it's also in the FAQ [1]. It's
    not really clear from the quote whether he thinks that the constructor
    should be pure virtual or not, looking at the article it seems not.
    Personally I can't see any reason to declare a constructor except to
    prevent people from trying to instantiate the class. But since it's
    abstract that's not possible anyway.

    1. http://www.parashift.com/c -faq-lite/virtual-functions.html#faq-20.7

    --
    Erik Wikström
    =?ISO-8859-1?Q?Erik_Wikstr=F6m?=, Dec 6, 2006
    #3
  4. * Eric:
    > I was wondering what people thought about the information found at:
    >
    > http://g.oswego.edu/dl/mood/C AsIDL.html
    >
    > Specifically, I am interested in the following recommendation:
    >
    > ----
    > Since interface classes cannot be directly instantiated, yet serve as
    > virtual base classes for implementations, the constructors should take
    > no arguments and should be listed as protected. Also, for similar
    > reasons, abstract classes should have a no-op virtual destructor, not
    > one listed as ... = 0.
    > ----
    >
    > Not being familiar with Doug Lea, I am not certain whether his
    > recommendations should be treated a genuine Perls of Wisdom or not.
    >
    > Is this really the right way to do things? Could it lead to unexpected
    > bugs? If so, what should be payed attention to to avoid these bugs?
    >
    > The reason I bring this up is that I am working with a pure abstract
    > class which really should be one. It seems kinda messy to have to
    > declare non-abstract things in it, destroying the purity of the class,
    > but doing so would get rid of an annoying compiler warning...and I
    > definitely like and prefer warning free compiles as it makes it easy to
    > spot warnings that point to real problems.


    First, although the ideal in C++ is that interface classes serve as
    virtual base classes, that ideal is often compromised due to reasons
    such as efficiency or having to work with an existing framework, and
    sticking to the ideal would mean not creating that program.

    Second, there's nothing inherently wrong about a pure virtual
    destructor, and it's a not uncommon convention to "document" a class as
    abstract by having a pure virtual destructor at the top of the class'
    code. But if a destructor is declared, it should also be implemented.
    Including that a pure virtual destructor should always be implemented
    (the implementation will be called non-virtually). A good linker will
    ensure that. But unfortunately you can't count on that.

    Third, the notion that an abstract class should have a no-op destructor
    is IMO an academic purist view of abstract classes where they don't
    manage resources. IMO that's just silly, and not very practical. The
    early Smalltalk notion of an abstract class, a class with one or more
    methods as "subclass responsibility", is IMO much better suited to
    actual programming, but the subset of abstract classes that don't
    enforce class invariants directly or leave all resource allocation and
    deallocation to derived classes and only provide ways of checking the
    invariant, are very important -- e.g., they include interface classes.

    Having said that, the advice quoted above (I didn't follow the link) is
    good, but as general advice, not as an absolute guideline.

    As always, it's better to do what you think best -- because you
    understand that, and can learn from it and fix it if it turns out to be
    less than ideal -- than to blindly follow advice you don't understand.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, Dec 6, 2006
    #4
  5. Eric

    Cy Edmunds Guest

    "Eric" <> wrote in message
    news:...
    >I was wondering what people thought about the information found at:
    >
    > http://g.oswego.edu/dl/mood/C AsIDL.html
    >
    > Specifically, I am interested in the following recommendation:
    >
    > ----
    > Since interface classes cannot be directly instantiated, yet serve as
    > virtual base classes for implementations, the constructors should take
    > no arguments and should be listed as protected. Also, for similar
    > reasons, abstract classes should have a no-op virtual destructor, not
    > one listed as ... = 0.
    > ----
    >
    > Not being familiar with Doug Lea, I am not certain whether his
    > recommendations should be treated a genuine Perls of Wisdom or not.
    >
    > Is this really the right way to do things? Could it lead to unexpected
    > bugs? If so, what should be payed attention to to avoid these bugs?
    >
    > The reason I bring this up is that I am working with a pure abstract
    > class which really should be one. It seems kinda messy to have to
    > declare non-abstract things in it, destroying the purity of the class,
    > but doing so would get rid of an annoying compiler warning...and I
    > definitely like and prefer warning free compiles as it makes it easy to
    > spot warnings that point to real problems.
    >


    In spite of my great respect for some of the other responders who have a
    different view, it is my opinion that "pure abstract classes" should NEVER
    have any state to initialize and therefore should never have constructors at
    all. I will defend this position by pointing out that if you want a starting
    point which has a state, you can always derive one from the pure abstract
    class and derive the rest of your classes from there.

    Otherwise it ain't pure. Just my opinion.

    The no-op virtual destructor is a good idea. If any of the derived classes
    have non-trivial destructors it may prevent a hard-to-find resource leak.

    Cy
    Cy Edmunds, Dec 7, 2006
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. DaKoadMunky
    Replies:
    4
    Views:
    549
    Lee Weiner
    Apr 20, 2004
  2. Todd Aspeotis
    Replies:
    3
    Views:
    460
    Kanenas
    May 30, 2005
  3. Manuel
    Replies:
    8
    Views:
    638
    Manuel
    Jan 5, 2006
  4. Replies:
    4
    Views:
    811
    Rolf Magnus
    May 17, 2006
  5. Miguel Guedes

    On pure abstract classes

    Miguel Guedes, Jul 16, 2007, in forum: C++
    Replies:
    7
    Views:
    483
Loading...

Share This Page