You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PREFACE:
I raised issue #51 earlier about the inability to inherit the source classes's base classes into a metaclass defined using the new format (which requires void constexpr function templates).
This is a semantic issue rather than a simple bug, of course: even if we were to allow the constexpr function to be followed by a colon and base list a la the format of a constructor's initializer list, still we would need some special command to generate the list of bases along with their qualifiers -- and how might we handle transforming the base tuple in every conceivable way the user might need?
After considering it, I think the ideal solution (barring significant technical hurdles) would be to use standard class templates, rather than the constexpr function templates or the $class format, to express metaclasses; that way we can handle base specification/transformation using reflection + standard template meta programming tricks, while doing the for... loops as usual in the body of the class template. The need for new semantics would be minimized, making it an easy sell to the standards people.
PROBLEM:
However, the mechanism for __generating a source class's functions within a class template doesn't work right now whenever the source class has a virtual function: we can't __generate such functions; e.g. the example below works as is but uncommenting the "__generate f;" line will cause an error.
EXAMPLE:
template<typename SRC>
struct MyClassTemplateMetaclass // : public some_inheritance_handler<$SRC.bases(),...>
{
constexpr {
for... (auto v : $SRC.variables()) {
__generate v; //Always works
}
for... (auto f : $SRC.functions()) {
//__generate f; //<--IF YOU UNCOMMENT THIS, YOU GET AN ERROR for any SRC w/virtual fcns
}
}
};
struct MySourceWVirtualFcns {
int myvar;
virtual void myfcn() {} //If you remove virtual keyword here, no more error on __generate f above.
};
int main() {
MyClassTemplateMetaclass < MySourceWVirtualFcns > m;
m.myvar;
//m.myfcn();
}
To be sure, this problem with virtual functions does not crop up when expressing metaclasses via void constexpr functions; but to repeat issue #51 the problem there is there is no way to inherit the SRC bases:
template<typename SRC>
void constexpr MyConstexprFcnMetaclass_NoWayToInheritBases(SRC source) {
for... (auto v : source.variables()) {
__generate v;
}
for... (auto f : source.functions()) {
__generate f; //Works
}
}
struct ThisBaseWillBeIgnored {
int missingbasevariable = 2;
};
struct(MyConstexprFcnMetaclass_NoWayToInheritBases) MyMetaclassInstance
: public ThisBaseWillBeIgnored
{
int myvar;
virtual void myfcn() {}
};
int main() {
MyMetaclassInstance m;
m.myvar;
m.myfcn();
//m.missingbasevariable; //ERROR IF UNCOMMENTED
}
Would be great to get this solved; reflection + the full ability to use __generate/__inject/etc. in the body of class templates is all I think we need for metaclasses, the rest is semantic sugar atop that. (E.g. we wouldn't need "is" and "as"; "is" could be handled through SFINAE trickery, and "as" would be a simple matter of instatiating the metaclass template with the source class (which itself would remain distinct and unchanging).
Thanks for your efforts, please let me know if you would like any help.
The text was updated successfully, but these errors were encountered:
davrec72
changed the title
Error when __generating virtual functions in class template
Error when __generating virtual functions in class template meta class
Nov 26, 2018
davrec72
changed the title
Error when __generating virtual functions in class template meta class
Error when __generating virtual functions in class template metaclass
Nov 26, 2018
PREFACE:
I raised issue #51 earlier about the inability to inherit the source classes's base classes into a metaclass defined using the new format (which requires void constexpr function templates).
This is a semantic issue rather than a simple bug, of course: even if we were to allow the constexpr function to be followed by a colon and base list a la the format of a constructor's initializer list, still we would need some special command to generate the list of bases along with their qualifiers -- and how might we handle transforming the base tuple in every conceivable way the user might need?
After considering it, I think the ideal solution (barring significant technical hurdles) would be to use standard class templates, rather than the constexpr function templates or the $class format, to express metaclasses; that way we can handle base specification/transformation using reflection + standard template meta programming tricks, while doing the for... loops as usual in the body of the class template. The need for new semantics would be minimized, making it an easy sell to the standards people.
PROBLEM:
However, the mechanism for __generating a source class's functions within a class template doesn't work right now whenever the source class has a virtual function: we can't __generate such functions; e.g. the example below works as is but uncommenting the "__generate f;" line will cause an error.
EXAMPLE:
To be sure, this problem with virtual functions does not crop up when expressing metaclasses via void constexpr functions; but to repeat issue #51 the problem there is there is no way to inherit the SRC bases:
Would be great to get this solved; reflection + the full ability to use __generate/__inject/etc. in the body of class templates is all I think we need for metaclasses, the rest is semantic sugar atop that. (E.g. we wouldn't need "is" and "as"; "is" could be handled through SFINAE trickery, and "as" would be a simple matter of instatiating the metaclass template with the source class (which itself would remain distinct and unchanging).
Thanks for your efforts, please let me know if you would like any help.
The text was updated successfully, but these errors were encountered: