Limitation on the number of w_property

[ToreHav]

The reason for us to test this implementation was initially to use define files such as config.i to macro generate the properties and also other functions.

Adding s sample application. The application compiles and runs from QT Creator using MSVC2017 (With heavy resource usage during compile).

Opening the project from Visual Studio and compiling it results in: C1060 Compiler is out of heap space

Removing one line from the config.i file, meaning one less W_PROPERTY has it compile.

TestVerdigris.zip

[ToreHav]

Thank you Oliver, and to report back, it now works from visual studio also. But not GCC as stated

[ogoffart]

Yeah, I broke GCC with that commit, but should be fixed now with more recent commits.

[ogoffart]

Did you get the chance to try out the latest commits?

There are still limitations on the number of property, but now it should be much higher. The problem in that case was the NOTIFY signal. Thankfully, you've only got one signal. Because the complexity is O(P * S) where P is the amount of properties in a class, and S the amount of signals in that class.

[ToreHav]

Partially, been busy the last three days with administrative stuff. Just started testing. Gets some strange behavior in the real application. For some reason it has problems with certain line numbers in the definition file used by X-macro... Just adding a comment in between helps... Seems like a problem with line endings... Will figure out:

[ToreHav]

Ahh, problem found, my errorous lines corresponds with line numbers in the header file with for instance W_SLOT W_SIGNAL or something....

LINE numbers in X-MACRO comes from the definition file..

[ToreHav]

I think this is a special case, but for my part, i will add possibility to inform that now, the W_PROPERTY is called from macro with external file's defines. Therefore we add a constant to the line numbers. Would you like me to check in a possible solution to the workaround for GCC or is it to "special" ?

[ToreHav]

Made a very simple workaround, where we define the OWN_LINESADDED in own implementation if X-Macro comes next:

From own implementation:

define OWN_LINESADDED 1

    #define THR_CONFIG_VALUE(path, value, type, name, defaultvalue) \
        W_PROPERTY(type , name MEMBER m_##name NOTIFY indexChanged)
    #include <config.i>
    #undef THR_CONFIG_VALUE
#undef OWN_LINESADDED

Then wobjectdefs:

if defined Q_CC_GNU && !defined Q_CC_CLANG

// workaround gcc bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69836)

define W_STATE_APPEND(STATE, ...) \

static constexpr int W_MACRO_CONCAT(W_WORKAROUND_, W_MACRO_CONCAT(OWN_LINESADDED, __LINE__)) = \
    decltype(STATE(w_internal::w_number<>{}, static_cast<W_ThisType**>(nullptr)))::size+1; \
friend constexpr auto STATE(w_internal::w_number<W_MACRO_CONCAT(W_WORKAROUND_, W_MACRO_CONCAT(OWN_LINESADDED, __LINE__))> w_counter, W_ThisType **w_this) \
    W_RETURN(w_internal::binary::tree_append(STATE(w_counter.prev(), w_this), __VA_ARGS__))

else