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.