kanze@gabi-soft.fr (J. Kanze) writes:

>In article <4lod8b$18b@netlab.cs.rpi.edu> clamage@Eng.Sun.COM (Steve
>Clamage) writes:

>    (Since I'm about to do some standardese nit-picking, I've put the
> follow-ups to comp.std.c++.)

>|> But what about a constructor (or destructor) of Abstract?
>|>  Abstract::Abstract() { foo(this); }
>|> The type of the partially-constructed object is "Abstract" during
>|> the constructor, so no derived-class override can be called from this
>|> invocation of foo(). But Abstract::f() won't be called either -- that's
>|> what I meant by "NEVER".

>Is this guaranteed by the standard, or is it just a case of undefined
>behavior, which in fact, any reasonable implementation *will* handle the
>way you go on to describe.

The behavior is undefined, but the intent is that the function
declared pure virtual will not be called unless explicitly qualified.
--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <3176D10D.2B4C@netcom.com>, Casey Muratori <cmu@netcom.com> wrote:

> Chris Page wrote:
> >
> > In article <4l1bmi$1li@netlab.cs.rpi.edu>, sachs@fnal.fnal.gov wrote:
> >
> > > Personally, I consider virtual destructors to be one of the blemishes
> > > of the C++ language. There should be a better way to make a class
> > > (with no other pure virtual functions) abstract.
> >
> > How about an "abstract" keyword that you can place before "class"?
>
> Hmmm.  If the class has no pure-virtual functions, why would you want
> to make it "abstract"?  If all you want to do is prevent someone from
> instantiating an object of its type, simply make the constructor private,
> no?

My message was forwarded from comp.lang.c++, where another respondant
noted that a friend or member function could still call the protected
contstructor (I'm not prepared to discuss this, I'm just passing along the
info).

Of course, it's my opinion that "abstractness" is, essentially, an
external documentation issue, not a language issue. It's nice to have a
C++ compiler that will statically identify "illegal" instantiations, but
nothing prevents you from simply documenting a class as abstract.

Anyhow, this thread was forwarded here because of my suggestion for an
"abstract" keyword. I haven't thought it through, but I think it might
satisfy those people who complain that they have to declare a pure virtual
function member in order to create an abstract class.

--
Chris Page        | Internet chain letters, advertisements and SPAMs suck...
Don't Panic!      |
page@best.com     |                   Cut it out! :-P
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Chris Page wrote:
>
> In article <4l1bmi$1li@netlab.cs.rpi.edu>, sachs@fnal.fnal.gov wrote:
>
> > Personally, I consider virtual destructors to be one of the blemishes
> > of the C++ language. There should be a better way to make a class
> > (with no other pure virtual functions) abstract.
>
> How about an "abstract" keyword that you can place before "class"?

Hmmm.  If the class has no pure-virtual functions, why would you want
to make it "abstract"?  If all you want to do is prevent someone from
instantiating an object of its type, simply make the constructor private,
no?

- Casey

--
"Fear can hold you prisoner.  Hope can set you free."




[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]