|
Boost : |
Subject: Re: [boost] [OT][RFC] standardized compile-time reflection
From: Matus Chochlik (chochlik_at_[hidden])
Date: 2012-04-23 12:53:53
On Mon, Apr 23, 2012 at 6:21 PM, Nathan Ridge <zeratul976_at_[hidden]> wrote:
>
>> > Â - Â I think you are neglecting the aspect on how the user can choose
>> > the types that are going to be reflected. I believe not all types
>> > should have their metadata generated, at least to save on compile time
>> > on large projects. The way I did it in my preprocessor was using a
>> > pragma directive but it was much simpler than Mirror since it was only
>> > intended for classes. There migth be other ways, though, but it should
>> > be made more explicit. If reflection makes it into the standard, there
>> > shouldn't be any tools to generate the metadata besides the compiler.
>> > For the standard library, I guess that including a given header or
>> > using reflect operator would bring in the metadata.
>>
>> 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.
>
> Since this is compile-time reflection, can't the compiler  generate reflection
> metadata "on demand" (that is, whenever it is being queried) rather than
> the user having to explicitly mark classes as reflected, without any loss of
> efficiency?
This is actually mentioned in the "Implementation hints" section, and yes
the compiler should generate meta-data lazily, but the problem is that
I would like to be able to traverse the members of a scope (namespace,
class, ...). You can imagine what would happen if such operation
instantiated for example ALL members of the boost or std namespace.
There are some ideas on how to solve this in the "Unresolved issues"
section but it is rather complicated:
- If we allow everything to be reflected the compile-times would
be horrible, even worse if a run-time reflection facility was based
on this meta-data so would be the resulting executable size.
- If we allow some sort of "white-listing" (i.e. specify what you want)
or "black-listing" (specify what you don't want) it would be inconvenient
for some use-cases.
I'm a fan of the "white-list" approach, but I would like to hear your opinions
on this issue.
BR,
Matus
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk