> P3132 aims to make it easier to do tooling through user-defined
> attributes and has a number of additional upsides.
>
> Waypoints m_waypoints; PROPERTY(INIT() RUNTIMEEDITABLE)
>
> In addition to making member variables visible and editable in the
> editor with the PROPERTY tag, we also use tags such as REGISTERCLASS
> on classes and enums that need to participate in our custom RTTI
> implementation. Note that those tags can sometimes double as macros,
> but are usually defined to nothing:
> #define PROPERTY
> What gives meaning to the tags is a custom tool - let’s call it the
> Property Parser - which is run before compilation. It generates a
> matching .property.cpp file for each .cpp file in our project.

UE, many game engines, and Qt each feature a Property Parser, MOC or
similar pre-compiler to extend C++ RTTI. Such non-standard C++ adjacent
proprietary pre-compilers were created as a hack to overcome C++ RTTI
limitations. Is this proof there's a hole in the C++ language, that so
many proprietary implementations exist to provide a missing C++ language
feature?

Instead of making external pre-compiler code generator tools better
supported by adding [[attributes]], would it be better to consider
making C++ more complete, so mutually incompatible pre-compiler tools
are unnecessary?

I'm imagining a new keyword 'property' that does the magic that is
presently handled by various proprietary pre-compilers.

> //TODO Qt GUI framework for its signals and slots?

Yes, Qt MOC replacement too, please.

 From Qt documentation:
>> What is a MOC in Qt?
>> The Meta-Object Compiler, moc , is the program that handles Qt's
>> C++ extensions. The moc tool reads a C++ header file. If it finds
>> one or more class declarations that contain the Q_OBJECT macro,
>> it produces a C++ source file containing the meta-object code
>> for those classes.

FYI, the Q_OBJECT macro:

#define Q_OBJECT \
public: \
     QT_WARNING_PUSH \
     Q_OBJECT_NO_OVERRIDE_WARNING \
     static const QMetaObject staticMetaObject; \
     virtual const QMetaObject *metaObject() const; \
     virtual void *qt_metacast(const char *); \
     virtual int qt_metacall(QMetaObject::Call, int, void **); \
     QT_TR_FUNCTIONS \
private: \
     Q_OBJECT_NO_ATTRIBUTES_WARNING \
     Q_DECL_HIDDEN_STATIC_METACALL static void
qt_static_metacall(QObject *, QMetaObject::Call, int, void **); \
     QT_WARNING_POP \
     struct QPrivateSignal {}; \
     QT_ANNOTATE_CLASS(qt_qobject, "")

If I understand what this is doing, C++ calls in any thread are queued
and forwarded for processing by the GUI thread so UI interactivity is
smooth.

In UE, the purpose of a pre-compiler is to connect C++ methods and data
to the Blueprints programming environment, so Blueprints can show C++
objects as i/o units in a code-free connect-the-noodles flowchart UI.

Property access could also be a way for C++ code to support a DLL API
without the macro import/export hack we use now.

Thoughts on a 'property' keyword to replace above hacks?

Robin

--
Robin Rowe
* Chairman ISO C++ SG14 Low Latency Financial Systems Subcommittee