D
Daniel
What is an abstract base class called that has all pure virtual functions
and no implementation? Is there such a thing as a pure abstract base class?
and no implementation? Is there such a thing as a pure abstract base class?
D
Doug Harrison [MVP]
The only term I've heard that would seem to apply is "interface".
Never heard of it.
W
WoadRider
It's still called an Abstract class. Better called an Interface.
G
Grezkue
J
Jochen Kalmbach [MVP]
Hi Daniel!
It does not matter if if all methods are marked as abstarct...
If at least *one* Method is abstract 8either marked with "= 0" or with
the new keyword "abstract", the the whole class is an "abstract class".
An interface is *not* an abstract class! It is an interface.
--
Greetings
Jochen
My blog about Win32 and .NET
http://blog.kalmbachnet.de/
It does not matter if if all methods are marked as abstarct...
If at least *one* Method is abstract 8either marked with "= 0" or with
the new keyword "abstract", the the whole class is an "abstract class".
An interface is *not* an abstract class! It is an interface.
--
Greetings
Jochen
My blog about Win32 and .NET
http://blog.kalmbachnet.de/
B
Ben Voigt [C++ MVP]
An interface is *not* an abstract class! It is an interface.
Yes it is. In C++ interfaces are abstract classes.
Even in C++/CLI, which like .NET makes a distinction between interfaces and
reference types (called classes in C#), the keyword to create an interface
is "interface class".
Yes it is. In C++ interfaces are abstract classes.
Even in C++/CLI, which like .NET makes a distinction between interfaces and
reference types (called classes in C#), the keyword to create an interface
is "interface class".
J
Jochen Kalmbach [MVP]
Hi Ben!
No. An interface is an interface!
In C++/CLI you cannot derived from more tha one "class"... so an
interface *must* not be a class (or abstract) class. It is an interface.
This is not comparable with "normal" C++.
You can only derive from one class (abstract or not). And you can
"implement" many interfaces.
Isn't that waht I am saying?
But I think we both mean the same
--
Greetings
Jochen
My blog about Win32 and .NET
http://blog.kalmbachnet.de/
No. An interface is an interface!
In C++/CLI you cannot derived from more tha one "class"... so an
interface *must* not be a class (or abstract) class. It is an interface.
This is not comparable with "normal" C++.
You can only derive from one class (abstract or not). And you can
"implement" many interfaces.
Isn't that waht I am saying?
But I think we both mean the same
--
Greetings
Jochen
My blog about Win32 and .NET
http://blog.kalmbachnet.de/
B
Ben Voigt [C++ MVP]
Jochen Kalmbach said:
This statement is horribly imprecise.
In C++/CLI, each unmanaged class/struct can derive from zero or more
unmanaged classes and structs, any number of these.
A ref class/struct derives from exactly one ref class/struct (which may
implicitly be System::Object) and exactly zero value classes, and implements
zero or more interface classes.
A value class/struct derives from exactly zero ref classes/structs and
exactly zero value classes/structs, (although reflection reports that it
derives from System::ValueType), and implements zero or more interface
classes/struct.
An interface class/struct derives from zero or more interface
classes/structs.
There is neither inheritance nor direct containment possible across the
managed/unmanaged boundary.
And all of the above are classified as "class types".
It doesn't sound like it.
An interface is an abstract class. It is not a ref class, true, but it is a
class type. And it is abstract.
In C++/CLI, the word "class" is not synonymous with "reference type".
C++/CLI is not C#.
A
Armin Zingler
Ben said:
If I may...
What's so special about this group is the CLI part. In this context a class
is always meant to be a ref class. Therefore, I agree with Jochen that an
interface is not an abstract class. As he said: "This is not comparable with
'normal' C++.".
Armin
B
Ben Voigt [C++ MVP]
Armin Zingler said:
Yes, in this group we talk about the C++/CLI compiler, writing managed code
using C++ syntax, and making managed and unmanaged C++ code talk to each
other.
Except when it is an interface class, value class, or unmanaged class...
these are all "class types" in C++/CLI.
gcroot<T> is certainly an important part of C++/CLI but it is not a ref
class
I will reiterate my point: In C++/CLI, the word "class" is not synonymous
with "reference type".
A
Armin Zingler
Ben said:
The word "always" means always, that is, without an exception. A value type
is called a value type, an interface an interface and a (ref) class
is called a class. There's no need to distinguish between
different "types of classes" because the word class itself is unambiguous.
MSFT's CLI specification
(http://msdn.microsoft.com/de-de/netframework/aa569283(en-us).aspx) does not
even mention the word "interface class". It also says: "For historical
reasons 'value class' can be used instead of 'value type' although the
latter is preferred." (source: MS Partition I, 13.1, page 58)
Sure, if you want to make it more complicated than necessary, you can
declare the word "class" being ambiguous instead of just calling an
interface an interface and a value type value type. For my part, I do know
what a class is without asking which kind of class.
IMO, it is.
Armin
B
Ben Voigt [C++ MVP]
What's so special about this group is the CLI part. In this context a
Not "types of classes". "class types", a term used frequently in the C++
and C++/CLI specifications.
In C++/CLI, the keyword "class" IS ambiguous. You need to know whether it
is prefixed by "value", "ref", "interface" or nothing to know its meaning.
This is the C++/CLI group, not the C# group. The documentation you
mentioned is all C#-centric. The "CLI" specification you mentioned is not
the specification for C++/CLI. That would be here:
specification for C++/CLI:
http://www.ecma-international.org/publications/standards/Ecma-372.htm
"interface class" is part of the C++/CLI syntax, how you can deny the
existence of the term is beyond me.
You might also try reading section 12.2, which is just one of many that
identifies "class types" in C++/CLI as "Ref class types, value class types,
interface types, and delegate types".
Again you claim that "class" is unambiguous in C++/CLI. Actually, the
meaning is context-sensitive.
You're entitled to your opinion, but please don't state it as fact in the
newsgroup where there are people trying to learn C++/CLI. They need to hear
accurate information about the C++/CLI type system, not your improper
attempt to impose C# terminology on C++ (BTW C++ used the terminology first,
so if you don't accept that terms can mean different things for different
languages, it's C# that's wrong).
Is it also your opinion that I can't create a reference type using "struct"?
Not "types of classes". "class types", a term used frequently in the C++
and C++/CLI specifications.
In C++/CLI, the keyword "class" IS ambiguous. You need to know whether it
is prefixed by "value", "ref", "interface" or nothing to know its meaning.
This is the C++/CLI group, not the C# group. The documentation you
mentioned is all C#-centric. The "CLI" specification you mentioned is not
the specification for C++/CLI. That would be here:
specification for C++/CLI:
http://www.ecma-international.org/publications/standards/Ecma-372.htm
"interface class" is part of the C++/CLI syntax, how you can deny the
existence of the term is beyond me.
You might also try reading section 12.2, which is just one of many that
identifies "class types" in C++/CLI as "Ref class types, value class types,
interface types, and delegate types".
Again you claim that "class" is unambiguous in C++/CLI. Actually, the
meaning is context-sensitive.
You're entitled to your opinion, but please don't state it as fact in the
newsgroup where there are people trying to learn C++/CLI. They need to hear
accurate information about the C++/CLI type system, not your improper
attempt to impose C# terminology on C++ (BTW C++ used the terminology first,
so if you don't accept that terms can mean different things for different
languages, it's C# that's wrong).
Is it also your opinion that I can't create a reference type using "struct"?
A
Armin Zingler
Long story short: ;-)
You are absolutly right if you're talking about keywords. However, I was
talking about clarity in a discussion. As I say "interface" to what you
declare as "interface class" in source code, and as I say "value type" what
is declared as "value class", I'm used to say "class" for what is written
"ref class" in source code. I'm not an MVP but I'm reading this group for a
long time, so I can say in good conscience that I'm not the only one using
these terms this way - if not talking about syntactical details. Maybe you
can also understand this point of view.
Armin
You are absolutly right if you're talking about keywords. However, I was
talking about clarity in a discussion. As I say "interface" to what you
declare as "interface class" in source code, and as I say "value type" what
is declared as "value class", I'm used to say "class" for what is written
"ref class" in source code. I'm not an MVP but I'm reading this group for a
long time, so I can say in good conscience that I'm not the only one using
these terms this way - if not talking about syntactical details. Maybe you
can also understand this point of view.
Armin
B
Ben Voigt [C++ MVP]
Armin said:
I can understand that. Many many C# programmers carry their terminology
into this group. But it's not the terminology used by the C++ community, or
the ISO C++ standard, or the C++/CLI standard. So I try to encourage them
to use the C++ terminology when in the C++ groups.
Bad things happen when someone is using the C++ terminology ("class") and a
C# programmer assumes the C# meaning for that word ("reference type") and
starts giving incorrect advise based on that assumption. That's what
happened in this thread to start the whole side discussion. A good clue
that the C++ terminology and meanings were being used should have been the
term "virtual function". If the OP was using the C# wording, he'd have said
"method".