Topic: Non-Exectutable code required ?
Author: b91926@fnclub.fnal.gov (David Sachs)
Date: 22 Mar 1993 19:31:07 GMT Raw View
In article <1993Mar21.094849.19624@njitgw.njit.edu>, dic5340@hertz.njit.edu (David Charlap) writes:
|>
|> Sure it can. When you subclass b (maybe with a a "struct c: virtual b")
|> with a struct that has a non-abstract function f(), it's constructor
|> might well call b::b(). You may not instantiate any struct b objects,
|> but descendants may call it's constructor, I believe.
|>
|> >Any subclass of b is required to build the a subobject BEFORE b::b()
|> >is invoked. Since b is an abstract class, there can be no objects of class b.
|>
|> As far as I can tell, the only never-executing code here would be
|> b::f(), which isn't defined.
|>
|>
|> --
|> David Charlap dic5340@hertz.njit.edu
|>
|> UUNET!rutgers!njitgw.njit.edu!hertz!dic5340, nothing but Net.
You missed the point. In its current form, the c++ standard requires that ALL virtual bases, direct or indirect, of a class are built by calls from the constructor of the object actually built.
If you have "struct c: virtual b", the constructor for c will call the constructor for a BEFORE calling the constructor for b. I do NOT like this
reuirement, but that is the way the standard say to do it.
Author: steve@taumet.com (Steve Clamage)
Date: Tue, 23 Mar 1993 18:26:15 GMT Raw View
b91926@fnclub.fnal.gov (David Sachs) writes:
>If you have "struct c: virtual b", the constructor for c will call the constructor for a BEFORE calling the constructor for b. I do NOT like this
>reuirement, but that is the way the standard say to do it.
That explanation is a little confused. Let's take an example:
class Vbase { ... };
class Base : virtual public Vbase { ... };
class Deriv : public Base { ... };
When constructing any complete object, all virtual base classes are
constructed first. In this example, when constructing a Deriv, the
Vbase part is constructed first. Further, its constructor is invoked
by the Deriv constructor, not by the Base constructor.
--
Steve Clamage, TauMetric Corp, steve@taumet.com
Author: b91926@fnclub.fnal.gov (David Sachs)
Date: 18 Mar 1993 15:27:08 GMT Raw View
I would like opinions on the propriety of the compilaton time error produced by the following code frgament:
// Example inspired by Marku Sakkinen's article (c++ report Mar/Apr 93 p 44)
struct a
{
int a1;
a(int x) {a1 = x}
};
struct b: virtual a
{
virtual void f()=0; // this makes b an abstract class
b();
}
b::b() {} // error - no default construct for a
// ******* end of fragment ********
Of course the code can be corrected by adding a ctor for a in b::b(), BUT the
constructor for struct b can NEVER be called on (using the c++ standard in its
current state) to build the a subobject.
Any subclass of b is required to build the a subobject BEFORE b::b() is invoked. Since b is an abstract class, there can be no objects of class b.
Why should the c++ language require code that can NEVER POSISSIBLY be executed?
Author: dic5340@hertz.njit.edu (David Charlap)
Date: 21 Mar 93 09:48:49 GMT Raw View
In article <1oa4cc$bpk@fnnews.fnal.gov> b91926@fnclub.fnal.gov (David Sachs) writes:
>// Example inspired by Marku Sakkinen's article (c++ report Mar/Apr 93 p 44)
>
>struct a
>{
> int a1;
> a(int x) {a1 = x}
>};
>
>struct b: virtual a
>{
> virtual void f()=0; // this makes b an abstract class
> b();
>}
>
>b::b() {} // error - no default construct for a
Try this:
b::b() : a(1) {}
>// ******* end of fragment ********
>
>Of course the code can be corrected by adding a ctor for a in b::b(), BUT the
>constructor for struct b can NEVER be called on (using the c++ standard in its
>current state) to build the a subobject.
Sure it can. When you subclass b (maybe with a "struct c: virtual b")
with a struct that has a non-abstract function f(), it's constructor
might well call b::b(). You may not instantiate any struct b objects,
but descendants may call it's constructor, I believe.
>Any subclass of b is required to build the a subobject BEFORE b::b()
>is invoked. Since b is an abstract class, there can be no objects of class b.
>
>Why should the c++ language require code that can NEVER POSISSIBLY be executed?
As far as I can tell, the only never-executing code here would be
b::f(), which isn't defined.
--
David Charlap dic5340@hertz.njit.edu
UUNET!rutgers!njitgw.njit.edu!hertz!dic5340, nothing but Net.