Every now and again I stumble upon a situation where it's natural to use an abstract class. A typical example is when working with parameterized classes and wanting to swap parameterizations:
Have you considered just dropping the abstractness from your base class and putting in a fatally flawed implementation of the method(s) that you would otherwise leave as pure? You lose the opportunity to get compile time errors if someone forgets to implement the method in their extensions, but with a proper fatal message in the “pure” base implementation it should be pretty easy to determine what’s wrong when it finally fails at run-time. In return, you don’t have to reimplement the uvm macros, nor worry that a new version of uvm will change the `m_uvm… macros out from underneath you.
This was actually on my notes while I was writing the post, but apparently I forgot to put it in. One of the alternatives was doing away with purism (i.e. not use abstract classes). This is what I did in the post about extendable covergroups.
The other two options were fixing the UVM source code to support this (which is obviously not possible) and the approach from the post.
Amazing timing. I JUST had to deal with this situation. I needed to use polymorphism for a parameterized class, but of course, the compiler said no - it thinks that obj#(A) is a different type than obj#(B). So, like you, I resorted to creating a facade base class to keep the compiler happy. I started off with a virtual base class with pure virtual functions, but then I got the issues with the constructor that you mentioned in your post. But instead of digging into the registration macros, I just removed the purity of the virtual class and voila, the sun is shining and the birds are singing again.
If you haven’t already, please submit your ideas to the UVM committee. I’m sure they would be interested.
Cheers.
Hi,
Factory will call the create_comp of the overridden proxy class which is some_concrete_param_component::type_id and this proxy class will in turn create the desired component of some_concrete_param_component. is this understanding correct? If this is true why the base virtual class is being constructed and cause the error?
Thanks
The issue isn’t what ‘create_comp()’ gets called, but the fact that a ‘create_comp()’ function gets compiled for a virtual class, which is an instant compile error.