| View previous topic :: View next topic |
| Author |
Message |
desperado
Senior
Joined: Jan 16, 2009
Posts: 41
|
 Posted: Tue Apr 06, 2010 7:16 am Post subject: Class Vs Abstract Class?? |
 |
|
Hi All..
Whats the advantage of Abstract Class over the normal Class and Vice-Versa. Kindly brief me out!!
Thanks,
Desperado  |
|
| Back to top |
|
 |
AmreSultan
Senior
Joined: Jan 13, 2004
Posts: 77
Location: Ottawa, Canada
|
| Posted: Tue Apr 06, 2010 8:19 am Post subject: |
|
|
Think of an abstract class as a template or like a Java interface if you're familiar.
The idea is to define the user interface via the method definitions but not provide the implementation. This is why it's 'abstract' and hence cannot be instantiated.
Now any classes that extend the abstract class can (and in fact must ) implement all the abstract methods (pure virtual methods in SV speak) in order to not be abstract themselves. Only when a class has no pure virtual methods can it be instantiated. I.e., all methods must have an implementation.
So this way you can force anyone that wants to extend your class to implement a read, write, or whatever method that was defined in the abstract class.
Amre
Amre
_________________
--Amre Sultan-- |
|
| Back to top |
|
|
pavanshanbhag
Senior
Joined: Mar 25, 2009
Posts: 380
Location: Bangalore, India
|
| Posted: Thu Apr 08, 2010 3:06 am Post subject: |
|
|
Hi Amresultan,
| Quote: |
The idea is to define the user interface via the method definitions but not provide the implementation. This is why it's 'abstract' and hence cannot be instantiated.
|
It can be instantiated but cannot call the constructor of the abstract class in the derived class. Although its meaningless to instantiate abstract class inside a derived class, since the derived class will extend the base abstact class.
For ex :
| Code: |
virtual class abstarct_base_class;
-----
endclass
class derived_class extends abstarct_base_class;
abstarct_base_class a_b_c; //Handle can be created, but its meaningless since we are
//extending the abstarct class
a_b_c = new (); // Constructor called - this is invalid
endclass;
|
_________________
-Pavan K Shanbhag
“The difference between genius and stupidity, genius knows his limits.” - Albert Einstein |
|
| Back to top |
|
|
AmreSultan
Senior
Joined: Jan 13, 2004
Posts: 77
Location: Ottawa, Canada
|
| Posted: Thu Apr 08, 2010 7:31 am Post subject: |
|
|
| Quote: | | Code: | abstarct_base_class a_b_c; //Handle can be created, but its meaningless since we are
//extending the abstarct class |
|
This is not instantiating the class. This is only declaring a variable or handle. The 'instantiation' is not done until an object is created, and hence memory allocated, through the calling of the constructor.
I believe I am using accepted OOP terminology correctly.
Regards,
_________________
--Amre Sultan-- |
|
| Back to top |
|
|
pavanshanbhag
Senior
Joined: Mar 25, 2009
Posts: 380
Location: Bangalore, India
|
| Posted: Thu Apr 22, 2010 12:20 am Post subject: |
|
|
HI Amresultan,
| Quote: |
The 'instantiation' is not done until an object is created, and hence memory allocated, through the calling of the constructor.
|
Yes you are right on it. Thanks for your valuable information.
_________________
-Pavan K Shanbhag
“The difference between genius and stupidity, genius knows his limits.” - Albert Einstein |
|
| Back to top |
|
|
BugCatcher
Senior
Joined: Apr 23, 2010
Posts: 43
|
| Posted: Fri Apr 23, 2010 4:21 am Post subject: |
|
|
As commented by experts:
a) Abstract(Virtual) classes serve like a template.
Eg: I would like all my transaction classes to follow a *unique* style.
b) They can have virtual methods. Number of arguments can be fixed in the template(base class virtual method).
All the extensions *must* have the same number and type of arguments
(consistent code is always complete and will have less bugs)
c) polymorphism : The main use of virtual members. Base class can hold the derived class handle and you can call the methods.
special and interesting case:
D) Call to virtual method from constructor has a different functionality than compared to non-virtual methods.
suppose consider the following code:
| Code: |
class A
virtual task x;
...
endtask
function new();
x();
enddunction
endclass
class B extends A;
virtual task x;
...
endtask
endclass
initial begin
B obj = new()
end
|
The flow of execution will be
a) control will go to new() of class B
b) super.new() will pass the control to new of class A
c) The new of class A is calling x()
d) The point to note is "The B: () will be executed first. not the A:()". Since x is virtual.
if x is non-virtual A:() will be executed.
experts am I correct? |
|
| Back to top |
|
|
BugCatcher
Senior
Joined: Apr 23, 2010
Posts: 43
|
| Posted: Fri Apr 23, 2010 5:47 am Post subject: |
|
|
Man... I meant to type scope resolution but not smiles
corrected the above code:
The flow of execution will be
a) control will go to new() of class B
b) super.new() will pass the control to new of class A
c) The new of class A is calling x()
d) The point to note is "The B :: x() will be executed first. not the A :: x()". Since x is virtual.
if x is non-virtual a :: x() will be executed.
_________________
-Bug Catcher
============================== |
|
| Back to top |
|
|
AmreSultan
Senior
Joined: Jan 13, 2004
Posts: 77
Location: Ottawa, Canada
|
| Posted: Fri Apr 23, 2010 8:03 am Post subject: |
|
|
Nothing wrong with the smilies BugCatcher!!
Just to clarify your example. There's nothing unique about the virtual method behaviour from within the constructor. The behaviour is the same no matter where you call the virtual method from. To illustrate the real power of polymorphism I would do the following.
| Code: |
initial begin
B b = new(); //derived class
A a = new(); //base class
a = b;
a.x(); //This calls the implementation of x() defined in b not a.
end
|
If x was not virtual the A:: x() would be called but because it is virtual B:: x() gets called.
So with non-virtual methods, what you see is what you get. You get the method implementation from the obj of the same type as the handle definition. Nothing special there.
With virtual methods, the method call is based on the runtime object that the handle is pointing to.
So in the above example imagine all the 'A' related code is in one verification component that knows nothing about the derived class B. Then you replace the 'a' object in that component with a B object and voila! You get your piece of 'A' Verification IP to behave like it was 'B' without ever touching the original code.
_________________
--Amre Sultan-- |
|
| Back to top |
|
|
BugCatcher
Senior
Joined: Apr 23, 2010
Posts: 43
|
| Posted: Fri Apr 23, 2010 11:15 am Post subject: |
|
|
Dear AmreSultan,
I have two programs here
Program 1: when the function 'x' is virtual:
| Code: |
program test();
class A;
virtual function void x();
$display(" CLASS A: METHOD X");
endfunction
function new();
x();
endfunction
endclass
class B extends A;
virtual function void x();
$display(" CLASS B: METHOD X");
endfunction
function new();
super.new();
endfunction
endclass
initial begin
B obj = new();
end
endprogram
|
output of simulation is: CLASS B: METHOD X
Program 2: same as above except 'x' is non-virtual (no other change)
| Code: |
program test();
class A;
function void x();
$display(" CLASS A: METHOD X");
endfunction
function new();
x();
endfunction
endclass
class B extends A;
function void x();
$display(" CLASS B: METHOD X");
endfunction
function new();
super.new();
endfunction
endclass
initial begin
B obj = new();
end
endprogram
|
output of simulation is: CLASS A: METHOD X
There is a difference right? do you agree?
try it and let me know...
_________________
-Bug Catcher
============================== |
|
| Back to top |
|
|
AmreSultan
Senior
Joined: Jan 13, 2004
Posts: 77
Location: Ottawa, Canada
|
| Posted: Fri Apr 23, 2010 1:28 pm Post subject: |
|
|
Hi BugCatcher,
So here's what I see is happening.
In Program1 the method x() is virtual.
When you call B = new() you get a call to super.new() which in turn calls the virtual method x() of 'this' object. At runtime the object it's referring to is of type B. The only object in your example is of type B because that's the only new call in your code. Hence there is no way the runtime type can be anything but B. I hope we agree so far. If so then because the methods are virtual the implementation of x() that gets called is going to be of the runtime type which we said was B so the output should be
CLASS B: METHOD X
which it is.
In Program2 the methods are not virtual so the print message you get should be of the 'compile time' type.
In this case the method call in A::new() is calling this.x() which in that context is of type A. At compile time we don't know that the x() call in the constructor is going to be called from a B obj.I hope we agree here as well. So the output we expect is that of A:: x()
CLASS A: METHOD X
which it is.
I guess the point I was trying to make (and obviously I did a poor job of it) is that the fact that you called the virtual method x() from within the constructor is inconsequential to the results. If you take the following example you should get similar results to above.
Program 3
| Code: | class A;
virtual function void x();
$display(" CLASS A: METHOD X");
endfunction
function new();
//nothing interesting here.
endfunction
function void y();
x();
endfunction
endclass
class B extends A;
virtual function void x();
$display(" CLASS B: METHOD X");
endfunction
function new();
super.new();
endfunction
function void();
super.y();
endfunction
endclass
initial begin
B obj = new();
obj.y();
end |
If the x() functions are virtual you get the same output as Program1 if the x() functions are not-virtual you get the same output as your Program2.
BugCatcher wrote:
| Quote: |
D) Call to virtual method from constructor has a different functionality than compared to non-virtual methods.
|
I guess my only disagreement was the "from constructor" part of your statement.
So your understanding of the polymorphic behaviour of virtual methods in SV is correct, but it's not governed by the fact that the method is called from the constructor in particular.
I hope this is a little clearer.
Thanks,
_________________
--Amre Sultan-- |
|
| Back to top |
|
|
BugCatcher
Senior
Joined: Apr 23, 2010
Posts: 43
|
| Posted: Fri Apr 23, 2010 1:42 pm Post subject: |
|
|
Yup. Thanks !!
_________________
-Bug Catcher
============================== |
|
| Back to top |
|
|
BugCatcher
Senior
Joined: Apr 23, 2010
Posts: 43
|
| Posted: Fri Apr 23, 2010 1:49 pm Post subject: |
|
|
Hello AmreSultan,
Yes. I agree with you. The caller need not be 'constructor'.
Following is the program and its output:
| Code: |
program test();
class A;
virtual function void x();
$display(" CLASS A: METHOD X");
endfunction
function void y();
x();
endfunction
endclass
class B extends A;
virtual function void x();
$display(" CLASS B: METHOD X");
endfunction
function void y();
super.y();
endfunction
endclass
initial begin
B obj = new();
obj.y();
end
endprogram
|
output: same as the call from constructor : CLASS B: METHOD X
Cheers,
_________________
-Bug Catcher
============================== |
|
| Back to top |
|
|
AmreSultan
Senior
Joined: Jan 13, 2004
Posts: 77
Location: Ottawa, Canada
|
| Posted: Fri Apr 23, 2010 1:50 pm Post subject: |
|
|
No problem.
_________________
--Amre Sultan-- |
|
| Back to top |
|
|
desperado
Senior
Joined: Jan 16, 2009
Posts: 41
|
| Posted: Sun Apr 25, 2010 11:51 pm Post subject: |
|
|
Hi All,
Truely thanks to all of your valueable comments & examples...
Thanks,
Desperado --> A Salute to all the Professionals & there Professionalism  |
|
| Back to top |
|
|
nimesh
Newbie
Joined: Jan 03, 2012
Posts: 2
|
| Posted: Wed Jan 04, 2012 2:42 am Post subject: |
|
|
Dear Amer Sultan and BugCatcher,
I tried given example and observed following things.
When method x() called from constructor, it calls its own x() method even though it is defined as VIRTUAL and when it is called through y() method, it calls derived class x() method.
Below is a code and its simulation results.
| Code: |
program test();
class A;
virtual function void x();
$display(" CLASS A: METHOD X");
endfunction
function new();
x();
endfunction
function void y();
x();
endfunction : y
endclass
class B extends A;
virtual function void x();
$display(" CLASS B: METHOD X");
endfunction
function new();
super.new();
endfunction
function void y();
super.y();
endfunction : y
endclass
initial begin
B obj = new(); // THIS PRINTS => CLASS A: METHOD X
obj.y(); // THIS PRINTS => CLASS B: METHOD X
end
endprogram
======================================================
== Simulation Result ==
======================================================
QuestaSim-64 qverilog 6.5c Compiler 2009.08 Aug 27 2009
/tools/mentor/questa6.5c/questasim/bin/../linux_x86_64/qverilog virtual_task.sv
-- Compiling program test
Top level modules:
test
+ /tools/mentor/questa6.5c/questasim/linux_x86_64/vsim -lib work test -c -do run -all; quit -f -appendlog -l qverilog.log -vopt
Reading /tools/mentor/questa6.5c/questasim/tcl/vsim/pref.tcl
# 6.5c
# vsim -appendlog -do {run -all; quit -f} -l qverilog.log -lib work -c -vopt test
# // QuestaSim-64 6.5c Aug 27 2009 Linux 2.6.18-194.el5
# //
# // Copyright 1991-2009 Mentor Graphics Corporation
# // All Rights Reserved.
# //
# // THIS WORK CONTAINS TRADE SECRET AND
# // PROPRIETARY INFORMATION WHICH IS THE PROPERTY
# // OF MENTOR GRAPHICS CORPORATION OR ITS LICENSORS
# // AND IS SUBJECT TO LICENSE TERMS.
# //
# Loading sv_std.std
# Loading work.test(fast)
# run -all
# CLASS A: METHOD X
# CLASS B: METHOD X
|
|
|
| Back to top |
|
|
|
Forum FAQ
Search
Usergroups
Profile
Digest
Log in
