in C++, there is a concept called an "abstract class", which is achieved by having a class with at least one pure virtual function (function declaration =0).  you are not allowed to create any instances of an abstract class.

i thought the keyword "abstract" would cause this behavior on a class without the "implied" kind that you get with C++.  apparently not!

defining a class as "abstract" does not seem to do anything.  D allows you to create instances of it.  deriving from the abstract class does not change any behavior.

looking through the manual, i cannot find any explanation as to what the abstract keyword does.

all i'm doing is this:

abstract class Parent
{
    int foo() { return 10; }
}

class Child : Parent
{
    int foo() { return 20; }
}

i'm still allowed to create instances of Parent and call its foo().

am i doing something wrong here?  am i not supposed to have any kind of function declaration in the Parent class for it to be treated as abstract? or does abstract do something completely different?  or is it even implemented ;)

It only works on methods, not entire classes.  For that i suggest an interface, though it does seem to be either a flaw, or not documented well.

C

In article <ccuj6r$2k5p$1@digitaldaemon.com>, Jarrett Billingsley says...
>
>in C++, there is a concept called an "abstract class", which is achieved by having a class with at least one pure virtual function (function declaration =0).  you are not allowed to create any instances of an abstract class.
>
>i thought the keyword "abstract" would cause this behavior on a class without the "implied" kind that you get with C++.  apparently not!
>
>defining a class as "abstract" does not seem to do anything.  D allows you to create instances of it.  deriving from the abstract class does not change any behavior.
>
>looking through the manual, i cannot find any explanation as to what the abstract keyword does.
>
>all i'm doing is this:
>
>abstract class Parent
>{
>    int foo() { return 10; }
>}
>
>class Child : Parent
>{
>    int foo() { return 20; }
>}
>
>i'm still allowed to create instances of Parent and call its foo().
>
>am i doing something wrong here?  am i not supposed to have any kind of function declaration in the Parent class for it to be treated as abstract? or does abstract do something completely different?  or is it even implemented ;)
>
>

On Mon, 12 Jul 2004 13:54:31 -0400, Jarrett Billingsley <kb3ctd2@yahoo.com> wrote:

> in C++, there is a concept called an "abstract class", which is achieved by
> having a class with at least one pure virtual function (function declaration
> =0).  you are not allowed to create any instances of an abstract class.
>
> i thought the keyword "abstract" would cause this behavior on a class
> without the "implied" kind that you get with C++.  apparently not!
>
> defining a class as "abstract" does not seem to do anything.  D allows you
> to create instances of it.  deriving from the abstract class does not change
> any behavior.
>
> looking through the manual, i cannot find any explanation as to what the
> abstract keyword does.
>
> all i'm doing is this:
>
> abstract class Parent
> {
>     int foo() { return 10; }
> }
>
> class Child : Parent
> {
>     int foo() { return 20; }
> }
>
> i'm still allowed to create instances of Parent and call its foo().
>
> am i doing something wrong here?  am i not supposed to have any kind of
> function declaration in the Parent class for it to be treated as abstract?
> or does abstract do something completely different?  or is it even
> implemented ;)

It is implemented, it just behaves differently to what you're expecting. From what I can see..

class Parent
{
	int foo();
}

class Child : Parent
{
	int foo() { return 20; }
}

The above will not compile, *unless* I put 'abstract' in front of the class, or the method 'foo' eg

abstract class Parent
{
	int foo();
}

or

class Parent
{
	abstract int foo();
}

so abstract *allows* a class to have undefined method bodies. It does not *prohibit* instantiation of a class as long as it has all it's method bodies.

I *do* like the fact that you do not need to place abstract on all the methods of a class, one abstract on the class definition will affect all methods in the class.

I *do not* like the fact that you cannot provide bodies and still *prohibit* instantiation of the abstract class.

These are my gut reactions, maybe it's time for a rethink, perhaps D has it right, if a class has all it's method bodies, why prohibit it's instantiation? In which case placing abstract in front of the class or method (with a body) should give an error.

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Mon, 12 Jul 2004 18:50:08 +0000 (UTC), Charlie <Charlie_member@pathlink.com> wrote:

> It only works on methods, not entire classes.

Not true. See my example.

> For that i suggest an interface,

An interface does not help when you're trying to say, all derived classes *must* redefine this method *and* you want to provide a method body (so as derived classes can call super.method())

> though it does seem to be either a flaw, or not documented well.

Agreed.

Regan

> C
>
> In article <ccuj6r$2k5p$1@digitaldaemon.com>, Jarrett Billingsley says...
>>
>> in C++, there is a concept called an "abstract class", which is achieved by
>> having a class with at least one pure virtual function (function declaration
>> =0).  you are not allowed to create any instances of an abstract class.
>>
>> i thought the keyword "abstract" would cause this behavior on a class
>> without the "implied" kind that you get with C++.  apparently not!
>>
>> defining a class as "abstract" does not seem to do anything.  D allows you
>> to create instances of it.  deriving from the abstract class does not change
>> any behavior.
>>
>> looking through the manual, i cannot find any explanation as to what the
>> abstract keyword does.
>>
>> all i'm doing is this:
>>
>> abstract class Parent
>> {
>>    int foo() { return 10; }
>> }
>>
>> class Child : Parent
>> {
>>    int foo() { return 20; }
>> }
>>
>> i'm still allowed to create instances of Parent and call its foo().
>>
>> am i doing something wrong here?  am i not supposed to have any kind of
>> function declaration in the Parent class for it to be treated as abstract?
>> or does abstract do something completely different?  or is it even
>> implemented ;)
>>
>>
>
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

thanks for the clarification :)  didn't know if i was just thick or what!

unfortunately an interface isn't really useable here.  so oh well.

Charlie wrote:

> It only works on methods, not entire classes.

It's been said before.  If one declares a class to be abstract, it follows that one wants it to be abstract.  Why is the keyword 'abstract' allowed here if it does nothing?

> For that i suggest an interface,
> though it does seem to be either a flaw, or not documented well.
<snip top of upside-down reply>

I'd call it a bug one way or the other.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.