__property/__declspec(property) in managed class?

  • Thread starter Thread starter Christian Kaiser
  • Start date Start date
C

Christian Kaiser

Hmmm. I just got the following compiler messages:

test_cpp.cpp

d:\src\logsolar\datasources\test_cpp\test_cpp.h(18) : error C3760: please
use __property keyword to declare property in managed 'test_cpp'

d:\src\logsolar\datasources\test_cpp\test_cpp.h(19) : error C3760: please
use __property keyword to declare property in managed 'test_cpp'

d:\src\logsolar\datasources\test_cpp\test_cpp.h(21) : error C4980:
'__property' : use of this keyword requires /clr:oldSyntax command line
option

(the first two lines had __declspec(), the third __property).



Well, what should I do now? I thought the __declspec metod would be the
newer one, but I cannot use it - and then it tells me I need to use the
'old' syntax.



Is there a better way to declare properties in a C++ class (interface
implementation!)?



Christian
 
OK, found 'property' (makes sense...)

BUT: I can use it in the header as described in several places, but when I
want to write the accessors into the CPP file, I get a problem...

..HPP:
virtual property String^ ID;



..CPP:

property String^ test_cpp::ID

{

String^ get()

{

return gcnew String("08/15");

}

}

??? does not work...



Any suggestions?

BTW: VStudio 2005 Beta...



Christian
 
Christian... This compiles:

// TestProperty.cpp : main project file.

#include "stdafx.h"

using namespace System;

namespace TestProperty {
interface class IId {
property String^ ID {String^ get();}
};
public ref class TestID : IId {
private:
String^ id;
public:
TestID() : id("me") {;}
property String^ ID {
virtual String^ get() {
return id;
}
}
};
}

int main(array<System::String ^> ^args)
{
TestProperty::TestID^ obj= gcnew TestProperty::TestID();
Console::WriteLine(obj->ID);
Console::ReadLine();
return 0;
}

Jeff
 
Jeff,


that's still in the class's definition. But I found out how...:

The class overrides the interface's property like:

virtual property String^ ID { String^ get(); };



and the definition is inside the C++ file:



String^ myclass::ID::get()

{

return gcnew String("08/15");

}



Yes, I "just" have to get used to a lot of "::"...



Christian
 
Sorry, next question:

how can I define a virtual abstract property in C++ that a derived class
must override? ;-)

Something like
virtual property String^ ModuleID; { String^ get(); } = 0;



Oooops....



My problem is, I want to create a base class in th plugin that overrides all
the interface functions, and which also uses virtual (abstract for this base
class) functions to do most of the work for the derived classes. Something
like:

public ref Base

: public IPluginAPI

{

public:

virtual property String^ ID { String^ get(); }

protected: // to be implemented by the derived objects!

virtual property String^ ModuleID { String^ get(); } <<<<< want this
abstract

}

and in the CPP file:

String^ Base::ID::get()

{

return gcnew String("Object type" + this->ModuleID); <<<<< calls the
derived class's ModuleID::get()

}



And how can I make the base class abstract, so that the Plugin Manager code
can not instantiate it?



Sorry, I hope this is understandable!



Christian
 
OK, sorry. As I said, it's "just" a getting used to the ideas of the new
C++...

It's:

<tadaaaaaa>

virtual property String^ ModuleID; { String^ get() = 0; }

and the override:

virtual property String^ ModuleID; { String^ get() override sealed; }

This works like a charm.

The base class must be declared abstract, and the plugin manager must only
look for ref classes that are not abstract.

Phew.


Thanks,

Christian
 
Hi Christian... You can use a base abstract class or just declare an
interface. An interface is the equivalent to a pure virtual class in native
C++ so that safe C++/cli supports single inheritance of implementation and
multiple inheritance of interface. Now be warned that the runtime pre pends
the assembly name to the fully qualified name so that
assembly1::mynamespace::myinterface is a different type than
assembly2::mynamesaped::myinterface. The common solution is to put the base
class or interface into a separate dll and reference that dll in both the
consumer and producer of the plug in.

Now a word of caution. The usual call is
sometype->isassignablefrom(sometype) but this FAILS on createinstance if
sometype is an interface. Here is my new approach in sorry c#

public static Program GetInstance(Type t1, Type t2) {
if ((typeof(I1).IsAssignableFrom(t1) && t1.IsClass)
&& (typeof(I2).IsAssignableFrom(t2) && t2.IsClass) ){
I1 pimplI1= (I1)Activator.CreateInstance(t1);
I2 pimplI2= (I2)Activator.CreateInstance(t2);
return new Program(pimplI1,pimplI2);
}
else {return null;}
}

This may also help:

http://www.geocities.com/Jeff_Louie/OOP/oop13.htm
 
Actually I like your solution better:

public static Program GetInstance(Type t1, Type t2) {
if ((typeof(I1).IsAssignableFrom(t1) && !t1.IsAbstract)
&& (typeof(I2).IsAssignableFrom(t2) && !t2.IsAbstract) ){
I1 pimplI1= (I1)Activator.CreateInstance(t1);
I2 pimplI2= (I2)Activator.CreateInstance(t2);
return new Program(pimplI1,pimplI2);
}
else {return null;}
}
 
Jeff,
Hi Christian... You can use a base abstract class or just declare an
interface. An interface is the equivalent to a pure virtual class in
native
C++ so that safe C++/cli supports single inheritance of implementation and
multiple inheritance of interface. Now be warned that the runtime pre
pends
the assembly name to the fully qualified name so that
assembly1::mynamespace::myinterface is a different type than
assembly2::mynamesaped::myinterface. The common solution is to put the
base
class or interface into a separate dll and reference that dll in both the
consumer and producer of the plug in.
Click to expand...

Yes, the interface already is in a different assembly.

Now a word of caution. The usual call is
sometype->isassignablefrom(sometype) but this FAILS on createinstance if
sometype is an interface.
Click to expand...

That's what I learned the hard way ;-)

I check

if (type.Attributes & TypeAttributes.Abstract) bail out;



Thank you!



Christian
 
Just read this after I answered your other post - this is a small tad nicer
than my solution.

Who the f*ck shall remember all the thousands of functions and properties?

Christian
 
Back
Top