سؤال

The following code is illegal ( Visual Studio 2012 Windows Phone( Creating a windows phone direct3d app ) )

a non-value type cannot have any public data members 'posX'

Header

ref class Placement sealed
{
public:
    Placement(
        float rotX, 
        float rotY, 
        float rotZ, 
        float posX, 
        float posY, 
        float posZ
    );
    float rotX, rotY, rotZ, posX, posY, posZ;
};

Cpp

Placement::Placement(
        float rotX, 
        float rotY, 
        float rotZ, 
        float posX, 
        float posY, 
        float posZ
    )
    :   posX( posX ),
        posY( posY ),
        posZ( posZ )
{
    this->rotX = static_cast<float>(rotX);
    this->rotY = static_cast<float>(rotY);
    this->rotZ = static_cast<float>(rotZ);
}

Why and how do I have to set the properties? I'm used to normal C++ not C++ CX( I think it's called that right? )... Do I have to create methods that serve the properties?

*This problem stemmed from me originally trying to create a normal class and creating a pointer to it, only to be complained to about the fact I cannot use * rather I have to use ^ which means I have to create a ref class instead... I don't really understand why?*

Is it something to do with WinRT or more specifically ARM processors?

هل كانت مفيدة؟

المحلول 2

This is something specific to WinRT and the C++/CX extensions specifically. C++/CX does not allow ref classes to contain public fields. You need to replace your public fields with public properties.

 ref class Placement sealed
{
public:
    Placement(
        float rotX, 
        float rotY, 
        float rotZ, 
        float posX, 
        float posY, 
        float posZ
    );
    property float rotX;
    property float rotY;
    property float rotZ;
    property float posX;
    property float posY;
    property float posZ;
};

Properties have getter and setter functions generated automatically for them by the compiler.

نصائح أخرى

Is is a restriction in COM, the underpinning of WinRT and the C++/CX language extension. COM only permits pure virtual methods in interface declarations. A property is fine, that's emulated as a getter and a setter method. Not a field.

This kind of restriction is not artificial, it strongly removes implementation details. Very important when you need to support arbitrary languages and get them to talk to each other or to an API. A field has a very nasty implementation detail, its location is very implementation dependent. Alignment and structure packing rules are important to determine that location and cannot be guaranteed to be compatible between language runtimes.

Using a property is the simple workaround.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top