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.

> abstract class A
> {
>  void fork();
> }

Try

###
abstract void fork();
###

Ciao
uwe

"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.

>> 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

"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.

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.
}

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.