On Jan 15, 2022, at 3:00 PM, Matus Chochlik via SG7 <sg7@lists.isocpp.org> wrote:



On Sat, Jan 15, 2022 at 8:56 PM Matus Chochlik <chochlik@gmail.com> wrote:
Hi David,

On Sat, Jan 15, 2022 at 8:45 PM David Rector via SG7 <sg7@lists.isocpp.org> wrote:

Now suppose a user decides they want to interface with reflection in an object-oriented style:
```
template<auto R>
struct DeclWrapper {
  auto nextDecl() { return DeclWrapper <decltype(std::meta::get_next_decl(R))>{}; }
  auto prevDecl() {…}
  auto getParent() { … }
  …
};

#include … // lots of stuff, big translation unit

int foo;
constexpr auto foorefl = DeclWrapper <decltype(^foo)>()>();
```

What happens when `foorefl` is instantiated?  

First each member of DeclWrapper<decltype(^foo)> must be instantiated, which means we have to instantiate each return type, each of which is a DeclWrapper, which itself has to be instantiated, …

The chain reaction results in instantiations of DeclWrappers for *every single declaration in the translation unit*.

for debugging, in order to have a way to easily force the extraction of all metadata and also to see the performance of such "chain reaction".
To clarify a little more, in my implementation you will not get the reflection of everything in the TU, the cascade is intentionally stopped to prevent really excessive compile-times. 

That’s cool, I’m very curious how you stopped the chain reaction, is this a change you made in the compiler, or via cleverness in the library code?  I can’t quite figure it out from the links.  It would be very nice to offer a solution that users could deploy when constructing their own reflection class hierarchies (and with improvements in constant evaluation performance this desire will surely emerge); I imagine a class attribute, call it something like __attribute__((lazy_instantiate_member_return_types)), would do it.

It would be interesting to see the precise performance hit of a template-instantiation-based approach, relative to the value-based-approach, when this chain-reaction-instantiation issue is guaranteed not to be a factor.   Memory usage would still be higher, but just how much would speed suffer, etc. Perhaps the decision to do meta::info and the decision to abjure an object-oriented reflection interface were made simultaneously, possibly giving a distorted impression of the performance gain of the meta::info approach?

As I've said previously it would be best if the language could permit treating templates and classes sufficiently similarly (e.g., allowing one to specify a template name instead of auto as a return type of a dependent function) that template instantiations vs. values could be a compiler implementation issue, rather than a language interface issue.

-- 
SG7 mailing list
SG7@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg7