Property Helpers and Macros

How Sharp Runtime expresses C#-shaped properties in native C++.

Compile-time convenience only

The helpers in SharpRuntime/Prop.hpp produce ordinary members and functions with predictable names. They do not create CLR properties, metadata, dynamic dispatch or automatic validation.

Declaration helpers

class Settings {
    DDATA(std::string, Label)
    DGETTER(int, Generation)
public:
    Settings(std::string label, int generation)
        : Label_(std::move(label)), Generation_(generation) {}
};

// Generated names include:
// const std::string& getLabelProperty() const;
// void setLabelProperty(const std::string& value);
// void setLabelProperty(std::string&& value);
// const int& getGenerationProperty() const;

Out-of-class definitions

IDATA(type, name, clazz), IGETTER(type, name, clazz) and IGETTERSTATIC(type, name, clazz, init) emit the corresponding definitions and, for the static form, initialization. Parameter order matters; older prose used incompatible signatures.

Type-name helpers

GETTYPENAME_HPP declares the virtual type-name accessor, while GETTYPENAME_CPP(Class, "Name") defines it using a stable static string. This is native identity plumbing, not full reflection.

Contributor guidance

• Follow the established pattern in the owning module rather than introducing a new property dialect.
• Keep validation and invariants visible in a method when a generated setter would be too permissive.
• Do not hide ownership transfer, allocation, blocking I/O or expensive computation behind property syntax.
• Prefer explicit accessors where a debugger, caller or generated documentation benefits from seeing the contract.