• Jarrett Billingsley (25/25) Aug 09 2005 If you compile this snippet under 0.129:
• Uwe Salomon (6/10) Aug 09 2005 Try
• Jarrett Billingsley (5/11) Aug 09 2005 That just makes B an abstract class. Then you can't instantiate B. The...
• Uwe Salomon (20/31) Aug 09 2005 That is the correct behaviour, i think?! If you write
• Jarrett Billingsley (6/17) Aug 09 2005 Then the compiler should throw an error if derived classes _don't_ provi...
• BCS (17/38) Aug 09 2005 They are treated equally, the following compiles with link errors. Furth...
• Stewart Gordon (10/17) Aug 09 2005 Uwe Salomon wrote:

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

If you compile this snippet under 0.129:

abstract class A
{
 void fork();
}

interface C
{
 void knife();
}

class B : A, C
{

}

It gives the error "dtest.d(15): class dtest.B interface function C.knife 
isn't implemented."  That's good, but it doesn't say anything about the 
unimplemented fork() B inherits from A.

If you remove C altogether, leaving you with:

abstract class A
{
 void fork();
}

class B : A
{

}

It compiles just fine, but gives a linker error, saying there's an undefined 
symbol called A.fork. 

"Uwe Salomon" <post uwesalomon.de> writes:

 abstract class A
 {
  void fork();
 }

Try


abstract void fork();


Ciao
uwe

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"Uwe Salomon" <post uwesalomon.de> wrote in message 
news:op.su8vszg26yjbe6 sandmann.maerchenwald.net...
 Try


 abstract void fork();


 Ciao
 uwe

That just makes B an abstract class.  Then you can't instantiate B.  The 
compiler gives no information as to why B can't be instantiated, just that 
it's abstract. 

"Uwe Salomon" <post uwesalomon.de> writes:

 Try


 abstract void fork();


 Ciao
 uwe

 That just makes B an abstract class.  Then you can't instantiate B.  The
 compiler gives no information as to why B can't be instantiated, just  
 that it's abstract.

That is the correct behaviour, i think?! If you write


void someFunc(int someParam);


this means that there is a function called someFunc with the parameter and  
stuff, it is just not defined here. If you write


abstract void someFunc(int someParam);


this means that there is *no* function called someFunc, but derived  
classes will provide it. That's why the first variant produces a linker  
error, and the second one doesn't. In digitalmars.D you have just asked  
for the first variant: declaring a class and its functions, without  
supplying the implementation. It will be supplied by object/library files  
you link into the executable. The function for the second variant will  
never be supplied, but instead the one from a derived class will be called.

Of course it would be nice if the compiler said why the class is abstract  
to help find the error.

Ciao
uwe

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"Uwe Salomon" <post uwesalomon.de> wrote in message 
news:op.su8yki136yjbe6 sandmann.maerchenwald.net...
 That is the correct behaviour, i think?! If you write


 void someFunc(int someParam);


 this means that there is a function called someFunc with the parameter and 
 stuff, it is just not defined here. If you write


 abstract void someFunc(int someParam);


 this means that there is *no* function called someFunc, but derived 
 classes will provide it.

Then the compiler should throw an error if derived classes _don't_ provide 
the implementation, just like it does for interfaces.

IMO, an abstract function in a base class serves the same purpose as a 
function in an interface, and should be treated equally. 

BCS <BCS_member pathlink.com> writes:

In article <ddair9$2osv$1 digitaldaemon.com>, Jarrett Billingsley says...
"Uwe Salomon" <post uwesalomon.de> wrote in message 
news:op.su8yki136yjbe6 sandmann.maerchenwald.net...
 That is the correct behaviour, i think?! If you write


 void someFunc(int someParam);


 this means that there is a function called someFunc with the parameter and 
 stuff, it is just not defined here. If you write


 abstract void someFunc(int someParam);


 this means that there is *no* function called someFunc, but derived 
 classes will provide it.

Then the compiler should throw an error if derived classes _don't_ provide 
the implementation, just like it does for interfaces.

IMO, an abstract function in a base class serves the same purpose as a 
function in an interface, and should be treated equally. 



They are treated equally, the following compiles with link errors. Furthermore
the reason for the errors are different. With the interface case, a function
must be supplied by the derived class. With the non-abstract case, the code says
a function is supplied _for_the_base_class_ from somewhere else.

class A
{
void foo();
}

interface I
{
void bar();
}

class B: A, I
{
void bar();  //defined, but not here.
}

Stewart Gordon <smjg_1998 yahoo.com> writes:

Uwe Salomon wrote:

<snip>
[Jarrett]
 That just makes B an abstract class.  Then you can't instantiate B.  The
 compiler gives no information as to why B can't be instantiated, just  
 that it's abstract.

 
 That is the correct behaviour, i think?! If you write

It's neither correct nor incorrect, as you indicate below:

<snip>
 Of course it would be nice if the compiler said why the class is 
 abstract to help find the error.

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/1940

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
on the 'group where everyone may benefit.