-
abstract! class! passing?
Hi,
please look at these (contradictory?) statements:
B.Eckel
If anyone tries to make an object of an abstract class, the compiler prevents them.
Note that pure virtual functions prevent an abstract class from being passed into a function by value.../Thus, it is also a way to
prevent object slicing (which will be described shortly). By making a
class abstract, you can ensure that a pointer or reference is always
used during upcasting to that class./
a class to be passed ???
Could someone tell me how to pass a class? (especially abstract one)
TVM
-
First of all you *never* pass a class; what you pass is an object, a reference to an object or an address of an object.
The quote is actually rather clear: "By making a
class abstract, you can ensure that a pointer or reference is always
used..."
In other words, you can pass a reference or a pointer that seems to be poiting to an asbtract class but in reality, the pointer or reference are bound to a concrete object derived from that class:
struct Abs
{
virtual int func()=0;
virtual ~ Abs()=0;
};
struct Der: Abs
{
int func(); //override and implement
};
void f(Abs & r);
int main()
{
Der d;
f(d); //passing a reference to Der
}
Danny Kalev
-
 Originally Posted by Danny
In other words, you can pass a reference or a pointer that seems to be poiting to an asbtract class but in reality, the pointer or reference are bound to a concrete object derived from that class:
Hm,
the same applies to non-abstract class which has virtual functions, right?
In addition, if we use func. void f(Abs ) instead of void f(Abs& ) /passing by
value/ with non-abstract base class Abs, late binding doesn't work too (base function is called)./I tested this in some other example/
So, what is so particular about abstract classes in terms of these things?
Only absolute clear thing here is: It's impossible to make an instance of an
abstract class. We use them if we don’t want anyone to create an object of
the base class, only to upcast to it so that its interface can be used.
TVM
-
 Originally Posted by pseudo
Hm,
the same applies to non-abstract class which has virtual functions, right?
Yes, except that when the class isn't abstract, the pointer/reference may actually point to an object of that class i.e., Abs. If the class is abstract, the ponter/reference must point to derived objects.
In addition, if we use func. void f(Abs ) instead of void f(Abs& ) /passing by
value/ with non-abstract base class Abs, late binding doesn't work too (base function is called)./I tested this in some other example/
So, what is so particular about abstract classes in terms of these things?
Normally, you use abstract classes as a mechanims for enforcing a certain interface on a hierarchy of classes. A pure interface doesn't contain an implementation so an abstract class only defines the member functions that need to be implemented in the derived classes. C++ supports this concept by guaranteeing that instances of an asbtract class can't be created (admittedly, a hacker would find at least one way to bypass this restriction and still create an object of an abstract class, but that's another issue).
Dynamic binding works only with reference or pointer arguments. Passing by value disables this mechanism.
Only absolute clear thing here is: It's impossible to make an instance of an
abstract class. We use them if we don’t want anyone to create an object of
the base class, only to upcast to it so that its interface can be used.
Yes.
TVM[/QUOTE]
Danny Kalev
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
Forum Rules
|
Top DevX Stories
Easy Web Services with SQL Server 2005 HTTP Endpoints
JavaOne 2005: Java Platform Roadmap Focuses on Ease of Development, Sun Focuses on the "Free" in F.O.S.S.
Wed Yourself to UML with the Power of Associations
Microsoft to Add AJAX Capabilities to ASP.NET
IBM's Cloudscape Versus MySQL
|
Bookmarks