How do you define a non-default constructor for a COM object in Visual C++?
Is such a thing even possible?
Or do you have to construct a default object and use an init(params) method to configure it?
COM coclasses implemented in C++ cannot have a constructor that takes an argument. The CoCreateObject() function, the primary way to create an instance of a coclass, doesn't have any way to pass arguments. Same with IClassFactory::CreateInstance(), the underlying method.
So yes, not possible, you'll need an Initialize() method. And the code to verify that it was called, E_UNEXPECTED with a decent IErrorInfo message is boilerplate.
Related
I'd like to use a single duktape/C constructor function as dispatcher for these kind of calls. When the dispatcher function is called I need to know for which class this happend to call the appropriate C++ construction function.
I guess the this binding won't help since it represents the (not yet fully initialized) JS object we are creating here.
Another option would be the current function, but from the docs I can't see how to get the class name from that. What else could I use?
Could you elaborate what you mean by "class name"? Do you mean the .name property of the Ecmascript function object which is used as a the 'new' target?
If so, you can use duk_is_constructor_call() to see if the current call is a constructor call, then use duk_push_current_function() to get access to the Ecmascript constructor function object, and then read its properties using the usual property API calls. For example, if by "class name" you mean .name of the function object, you'd just read its "name" property using duk_get_prop_string().
I want to make the return type of my method generic. The caller will decide which type it should expect.
Actually my method will be a member of interface and the class which will implement it will have a decision making block to delegate the work to other methods.
Hence I want to make the return type of the interface method as generic.
I can achieve this by using dynamic or object keyword or c# generic type.
I am not able to figure it out which will be the best option to achieve it and what are the limitations and advantages of each type.
public interface ICoreWrapper
{
Response<T> ExecuteDeviceCommand<T>(DeviceCommand deviceCommand, object param = null);
}
Please suggest me.
Thanks in advance.
If you do not know the type at compile time you could use dynamics but they will be slower because they are using runtime invocation and less safe because if the type doesn't implement the method you are attempting to invoke you will get a runtime error.
Use dynamic return type, Based on the input type return the appropriate object.
I have a Groovy script that lets the user define some dynamic properties and methods and later executes a user-defined closure. A script would look like this:
// init properties and methods dynamically at runtime
context.prop1 = "Some test value"
context.method1 = { String input ->
"exec " + input.toUpperCase()
}
// "this" is set to the context variable from above
run {
println method1( prop1 )
}
So in the beginning of the script, a context is initialized with user-defined properties (e.g. prop1) and methods (e.g. method1). The context is then used as this pointer in the run closure. I have achieved this by dynamically extending the meta class of the context and setting the context as delegate of the run closure (with DELEGATE_FIRST as resolves strategy).
Currently I am struggling at type checking. Before executing the run closure, I would like to check if method1 really expects prop1. I have looked into the DelegatesTo annotation, but that doesn't seem to work for dynamically extended objects. I have also played with the AST, but since my knowledge on that topic is limited, I haven't come up with a solution. If what I want to achieve is possible, any pointers in the right direction would be greatly appreciated.
You want to add a method to a context at runtime and then type check this before execution of that method.
Type checking is done at compile time. That is before anything of your program is executed. There is normally no chance this can ever check anything that will only happen at runtime, unless you have a way to statically declare it and give the compiler the power to do the check. But this means normally, you will have to do static compilation.
One way would be to use type checking extensions, but I think in your case that might be overkill. A more simple way would be to use extension modules. And the most simple way would be to use custom script base class.
But for any of these solution you will need static compilation to really have type checking, same for DelegatesTo (which is more used in combination with extension modules). For a type checked DSL a mix of type checking extensions and extension modules can work very well. But you will of course loose more dynamic features of the language and some simplicity.
Is it a best practice to wrap the ServiceStack's JsonServiceClient within a using statement?
var client = new JsonServiceClient();
client.Post(request);
versus
using (var client = new JsonServiceClient())
{
client.Post(request);
}
Which one is the best?
JsonServiceClient implements IDisposable so best practise would be to use it with a using statement.
However there are scenarios whereby you need to the share an instance of the JsonServiceClient across multiple requests (Such as when you use cookie based sessions, as the cookies are contained in the instances cookie container), in which case you would use the client without a using statement, but ensure that your application calls the Dispose method of the client, when it no longer requires the client.
This answer by gdoron further explains the best practise regarding classes that implement IDisposable such as the JsonServiceClient and the reasoning behind it.
As a rule, when you use an IDisposable object, you should declare and instantiate it in a using statement. The using statement calls the Dispose method on the object in the correct way, and (when you use it as shown earlier) it also causes the object itself to go out of scope as soon as Dispose is called. Within the using block, the object is read-only and cannot be modified or reassigned.
The using statement ensures that Dispose is called even if an exception occurs while you are calling methods on the object. You can achieve the same result by putting the object inside a try block and then calling Dispose in a finally block; in fact, this is how the using statement is translated by the compiler. The code example earlier expands to the following code at compile time (note the extra curly braces to create the limited scope for the object):
I hope that helps.
I've been poking into some Node.js modules in the hopes of learning something I could have missed while creating a module with similar functionality. Then I came across this code from Hound:
function Hound() {
//why this?
events.EventEmitter.call(this)
}
//ok, so inheriting the EventEmitter
util.inherits(Hound, events.EventEmitter);
I know that the util.inherits() function from Node.js creates a new Parent instance as the prototype of the child constructor as stated in the docs:
The prototype of constructor will be set to a new object created from superConstructor.
So if our constructor is inheriting EventEmitter through util.inherits(), what is that code in the constructor for?
It's just making your Hound class an EventEmitter object.
It gives your the EventEmitter instance methods to the class.
E.g., houndInstance.emit('something')
Other objects that are listening to these events can then respond to them.
Per your comment:
// constructor
function Hound() {
// equivalent of calling a "super" or "parent" constructor
SomeClass.call(this);
}
In JavaScript, .call(context) is a means of invoking a function in a specific context. In the example above, we're just calling the SomeClass constructor and passing this (the Hound class in this example) as the context.
From your comments:
But doesn't util.inherits() already cover that? Or am I missing something?
What you are missing is that util.inherits() merely inherits the parent object. It doesn't set up the constructor to automatically call the parent object's constructor. In most cases it would be enough since most objects don't do much initialization in their constructors.
But events.EventEmitter apparently does some initialization in the constructor that has some important side effects. Since prototypical inheritance does not automatically call the parent's constructor you need to call it manually in this case. Hence the events.EventEmitter.call(this) line.
Note that an alternative is to use the module pattern which always calls the parent's constructor. That is because the module pattern is not inheritance per-se but emulates inheritance by abusing the mixin/decorator pattern - it creates an object from the parent constructor and manually add attributes to it. Lots of people don't like the module pattern because it duplicates functions and attrubutes - hence they see it as wasting memory. Also, it's not proper inheritance and so breaks stuff like instanceof.