Pass a C++/CLI wrapper of a native type to another C++/CLI assembly - assemblies

Suppose I have the following simple wrapper of a NativeClassInstance.
public ref class Wrapper
{
private:
NativeClass *_wrapped;
public:
Renderer()
{
_wrapped = new NativeClass();
}
~Renderer()
{
delete _wrapped;
}
operator NativeClass*()
{
return _wrapped;
}
}
Now, I want to create an instance of Wrapper from C# with Wrapper wrapper = new Wrapper() and use it in another native functionalities wrapper that resides in another assembly with Helper.Foo(wrapper) (nothing strange having other functionalities not directly related to the wrapped classes in another assembly, IMO):
// Utilities is in another Assembly
public ref class Helper
{
public:
static Foo(Wrapper ^wrapper)
{
// Do something in native code with wrapper->_wrapped
}
}
The results with the implicit user conversion is:
candidate function(s) not accessible
If I make _wrapped public it is:
cannot access private member declared in class ...
Now, I've learnt that native type visibility is private outside of the assembly. So, how I'm supposed to use the wrapped entity in native code outside the assembly it's defined? I've read of make_public but you can't use with template types so it seems very limiting in the general case. Am I missing something? Is there a more correct solution?

I haven't been able to successfully expose native types using make_public, however a solution I have used is to put NativeClass in its own native DLL and then a) reference the native DLL from both assemblies; and b) pass the pointer to the native class around as an IntPtr.
Under the above scenario, instead of having an operator NativeClass* you might use a property such as
property IntPtr WrappedObject {
IntPtr get() { return IntPtr(_wrapped); }
}
You then retrieve NativeObject in you helper assembly by
static void Foo(Wrapper ^wrapper)
{
NativeObject *_wrapped
= static_cast<NativeObject*>(wrapper->WrappedObject.ToPointer());
// ... do something ...
}

If you use make_public, your solution of making _wrapped public should work (it would obviously be best to make a public accessor instead). Regarding your comment "I've read of make_public but you can't use with template types so it seems very limiting in the general case." I agree--read here for the workaround I used:
http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/b43cca63-b0bf-451e-b8fe-74e9c618b8c4/
More related info:
Best workaround for compiler error C2158: make_public does not support native template types
Good luck!

Related

How Poco::SharedLibrary loading and instantiating classes?

I know that dynamic libraries can be loaded by Poco::SharedLibrary as below:
using PocoLibraryPtr = std::shared_ptr<Poco::SharedLibrary>;
poco_library = PocoLibraryPtr(new Poco::SharedLibrary(library_path));
I see in the code that the class is instantiated directly after loading. Is this feasible? Currently this code works fine.
template <typename ClassObject, typename Base>
class ClassFactory : public AbstractClassFactory<Base> {
public:
ClassFactory(const std::string& class_name,
const std::string& base_class_name)
: AbstractClassFactory<Base>(class_name, base_class_name) {}
Base* CreateObj() const { return new ClassObject; }
};
When the class is loaded, then the code use
classobj = factory->CreateObj();
to create the class. I did not find similar usage online. Is there any code I didn't notice?
It looks like you want a shared library to create an object using a templatized factory class.
Template instantiations are static polymorphic so the factory object needs to be determined at compile time.
In other words, no, that won't work.
If you specifically want Poco SharedLibrary help, take a look at the Poco documentation for more help: https://pocoproject.org/docs/Poco.SharedLibrary.html.
Or look at the slides here: https://pocoproject.org/slides/120-SharedLibraries.pdf

Passing native shared_ptr across managed assembly

We are in the process of converting C# code to C++, but we need to do so in phases. I am at a point now where I need to instantiate several native objects from within managed code. These native objects I cannot change, and their declaration looks like this:
public class NativeA();
public class NativeB(std::shared_ptr<NativeA> obj);
Both NativeA and NativeB need to be instantiated from managed code as:
void main() {
ManagedA ObjectA = gcnew ManagedA();
ManagedB ObjectB = gcnew ManagedB(ObjectA);
}
The problem comes in with getting the shared_ptr of NativeA in the constructor of NativeB. Niether NativeA nor NativeB will be manipulated in managed code, they just need to be instantiated. Ideally, something like this:
public ref class ManagedA {
public:
ManagedA() { _object = new NativeA(); }
~ManagedA() { delete _object; }
NativeA * Get() { return _object; }
private:
NativeA *_object;
};
public ref class ManagedB {
public:
ManagedB(ManagedA^ objectA ) {
_object = new NativeB(std::make_shared<NativeA>(*objectA->Get());
}
~ManagedB() { delete _object; }
private:
NativeB *_object;
};
But, this is not allowed in c++/cli because native types are declared as private. Defining #pragma make_public(NativeA) does not solve this either.
My intent is not to work with the native objects in managed code, they just need to be instantiated, so I really don't care about trying to marshal the native pointers and deal with .NET GC if I don't have to, and I don't want to perform a copy. I just want to wrap the classes in order to pass them around.
Is there a clean and simple way to do this?
It appears that the answer was not due to a syntax or usage problem. The two managed objects were in different DLLs and could not be passed across them via .NET. Once the code was compiled in the same project, the issue was resolved.
Although the error message indicated the problem was an accessibility issue in VS 2015, and because it reported it during the link phase, I suspect the cause was because the linker would not have known about the implementation of the NativeA in NativeB without declaring an extern. Being wrapped in CLR, it surfaced as a different issue.

How to reference a class in ASP.NET

I created a website and would like to have a class to centralize all the code that I use frequently in the entire project, for instance, a method to connect to the database. Question: after I create this class, on the App_Code folder, how can I use it in the aspx.cs pages? I mean, should a reference it? Should I inform add a namespace?
Thanks!
Create the class file as public and you will be able to access the class file at any part of your project.
namespace applicationName
{
public class DataManager
{
public static DataTable GetData(StringBuilder sql)
{
}
}
}
you can access the DataManager from your code.
DataManager.GetData(SQL);
Yes, put your class in a namespace and consider making the class static if possible, that way it can be used in code throughout your project without instantiating the class. This is common for utility classes that pass in objects and do work with them, but do not need the actual utility method to be part of a class instance.
For example:
namespace My.Utilities
{
public class static ConnectionStringHelper
{
public static string GetConnectionString()
{
// Logic here to actually get connection string
return yourConnectionString;
}
}
}
Now, code in your project just needs to reference the My.Utilities namespace and then can use the GetConnectionString() method, like this:
using My.Utilities;
string connString = ConnectionStringHelper.GetConnectionString();
You can do it a number of ways. Technically you can drop the namespace completely and your code becomes a free for all (accessible from anywhere naturally). I prefer to use namespaces personally, but I have seem people just avoid them.
If your class Foo is in Some.Namespace, you can reference it as such:
Way one:
Some.Namespace.Foo foo = new Some.Namespace.Foo()
Way two: Use the "Use" command
If your class is inside of Some.Namespace and you don't want all the junk preceding your class name, you can add:
using Some.Namespace;
to the top of your file.
I may be miss understanding what you are saying. If you are talking about setup, you can make a centralized class that manages everything. This class can be a singliton. For instance:
class MyClass
{
public static MyClas Singliton;
static MyClass()
{
Singliton = new MyClass();
}
public void someFunction()
{
}
}
This will create and manage a single reference to your class so that everything is managed out of there (hence being called a "singleton"). As a result, you can access it by:
MyClass.Singliton.someFunction();
There are ways to protect your singliton instance from being overwritten, but this is the basic idea. If you want to manage stuff out of a single location without recreating classes, singletons are the way!
http://msdn.microsoft.com/en-us/library/ff650316.aspx
If the class is wrapped in a namespace, then yes, you'll need a using statement that matches your namespace. For instance, if your class is wrapped in a namespace like so:
namespace My.Namespace
{
public class Foo
{
//Methods, properties, etc.
}
}
then anywhere you want to use that class you'll need to add
using My.Namespace;
to the top of the files where you want to utilize the class(es) you've defined. Then you can use your class as you would expect:
Foo foo = new Foo(); //for a new instance
Foo.Bar(); //for a static method
This is, of course, assuming that the class is in the same assembly and you don't want to mess with adding it to the GAC.
Alternatively, if for some reason you don't to use a using statement you can use the fully qualified name of the class:
My.Namespace.Foo foo = new My.Namespace.Foo(); //for a new instance
My.Namespace.Foo.Bar(); //for a static method
This is most useful if you have namespaces that conflict, for instance if you had
namespace My.Namespace
{
public class Foo
{
//Methods, properties, etc.
}
}
somewhere, and
namespace MyOther.Namespace
{
public class Foo
{
//Methods, properties, etc.
}
}
somewhere else, but needed to use them both in the same scope.

Access objects instantiated in Flex app's MXML file in other AS classes

I've got an object declared and instantiated in my Flex application's singular MXML file:
public var CDN:CDNClass = new CDNClass;
I would like to access this same CDN object (and its public methods and properties) in another class declared in a separate .as file as such:
package my.vp
{
import my.media.CDNClass;
public class SyncConnectorManager
{
private function syncMessageReceived(p_evt:SyncSwfEvent):void
{
switch (p_evt.data.msgNm)
{
case "startStream" :
// Play a stream
CDN.parsePlayList(p_evt.data.msgVal);
break;
But when I try to access the public method parsePlayList in the CDN object in a method in the class defined in the .as file, I get the following error:
Access of undefined property CDN
The reason I want to do this is to break up the logic of my application into multiple AS files and have minimal MXML files, probably only one.
Thanks - any help is much appreciated. Perhaps my OOD/OOP thinking is not correct here?
IT depends on your class architecture. For your code to work, the CDNClass instance must be defined and implemented inside your SyncConnectorManager.
Generally, you can always call down into components, but should never call up
One option is to pass the instance ofCDNClass to a variable inside SyncConnectorManager. Add this variable to your SyncConnectionManager class:
public var CDN:CDNClass = new CDNClass;
And at some point do this:
syncConnectorManagerInstance.CDN = CDN;
That way both classes will have access to the same CDN instance and can call methods on it.
Yes, your OOP thinking is not correct here. You should take in mind differences between classes and instances. This line declares a filed in a current class and initiates it with an instance:
public var CDN:CDNClass = new CDNClass;
So current instance of your MXML class (you can think about it as usual AS class with some other notation) has public field. To operate with CDN instance you need something from the following:
Read the value of CDN (as far as it is public) from the instance of your MXML class. You need some reference to it for that.
The instance of your MXML class can have a reference to the instance of SyncConnectorManager and SyncConnectorManager should have a way to inject the value of CDN there. Something like:
Your class:
package my.vp
{
import my.media.CDNClass;
public class SyncConnectorManager
{
private var CDN:CDNClass;
public function SyncConnectorManager(CDN:CDNClass)
{
this.CDN = CDN;
}
private function syncMessageReceived(p_evt:SyncSwfEvent):void
{
switch (p_evt.data.msgNm)
{
case "startStream" :
// Play a stream
CDN.parsePlayList(p_evt.data.msgVal);
break;
In your case SyncConnectorManager class hasn't CDN declared (the problem of the compiler error you mentioned) and instantiated (the problem of NPE even if you just declare field).
As the bottom line I can suggest you to follow ActionScript naming and coding conventions to talk other people and team members about your code :)

What is the best way to reuse functions in Flex MVC environment?

I am using a Cairngorm MVC architecture for my current project.
I have several commands which use the same type of function that returns a value. I would like to have this function in one place, and reuse it, rather than duplicate the code in each command. What is the best way to do this?
Create a static class or static method in one of your Cairngorm classes.
class MyStatic
{
public static function myFunction(value:String):String
{
return "Returning " + value;
}
}
Then where you want to use your function:
import MyStatic;
var str:String = MyStatic.myFunction("test");
Another option is to create a top level function (a la "trace"). Check out this post I wrote here.
You have lots of options here -- publicly defined functions in your model or controller, such as:
var mySharedFunction:Function = function():void
{
trace("foo");
}
... static methods on new or existing classes, etc. Best practice probably depends on what the function needs to do, though. Can you elaborate?
Create an abstract base class for your commands and add your function in the protected scope. If you need to reuse it anywhere else, refactor it into a public static method on a utility class.

Resources