Subject: Re: [boost] [OT][RFC] standardized compile-time reflection
From: Matus Chochlik (chochlik_at_[hidden])
Date: 2012-04-24 11:31:17
> [MC] Personally I don't have anything against "mirror" I just didn't want
> to put any shameless plugs there :) since Mirror is also the name of the
> [JN] I guess the proposal should mention the name it thinks is more
> appropriate. Your library is one of many using that name for that purpose,
> so no shameless plugs ;) I guess that "mirror" is the proper name since the
> objects don't reflect themselves, but just my 2 cts.
It is true that 'mirror' is the usual term for "stratified" objects/functions
providing meta-data for decoupled base-level objects. I'll update
the paper and include some explanation.
> [MC] [About metadata generation] Actually, this is one of my primary
> concerns. I also think that the way
> to go is not to reflect everything automatically, but to let the user
> to (somehow) choose what should be reflected. But i think that
> the process of "marking" namespaces, classes, etc. that should
> be reflected, should be decoupled from the declaration of the namespace,
> class, etc. because that would allow greater flexibility and also
> would allow to cherry-pick, what parts of 3rd-party libraries should be
> reflected in concrete applications based on their needs.
> Â [JN] I think there's a problem in this. If I summarize, the reflection
> info is (should) be stored in an immutable global object. That means that
> it must (should) be declared in a CPP, not a header, like other global
> (/static) variables. If it is, then the compiler must make sure that is
> present only once accross various libraries. It may be possible, but I am
> not sure. If the declaration of the metadata is not linked to the
> declaration of the object, then the compiler has no way to know whether
> that info exists and will suppose it does. If it doesn't you'll get a link
> error. On the other hand if you force the declaration of the metadata at
> the same time as the type, then the compiler knows whether the metadata
> exists or not and will result in an earlier error that is probably easier
> to analyze.
> Now, if the metadata is only type information it *may* be Â possible to
> generate it at will anywhere without linking problem.
I would like the meta-objects to be completely "static" and to provide
the meta-information only through types and compile-time constants and
be (re-)generated for every translation unit and not shared implicitly
between translation units to avoid ODR violations.
The libraries based on top of the meta-object provided by the compiler
(mostly those implementing run-time reflection) would have to take
care of this (avoid ODR violations) themselves.
> I guess the proposal should explicit more how all that should work and
> probably requires some compiler expertise I am far from having.
OK, I'll add this too, thanks.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk