nelson@m.cs.uiuc.edu (01/23/90)
Two questions about "newer" C++:
1. When using abstract classes, ie with true virtual functions like
ding dong::dell (foo bar) = 0;
is a constructor permitted? "The Evolution of C++" says nothing
about this, but G++ seems to disallow it on the grounds that you
are creating an object of that class when the subclasses call
the constructor. That is, in a sense, true, but it removes an
extrememly handy thing. As a hack, I suppose there could be an
initialization routine, but... Does anyone know anything
further about this???
2. In the 1987 paper "Possible Directions for C++", Stroustrup
mentions an exception handling scheme. Has anyone or any
compilers implemented any sort of error-handling scheme. We
are about to begin a large C++ project, and nice/varied error
handling is something that has to be figured out at the start.
Suggestions?
Danke!kvt@drutx.ATT.COM (TranKV) (01/23/90)
In article <4800082@m.cs.uiuc.edu> nelson@m.cs.uiuc.edu writes: >1. When using abstract classes, ie with true virtual functions like > ding dong::dell (foo bar) = 0; > is a constructor permitted? Is destructor permitted? My 2.0 Cfront won't accept it.
kvt@drutx.ATT.COM (TranKV) (01/23/90)
In article <4800082@m.cs.uiuc.edu> nelson@m.cs.uiuc.edu writes: >1. When using abstract classes, ie with true virtual functions like > ding dong::dell (foo bar) = 0; > is a constructor permitted? Is destructor permitted? My 2.0 Cfront won't accept it. Well, actually Cfront allowed my code to pass but ld complained about missing definition for the constructor.
jenings@hpfcbig.SDE.HP.COM (Byron T. Jenings Jr.) (02/08/90)
Andrew Koenig <ark@alice.UUCP> writes: |Therefore, it doesn't make sense to have a pure virtual |destructor, as it would preclude destroying objects not |only of that class but of any class derived from it. Only if you take a compiler implementer's view instead of a user's view. I hit this as well, because I was trying to specify: This is an abstract base class that cannot exist, and so has nothing but pure virtual functions. Since it cannot exist, it has no destructor, so there's obviously no base class destructor for derived classes to call. Since all of the above is specified in the class declaration, the compiler could easily treat a pure virtual destructor the same as a nonexistent destructor, with the exception of putting a placeholder entry in the virtual function table for it. What cfront2.0 really did, however, was to compile my virtual destructor OK, but generated calls to the "nonexistent" base class in each derived class's destructor. This seems inconsistent, since the function both exists and doesn't exist at the same time. I can see why cfront does what it does, however, since this way the compiler doesn't have to bother to look up whether the base class's destructor was pure. Probably keeps the code simpler. Or, maybe there's some conceptual truth that I'm overlooking...