I've learned two design patterns of writing a subscriber:
1) Derive from uvm_subscriber, override the write function, which is then called over the built-in analysis port
2) derive from uvm_component, install an uvm_analysis_export and uvm_tlm_analysis_fifo, connect them and process in the run_phase
I'm wondering about the following. If I do not derive from uvm_subscriber, but from uvm_component, install an uvm_analysis_export and write a write function, which is to be called over the uvm_analysis_export by the corresponding port, how do I do hook up the uvm_analysis_export to the write? Is it possible at all?
It is not possible to "hook up the uvm_analysis_export to the write". Instead, you need to derive from uvm_component, install a uvm_analysis_imp (an imp not an export) and write a write function.
An imp is the endpoint; (with the subscriber pattern) it is this that calls the write method. An export is a waypoint; it can only be connected to another export or imp.
If we look at the source code for the uvm_subscriber class, we can see how to do it:
virtual class uvm_subscriber #(type T=int) extends uvm_component;
typedef uvm_subscriber #(T) this_type;
// Port: analysis_export
//
// This export provides access to the write method, which derived subscribers
// must implement.
uvm_analysis_imp #(T, this_type) analysis_export;
// Function: new
//
// Creates and initializes an instance of this class using the normal
// constructor arguments for <uvm_component>: ~name~ is the name of the
// instance, and ~parent~ is the handle to the hierarchical parent, if any.
function new (string name, uvm_component parent);
super.new(name, parent);
analysis_export = new("analysis_imp", this);
endfunction
// Function: write
//
// A pure virtual method that must be defined in each subclass. Access
// to this method by outside components should be done via the
// analysis_export.
pure virtual function void write(T t);
endclass
I am not quite sure why you'd want to do this, because as you can see, you'd be pretty much just rewriting what's already done for you in uvm_subscriber. I guess by asking the question you've learnt something and I've refreshed some knowledge in answering it.
Related
In SQLCLR, I can detect if I'm inside an SqlContext, and if so, perform additional functions like writing to the pipe.
However, how do I detect if I'm inside a read-only SQL context, such as method with this attribute:
[SqlFunction(DataAccess = DataAccessKind.Read)]
public static void MyMethod()
{
}
The only way I can surmise is to walk back the stack and look for a method decorated with SqlFunctionAttribute?
Is there a con to implementing a singleton that wraps instance methods with static ones?
For example:
public void DoStuff() { instance._DoStuff(); }
private void _DoStuff() {
...
}
And of course instance would be static. But it would be nicer to call:
Singleton.DoStuff();
Instead of:
Singleton.GetInstance().DoStuff();
I think it depends.
First the GetInstance() really should be used for getting an object back and then using that else where in your code. The Singleton should just help guarantee a single instance of that object exists.
Next if you want to make DoStuff static go ahead, though you have to know to call it that way everywhere else in your code.
So you really have this difference:
var instance = Singleton.GetInstance();
...
instance.DoStuff ()
Vs
Singleton.DoStuff ()
This means that you can pass a singleton object around and not have to know static calls.
Also, I have to mention that Singletons if not used properly can lead to a nightmare in unit testing: http://misko.hevery.com/2008/08/25/root-cause-of-singletons/
Both Java and Javascript allow for a different way of executing static code. Java allows you to have static code in the body of a class while JS allows you to execute static code outside class definitions. Examples:
Java:
public class MyClass {
private static Map<String,String> someMap = new HashMap<String,String();
static {
someMap.put("key1","value");
someMap.put("key2","value");
SomeOtherClass.someOtherStaticMethod();
System.out.println(someMap);
}
}
JS (basically any JS code outside a class):
var myint = 5;
callSomeMethod();
$(document).ready(function () {
$("#hiddenelement").hide();
});
However, it seems like Dart supports either of both ways. Declaring global variables and methods is supported, but calling methods and executing code like in JS is not. This can only be done in a main() method. Also, static code inside a class is not allowed either.
I know Dart has other ways to statically fill a Map like my first example, but there is another case that I can think of for which this is required.
Let's consider the following CarRegistry implementation that allows you to map strings of the car model to an instance of the corresponding class. F.e. when you get the car models from JSON data:
class CarRegistry {
static Map<String, Function> _factoryMethods = new HashMap<String, Function>();
static void registerFactory(String key, Car factory()) {
_factoryMethods[key] = factory;
}
static Car createInstance(String key) {
Function factory = _factoryMethods[key];
if(factory != null) {
return factory();
}
throw new Exception("Key not found: $key");
}
}
class TeslaModelS extends Car {
}
class TeslaModelX extends Car {
}
In order to be able to call CarRegistry.createInstance("teslamodelx");, the class must first be registered. In Java this could be done by adding the following line to each Car class: static { CarRegistry.registerFactory("teslamodelx" , () => new TeslaModelX()); }. What you don't want is to hard-code all cars into the registry, because it will lose it's function as a registry, and it increases coupling. You want to be able to add a new car by only adding one new file. In JS you could call the CarRegistry.registerFactory("teslamodelx" , () => new TeslaModelX()); line outside the class construct.
How could a similar thing be done in Dart?
Even if you would allow to edit multiple files to add a new car, it would not be possible if you are writing a library without a main() method. The only option then is to fill the map on the first call of the Registry.createInstance() method, but it's no longer a registry then, just a class containing a hard-coded list of cars.
EDIT: A small addition to the last statement I made here: filling this kind of registry in the createInstance() method is only an option if the registry resided in my own library. If, f.e. I want to register my own classes to a registry provided by a different library that I imported, that's no longer an option.
Why all the fuss about static?
You can create a getter that checks if the initialization was already done (_factoryMethods != null) if not do it and return the map.
As far a I understand it, this is all about at what time this code should be executed.
The approach I showed above is lazy initialization.
I think this is usually the preferred way I guess.
If you want to do initialization when the library is loaded
I don't know another way as calling an init() method of the library from main() and add initialization code this libraries init() method.
Here is a discussion about this topic executing code at library initialization time
I encountered the same issue when trying to drive a similarly themed library.
My initial attempt explored using dart:mirrors to iterate over classes in a library and determine if they were tagged by an annotation like this (using your own code as part of the example):
#car('telsamodelx')
class TelsaModelX extends Car {
}
If so, they got automatically populated into the registry. Performance wasn't great, though, and I wasn't sure if how it was going to scale.
I ended up taking a more cumbersome approach:
// Inside of CarRegistry.dart
class CarRegister {
static bool _registeredAll = false;
static Car create() {
if (!_registeredAll) { _registerAll()); }
/* ... */
}
}
// Inside of the same library, telsa_model_x.dart
class TelsaModelX extends Car {}
// Inside of the same library, global namespace:
// This method registers all "default" vehicles in the vehicle registery.
_registerAll() {
register('telsamodelx', () => new TelsaModelX());
}
// Inside of the same library, global namespace:
register(carName, carFxn) { /* ... */ }
Outside of the library, consumers had to call register(); somewhere to register their vehicle.
It is unnecessary duplication, and unfortunately separates the registration from the class in a way that makes it hard to track, but it's either cumbersome code or a performance hit by using dart:mirrors.
YMMV, but as the number of register-able items grow, I'm starting to look towards the dart:mirrors approach again.
is is possible to do end up with something like this:
ServiceChild (class) extends (or only partial implements) Service and overrides sayHello
Service (interface) implements hello,goodbye
Hello (has a mixin HelloMixin) has method sayHello
Goodbye (has a mixin GoodbyeMixin) has method sayGoodbye
I've tried doing the above using the concern approach in ServiceChild
public class ServiceChild extends ConcernOf<Service> implements Hello
{
#Override
public String sayHello() {
return "Rulle Pharfar";
}
}
However using this approach only the Hello implementation are detected by java and not the rest of the stuff from the Service class. So is there any other approach that would work?
I'm not sure I understand what you are trying to do, but a concern should more be seen as a wrapper around the original implementation of the class it is a concern of.
As the documentation states:
A concern is a stateless Fragment, shared between invocations, that acts as an interceptor of the call to the Mixin.
And would usually do this:
//Given interface MyStuff
#Mixins( MyStuff.Mixin.class )
#Concerns( MyStuffConcern.class )
public interface MyStuff
{
public void doStuff();
abstract class Mixin implements MyStuff
{
public void doStuff()
{
System.out.println( "Doing original stuff." );
}
}
}
public class MyStuffConcern extends ConcernOf<MyStuff>
implements MyStuff
{
public void doStuff()
{
// if I want to do anything before going down the call chain I'll do it here
System.out.println( "Doing stuff before original." );
// calling the next concern or actual implementation
next.doStuff();
// anything to do after calling down the call chain - here is the place for it
System.out.println( "Doing stuff after original." );
}
}
But nevertheless if you have a concern on a interface you should also implement said interface:
public abstract class ServiceChild extends ConcernOf<Service> implements Service
{
public String sayHello()
{
return "Rulle Pharfar";
}
}
Hope this helped.
I also don't fully understand the question.
As Arvice says, Concerns are the equivalent of around-advice in AOP, with much more precise pointcut semantics. Although it is technically correct that a concern 'wraps' the underlying concerns/mixins, I prefer to not thinking of it as a 'wrapper' but an 'interceptor'. It is the incoming call that is handled. Conceptually slightly different, and it may not work for everyone.
It is also possible that both Concerns (stateless) and Mixins (stateful) implements only a subset of the methods in the interface they override, simply by making the class 'abstract'. Qi4j will fill in the missing (and unused) method calls. And any combination may be used.
Further, well implemented concerns should call the 'next', because they should be unaware of their actual uses. If the concerns are expected to take care of the method call. There must be a Mixin for each composite type method, or assembly will fail.
So in short;
1. A Mixin implementation may implement zero (a.k.a private mixins), one or more methods of the composite type interface.
2. A Concern may implement one or more methods of the composite type interface.
It is also interesting to note that when a class (mixin or concern) calls one of its own methods that are in the composite type interface, the call will not be intra-class, but call the composite from the outside, so the entire call stack is invoked, to ensure that an internal call and an external call are identical in results. Patterns exists if this needs to be bypassed.
I am trying my best to explain the situation. I hope, what I wrote, is understandable.
We already have class defined like
public ref class TestClass
{
public:
TestClass();
virtual ~TestClass();
protected:
Car* m_car;
}
TestClass is managed C++ and Car is unmanaged C++.
So far so good, but now I need to make static object of TestClass also. So I modify the code like below
public ref class TestClass
{
private:
static TestClass^ s_test = nullptr ;
public:
TestClass();
virtual ~TestClass();
static TestClass^ Instance();
protected:
Car* m_car;
}
When I want to use static instant of the class, I just get it from calling
TestClass staticobj = TestClass::Instance();
Elsewhere, just call
TestClass normalobj = gcnew TestClass();
Instance function is creating s_test static object and returns it.
TestClass ^ TestClass::Instance()
{
if(s_test == nullptr)
{
s_test = gcnew TestClass();
s_test->m_car = new Car();
}
return s_test;
}
Is it a good approach?
Is there any other better approach to accomplish same thing?
Edit :
FYI Above code works.
I combined Krizz and Reed Copsey’s solutions. That solve independent Singleton and memory leak.
Here is my sample code,
Special Singleton class derived from test class,
public ref class SpecialSingletonTestClass: public TestClass
{
private:
static SpecialSingletonTestClass ^ s_ SpecialSingletonTestClass = nullptr;
public:
SpecialSingletonTestClass ();
static SpecialSingletonTestClass ^ Instance();
};
Changed the testclass so it has now one more finalizer function.
public ref class TestClass
{
public:
TestClass ();
virtual ~ TestClass ();
! TestClass ();
protected:
Car* m_car;
}
I tested above pattern , it worked.
Thanks you guys,
L.E.
Is it a good approach?
I would probably not consider this a good approach, as you're making a single class both a singleton and a normal class that you can instance directly.
Typically, if you need a singleton, this would preclude the need or desire to be able to instantiate the class.
If you truly need to have a way to have a "global" instance of this class, I would encapsulate that in a separate class which implements the singleton. This would, at least, make it clear that you are dealing with something that's a single instance in that case. I would not mix both use cases into a single class.
Well, actually there is an issue with memory leaks in your code.
You declare only virtual ~TestClass(); which, for managed classes, are internally turned by C++/CLI compiler into implementation of IDisposable.Dispose().
Therefore, if you put delete car into it, it will be called only if you delete test_class or, e.g. wrap into using (TestClass tst) {} block when using from C#.
It will not be called when object is GCed!
To be sure it is called you need to add finalizer to your class !MyClass(); which is turned by compiler into virtual void Finalize() and thus non-deterministically called when GC is freeing an object.
And it is the only way to free m_car of singleton object.
Therefore, I suggest:
TestClass()
{
m_car = new Car();
}
~TestClass()
{
if (m_car)
delete m_car;
m_car = NULL;
}
!TestClass()
{
if (m_car)
delete m_car;
m_car = NULL;
}
I'm unsure as to what situation you could possibly be in that would require both singleton-style semantics and normal creation semantics for the same class.
As far as what you've coded though, it looks completely fine. My only comments would be that your Instance() function shouldn't need to perform construction on Car, the Instance() function should just call the default constructor of TestClass which should do all that.
EDIT
In reference to:
#crush . The class is already define i just need to get static object of it. Singleton means only one object of the class, but in this case, class have multiple normal object. But i want to use only one object of this class for one specific goal only for limited period of time. – L.E. 2 mins ago
A singleton is (usually) a sign of bad design - alot of people call it an anti-pattern actually. Chances are if you just need this one single specific instance of this class for a limited period of time there are some issues:
Singleton design is made for static-style existence - the variable will live for the scope of your program after lazily initialized.
Allowing global access will move your code towards spaghetti logic. You'd be better off dynamically allocating the one you need and passing the pointer to it to where you need it to be. A shared_ptr would be good for this.
You should find a way around the singleton-style implementation in this case even if it's more work for you - it'll almost certainly be better design.