Implementing an interface declared in C# from C++/CLI - c++-cli

Say I have a C# interface called IMyInterface defined as follows:
// C# code
public interface IMyInterface
{
void Foo(string value);
string MyProperty { get; }
}
Assume I also have a C++/CLI class, MyConcreteClass, that implements this interface and whose header is declared as follows:
// C++/CLI header file
ref class MyConcreteClass : IMyInterface
{
public:
};
How does one implement the method Foo and the property MyProperty in the C++/CLI header?
My attempt results in the following compile error:
error C3766: 'MyConcreteClass' must
provide an implementation for the
interface method 'void
IMyInterface::Foo(System::String^
value)'

public ref class MyConcreteClass : public IMyInterface
{
public:
virtual void __clrcall Foo(String^ value) sealed;
virtual property String^ __clrcall MyProperty
{ String^ get() sealed { String::Empty; } }
};
Interfaces need to be defined as virtual. Also note the "public IMy.." after the class decleration, it's a slighly different syntax than C#.
If you can, seal the interface members to improve performance, the compiler will be able to bind these methods more tightly than a typical virtual members.
Hope that helps ;)
I did not compile it but looks good to me... Oh and also, defining your methods as __clrcall eliminates dangers of double thunk performance penalties.
edit
the correct syntax for a property is:
public ref class MyConcreteClass : public IMyInterface
{
public:
virtual property String^ MyProperty
{
String^ get() sealed { return String::Empty; };
void set( String^ s ) sealed { };
}
};
or, when putting the definition in the source file:
public ref class MyConcreteClass : public IMyInterface
{
public:
virtual property String^ MyProperty
{
String^ get() sealed;
void set( String^ s ) sealed;
}
};
String^ MyConcreteClass::MyProperty::get()
{
return String::Empty;
}
void MyConcreteClass::MyProperty::set( String^ )
{
//...
}

Related

Why does ninject's constructorScorer rate constructors which have unresolvable params?

Given some simple classes and interfaces...
public interface IClass1 { }; public class Class1 : IClass1 { }
public interface IClass2 { }; public class Class2 : IClass2 { }
... this injectable code ...
public class Class3
{
public Class3(IClass1 class1, IClass2 class2)
{
}
public Class3(IClass1 class1)
{
}
}
... and this setup ...
static void Main(string[] args)
{
var kernel = new StandardKernel();
kernel.Bind<IClass1>().To<Class1>();
var instance = kernel.Get<IClass1>();
}
Ninject will crash declaring that it can't find a binding for IClass2.
On the one had this is understandable, because it doesn't have a binding for IClass2.
However it does have access to a constructor which does not require such a binding.
After some investigation, we have discovered that both of these constructors have the same 'score' because they both have the same number of resolvable parameters.
Ninject appears to treat them as equally valid. It picks the constructor which requires an IClass2 parameter because it is listed first within the code.
So if I reverse the order of these constructors thus...
public class Class3
{
public Class3(IClass1 class1)
{
}
public Class3(IClass1 class1, IClass2 class2)
{
}
}
... everything works.
My question is therefore....
Why is the constructor (the one requiring an IClass2 parameter) ever considered a valid contender when it has unresolvable parameters?

__property to property

I am converting a project from /oldsyntax to /clr and have problems to convert my properties in the public __gc class Reader which has now become public ref class Reader
I have these properties (amongst others) in the .h file
__property void set_Xml(System::String *value);
__property System::String *get_Xml();
and then in the .cpp file I have
void Reader::set_Xml(System::String *value)
{
if(value->Chars[0] == '<'){
reader->put_xml(stlString(value).c_str());
}
else {
reader->put_xml_file(stlString(value).c_str());
}
}
System::String *Reader::get_Xml()
{
return gcString(reader->get_xml(), reader->state.is_utf8);
}
How do I rewrite this so that it can compile with /clr. I am using Visual Studio 2010 ?
The link posted in the comments has all the information on the new syntax for properties.
Old: Declare methods with a specific naming convention, decorate them with __property.
New: Declare a property block within your class, and have methods with an additional level of scope. (Note: I'm not sure if "additional level of scope" is the proper way to describe it, see below.)
For a property named Xml of type String, the syntax would be:
In the header file:
public ref class Reader
{
public:
property String^ Xml
{
String^ get();
void set(String^ value);
}
}
In the .cpp file:
String^ Reader::Xml::get()
{
return whatever;
}
void Reader::Xml::set(String^ value)
{
whatever = value;
}

Point to the function created in C# project from generic typename in C++/CLI

C++/CLI :
public interface class ITest{
public:
virtual void doSomething (){
}
}
public ref Base {
...........
...........
}
generic <typename T> where T : ITest
public ref Derived : Base{
public:
virtual void doNothing (){
}
}
public ref AnotherClass {
public:
generic<class T> where T : Base
static int justDoThis(){
//Problem!!
}
}
C# :
In C# there are two classes A and B. A inherits from the ITest and B inherits from Derived where A is used as the typename. Also, B has a private variable of type A. So, from main function AnotherClass.justDoThis<B>() is called where B is passed as the generic type.
"//Problem!!" Part :
Now I have to create a new instance of B in this section and also access the A which is private variable in B.
So if I take your paragraph of description of the C# code:
class A : ITest {}
class B : Derived<A>
{
private A someVariableOfTypeA;
}
class Program
{
void Main(string[] args)
{
AnotherClass.justDoThis<B>();
}
}
And the problem is that you want to do this:
public ref AnotherClass {
public:
generic<class T> where T : Base
static int justDoThis()
{
// Problem!!
Something^ actuallyB = gcnew Something();
A^ a = actuallyB->someVariableOfTypeA;
}
}
Issue #1: You can allow creation of new objects of the generic type by specifying gcnew as another generic constraint. (In C#, this would be new.) This will require that the generic type have a default (i.e., parameterless) constructor, which you can access with the normal gcnew.
generic<class T> where T : Base, gcnew
static int justDoThis()
{
T^ t = gcnew T();
}
Issue #2: You cannot access private variables within an object. That's what private means. If you want to give justDoThis access to the A object, then add an appropriate public method or property to Base. The method or property would return type ITest. You could also put that method/property on a new interface (perhaps named IHaveAnITestAccessorMethod), and add that as another generic constraint, and B satisfies all the constraints.
Note that it won't do any good to make the variable public on type B: justDoThis doesn't know about B, it only knows about T, which is a Base with a no parameter constructor.
Disclaimers:
I didn't check my syntax with a compiler.
Yes, you can do anything with reflection, but that's a bad design. Don't do that, fix your code the right way.

Different access modifiers for property getter/setter in C++/CLI

Is it possible to specify different access modifiers for property getter and setter using C++/CLI syntax? In C# one would write:
class Foo
{
public string Bar
{
get;
internal set;
}
}
This should do:
public:
property String^ Bar
{
String^ get();
private:
void set(String^);
}
(Edited following Hans Passant's comment).

Design: classes with same implementation but different method names

I have multiple classes that have similar implementation for different named methods:
class MyClassX
{
public int MyClassXIntMethod(){}
public string MyClassXStringMethod(){}
}
class MyClassY
{
public int MyClassYIntMethod(){}
public string MyClassYStringMethod(){}
}
the methods inside the classes have similar implementation but because the method's names are different (due to 3rd party constraints) i cannot use inheritance.
I'm looking for an elegant solution that would be better than implementing the same functionality over and over again.
The classic answer IMHO is use the adpater pattern for every 3rd party calling party.
Don't apply blindly but see if it is a good fit first.
class MyClassXAdapter
{
IMyInterface _myImpClass
public int MyClassXIntMethod(){ return _myImpClass.IntMethod()}
public string MyClassXStringMethod(){ return _myImpClass.StringMethod() }
}
class MyClassYAdapter
{
IMyInterface _myImpClass
public int MyClassYIntMethod(){ return _myImpClass.IntMethod()}
public string MyClassYStringMethod(){ _myImpClass.StringMethod() }
}
class MyClassImplementation :IMyInterface
{
public int IntMethod(){}
public string StringMethod(){}
}
And whats the problem in using composition?
class MyClassY
{
private MyClassX myclx;
public int MyClassYIntMethod()
{
return myclx.MyClassXIntMethod();
}
public string MyClassYStringMethod(){...Similarly here...}
}
Why not simply create a common super class, and let each "MyClass_" call that common function? You can have a different program signature and still reuse the same codes pieces. Without copy and paste the same code again.
class MyClassX extends MyClassGeneric
{
public int MyClassXIntMethod(){}
public string MyClassXStringMethod(){}
}
class MyClassY extends MyClassGeneric
{
public int MyClassYIntMethod(){ return MyClassIntMethod();}
public string MyClassYStringMethod(){return MyClassStringMethod();}
}
class MyClassGeneric
{
protected int MyClassIntMethod(){ /*...... logic .....*/ return 0; }
protected string MyClassStringMethod(){/*...... logic ....*/return "";}
}
Real world example.
Without "software patternitis". (I apply software patterns, very useful, but, I'm not adicted to them).
collections.hpp
#define pointer void*
class Collection {
protected:
VIRTUAL bool isEmpty();
VIRTUAL void Clear();
}
class ArrayBasedCollection: public Collection {
protected:
int internalInsertFirst(pointer Item);
int internalInsertLast(pointer Item);
pointer internalExtractFirst(int Index);
pointer internalExtractLast(int Index);
}
class Stack: public ArrayBasedCollection {
public:
OVERLOADED bool isEmpty();
OVERLOADED void Clear();
// calls protected "internalInsertFirt"
void Push(pointer Item);
// calls protected "internalExtractLast"
pointer Pop(pointer Item);
}
class Queue: public ArrayBasedCollection {
public:
OVERLOADED bool isEmpty();
OVERLOADED void Clear();
// calls protected "internalInsertFirt"
void Push(pointer Item);
// calls protected "internalExtractFirst"
pointer Pop(pointer Item);
}
Cheers.