32

There is a study group in the C++ standardization committee to provide compile-time reflection in C++1z or after. I would like to know what is exactly the purpose and how powerful the expected tools will be?

For example will it be possible to name functions or classes using these tools?

struct A {int f() {return 42;}};
struct B {int (std::reflect<A>::member<0>::declname)() {return 43;}};
// equivalent to struct B {int f() {return 43;}};

If it would not be as powerful as this, what the typical use cases will be?

Rapptz
  • 20,807
  • 5
  • 72
  • 86
Vincent
  • 57,703
  • 61
  • 205
  • 388
  • 2
    It is still in very early stages. The best you can do is [look at what people are proposing](https://groups.google.com/a/isocpp.org/forum/#!forum/reflection). – Joseph Mansfield Mar 05 '14 at 18:46
  • @JosephMansfield I have already looked, but as I do not know the "history" of the study group, I am not sure to understand what is "their ultimate dream"... – Vincent Mar 05 '14 at 18:48
  • 3
    I don't think they know that yet either. – Joseph Mansfield Mar 05 '14 at 18:48
  • This will be extremely helpful in case of serialization. Another use case is a property editor that allows the user to edit the properties of objects. This reflection thingy would be very useful for me in many cases! – pasztorpisti Mar 05 '14 at 18:51
  • 3
    Someone voted down this question... wtf! It may not add anything in coding but I sure as hell didn't new about accessing an enumerator_list from an static_assert in compilation time. This is an awesome feature. The future looks bright – Claudiordgz Mar 05 '14 at 18:54
  • Those interested may want to [investigate the scribblings in the SG7 discussion group](https://groups.google.com/a/isocpp.org/forum/?fromgroups=&pli=1#!forum/reflection). – Casey Mar 05 '14 at 19:05
  • Looking at what they are proposing may not be ideal: in some cases, minimal support is proposed so people can write libraries using them so we can figure out the best way to standardize. If we do not do this, we coukd end up with messes like `vector`... It can take a surprisingly small set of primitives to allow really powerful libraries. – Yakk - Adam Nevraumont Mar 05 '14 at 22:13
  • Hmm this is not really c++1y, as c++1y refers to most likely c++14, if we're lucky. Shall we call it c++1z? ;-) – stefan Mar 06 '14 at 09:59
  • @Claudiordgz: Good feature != good question – Lightness Races in Orbit Aug 21 '14 at 21:58
  • 7
    This question appears to be off-topic because it is about speculation. It belongs on the [std-proposals](https://groups.google.com/a/isocpp.org/forum/#!forum/std-proposals) forum. – R. Martinho Fernandes Aug 21 '14 at 22:10
  • @LightnessRacesinOrbit then close it or add something of value to it. I'd rather see people discussing the new features in C++ and find better ways to building things. Your negative comment is more useless than homework questions. – Claudiordgz Aug 22 '14 at 13:51

1 Answers1

32

Reflection use cases are outlined in N3814:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3814.html

The general view is that we will do it as an extension of the Type Traits library as exemplified by N3815:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3815.html

There are two parts to reflection. The first is introspection. Taking an entity and querying constant values about it. The second is reification, which is the opposite - using values to create new entities.

For introspection - you can expect additional traits that will allow you to enumerate and get the names of class members, base classes, enumerators, function paramaters and so forth at compile-time. From there you can use them for things like serialization, memberwise operations, static checks and various other things.

Additionally later we are looking at reification, which would involve creating new entities from constant values with more expressiveness than you can with a template. So perhaps you might fill out a std::class_specifier s struct and then call make_type_from_spec(s) to create the type.

The introspection approach has more consensus at the moment, the reification side is further off.

Andrew Tomazos
  • 66,139
  • 40
  • 186
  • 319
  • I am not sure of what you call "reification". Is my little example a case of reification (reinterpreting a compile-time string as the name of a function?) – Vincent Mar 05 '14 at 18:58
  • Compilation time is just as valuable time as runtime, and has potential to be even more valuable. Boost Static Assert has helped me a lot in the past but Concept check on the other hand has not been easy to digest and implement. This features you list look like a great value added to c++ – Claudiordgz Mar 05 '14 at 18:58
  • @Vincent: Yes, creating a new entity with a name that is a compile-time string, and not an identifier token, I consider part of reification. I think we will be able to read an identifier (like in N3815) before we can write one. – Andrew Tomazos Mar 05 '14 at 19:00
  • Ok, great I see a bright future for library development using introspection+reification+template metaprogramming... – Vincent Mar 05 '14 at 19:03
  • are you planning something like for_each_member{/*smthing8/}? or for a struct that has members a b c d e f to be able to write for_member(a,b,f) {/*smthing*/} – NoSenseEtAl Mar 05 '14 at 22:42
  • would make serialization 17x more easier :) – NoSenseEtAl Mar 05 '14 at 22:52
  • 1
    @NoSenseEtAl: Yes. If you look at the example code in N3815 you can see how to get from the given traits to a for loop over the enumerators of an enumeration type. I am currently working on similar traits for class members so you will be able to loop over class members. Of course, class members have heterogeneous types so the "loop" will be like looping over the elements of a `std::tuple` - it can't be a for loop as such - but you will be able to get the same effect of doing something for each class member. – Andrew Tomazos Mar 05 '14 at 23:15
  • basically what I would like is to have serialization trivially implementable in a way that it flows bottom up(language/std knows how to serialize built in types and all other types are composition of built in ones) ... but my wishlist aside as a noob i can say enum code looks ok but it has a libraryish feel, i would prefer language support for it... though I guess cpp grammar is evil enough already :) – NoSenseEtAl Mar 06 '14 at 00:02
  • @NoSenseEtAI: I don't completely understand what you mean - but using the primitives someone will be able to write-once a serialization library that can take a value of an arbitrary type T and encode it to a bit string in some format and visa versa. This can be achieved by enumerating the subobjects recursively, and taking appropriate action based on their type, name and a pointer-to-member. – Andrew Tomazos Mar 06 '14 at 00:30
  • Are we talking about "member variables" as well with the introspection side, right? And dealing with all the scopes beforehand? – Marco A. Mar 25 '14 at 16:07