Hi everyone,
I intend to propose a small reflection-like utility for the next C++
standard (which would be something like C++16?). My proposal is still
in progress, but I would like to collect input from you as early as it
is possible. I would appreciate your feedback.
Here is the current description.
https://docs.google.com/document/pub?id=18Jr3UfvQvbWh2pXQ4Wm4e8-PYdV2aTXpPtNNOicgGjw

Regards,
&rzej


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 7/22/2011 9:07 AM, Andrzej Krzemie  ski wrote:
>
> Hi everyone,
> I intend to propose a small reflection-like utility for the next C++
> standard (which would be something like C++16?). My proposal is still
> in progress, but I would like to collect input from you as early as it
> is possible. I would appreciate your feedback.
> Here is the current description.
> https://docs.google.com/document/pub?id=18Jr3UfvQvbWh2pXQ4Wm4e8-PYdV2aTXpPtNNOicgGjw
>
> Regards,
> &rzej
>


skim... admittedly I don't entirely follow.


why not something that can be implemented primarily as library
functionality?

struct Foo
{
 int x;
 int y;

 void fooMethod();
};

using meta;

Foo *obj;
mtStruct *ts;
mtField *tf;
mtType *tt;
mtMethod *tm;
int i;

ts=mtGetStruct("Foo");
tf=ts->getField("x");

obj=(Foo *)ts->newInstance();

i=tf->ptrGetValuei(obj); //get value for an object field

i=tf->offsetOf(); //get field offset
tt=tf->getType();

if(tt->typeIs(mtParseType("int"))) //type-check
{
 ...
}

tm=ts->getMethod("fooMethod", "()");
tm->ptrInvokev(obj);

...


in my projects, I have a system which serves a vaguely similar role, but
it is for plain C and it works a bit differently (its APIs are notably
different, ...).


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Am 22.07.2011 18:07, schrieb Andrzej Krzemie  ski:
>
> Hi everyone,
> I intend to propose a small reflection-like utility for the next C++
> standard (which would be something like C++16?). My proposal is still
> in progress, but I would like to collect input from you as early as it
> is possible. I would appreciate your feedback.
> Here is the current description.
> https://docs.google.com/document/pub?id=18Jr3UfvQvbWh2pXQ4Wm4e8-PYdV2aTXpPtNNOicgGjw

I like your proposal. But there is one subtlety which might make
std::tuple inappropriate for the API: std::tuple enforces a copy
constructor of the form

tuple(const tuple&) = default;

This means that this could cause problems, if at least one member or
base class type M has a mutating copy constructor of the form

M::M(M&);

I'm mentioning this, because this reflection-utility should IMO be
useful for all valid C++ types. Of-course one could consider this as a
library problem and in fact recently a new issue has been opened for
std::pair in this regard, because the C++03 std::pair was able to host
types with a source-mutating copy constructor/assignment operator.
Nonetheless, this is a library issue currently and this should better
not have impact on something like this very core-language near utility.
I would hope that the tuple/pair copy problem can be solved soon, but I
would like to emphasize that we have this problem at the moment.

HTH & Greetings from Bremen,

Daniel Kr  gler




--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Andrzej Krzemie  ski wrote:
> Hi everyone,
> I intend to propose a small reflection-like utility for the next C++
> standard (which would be something like C++16?). My proposal is still
> in progress, but I would like to collect input from you as early as it
> is possible. I would appreciate your feedback.
> Here is the current description.
> https://docs.google.com/document/pub?id=18Jr3UfvQvbWh2pXQ4Wm4e8-PYdV2aTXpPtNNOicgGjw

Have you seen
http://www.boost.org/doc/libs/1_47_0/libs/fusion/doc/html/index.html?

There are also additional reflection library(ies) proposed for boost.

Jeff


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

> > Here is the current description.
> >https://docs.google.com/document/pub?id=18Jr3UfvQvbWh2pXQ4Wm4e8-PYdV2...
>
> > Regards,
> > &rzej
>
> skim... admittedly I don't entirely follow.
>
> why not something that can be implemented primarily as library
> functionality?
>
> struct Foo
> {
>         int x;
>         int y;
>
>         void fooMethod();
>
> };
>
> using meta;
>
> Foo *obj;
> mtStruct *ts;
> mtField *tf;
> mtType *tt;
> mtMethod *tm;
> int i;
>
> ts=mtGetStruct("Foo");
> tf=ts->getField("x");
>
> obj=(Foo *)ts->newInstance();
>
> i=tf->ptrGetValuei(obj);     //get value for an object field
>
> i=tf->offsetOf();    //get field offset
> tt=tf->getType();
>
> if(tt->typeIs(mtParseType("int"))) //type-check
> {
>         ...
>
> }
>
> tm=ts->getMethod("fooMethod", "()");
> tm->ptrInvokev(obj);
>
> ...
>
> in my projects, I have a system which serves a vaguely similar role, but
> it is for plain C and it works a bit differently (its APIs are notably
> different, ...).

I guess, there are many ways to implement "reflection" in C++. Yours
appears to address a more wide spectrum of applications. If I
understood correctly your example the "meta" functions are evaluated
at runtime, ant they require that apart from the program code there
should exist a "database" containing information about every struct/
class we define. Am I correct?
In contrast, in my proposal, I tried to implement the solution in "the
spirit of C++" (as I understand it), that is, any "reflection"
information is only available at compile-time, and once the program is
compiled, no runtime performance or program size is affected by the
"reflection".

Regards,
&rzej


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 7/30/2011 12:13 PM, Andrzej Krzemie  ski wrote:
>
>
>>> Here is the current description.
>>> https://docs.google.com/document/pub?id=18Jr3UfvQvbWh2pXQ4Wm4e8-PYdV2...
>>
>>> Regards,
>>> &rzej
>>
>> skim... admittedly I don't entirely follow.
>>
>> why not something that can be implemented primarily as library
>> functionality?
>>
>> struct Foo
>> {
>>          int x;
>>          int y;
>>
>>          void fooMethod();
>>
>> };
>>
>> using meta;
>>
>> Foo *obj;
>> mtStruct *ts;
>> mtField *tf;
>> mtType *tt;
>> mtMethod *tm;
>> int i;
>>
>> ts=mtGetStruct("Foo");
>> tf=ts->getField("x");
>>
>> obj=(Foo *)ts->newInstance();
>>
>> i=tf->ptrGetValuei(obj);     //get value for an object field
>>
>> i=tf->offsetOf();    //get field offset
>> tt=tf->getType();
>>
>> if(tt->typeIs(mtParseType("int"))) //type-check
>> {
>>          ...
>>
>> }
>>
>> tm=ts->getMethod("fooMethod", "()");
>> tm->ptrInvokev(obj);
>>
>> ...
>>
>> in my projects, I have a system which serves a vaguely similar role, but
>> it is for plain C and it works a bit differently (its APIs are notably
>> different, ...).
>
> I guess, there are many ways to implement "reflection" in C++. Yours
> appears to address a more wide spectrum of applications. If I
> understood correctly your example the "meta" functions are evaluated
> at runtime, ant they require that apart from the program code there
> should exist a "database" containing information about every struct/
> class we define. Am I correct?

yep. this is what I would generally understand as being reflection.

in my implementation (in my projects known as "DYLL"), there is a
database, which is generally propagated at build-time by tools which
process header files and similar, and spit out a database containing the
various things it has seen.

things it constains information about:
structs and unions (it would support classes, if it supported C++);
functions;
top-level global variables;
preprocessor defines and macros;
...

its main use at the moment is for helping glue between native code and
my scripting language.


potentially, similar could be done by making use of debugging
information, but there are drawbacks:
accessing debug-info depends a fair amount on the compiler and OS;
debugging information will often contain a good amount if information
which is either not needed, or would expose internal details of the
program or aide in decompilation;
...


> In contrast, in my proposal, I tried to implement the solution in "the
> spirit of C++" (as I understand it), that is, any "reflection"
> information is only available at compile-time, and once the program is
> compiled, no runtime performance or program size is affected by the
> "reflection".
>

except that this is not generally what I would understand as being
reflection, but rather more a a type of metaprogramming feature.


granted, both types of options could make sense.


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jul 30, 9:16 pm, Jeff Flinn<TriumphSprint2...@hotmail.com>  wrote:
>  Andrzej Krzemie  ski wrote:
>  >  Hi everyone,
>  >  I intend to propose a small reflection-like utility for the next C++
>  >  standard (which would be something like C++16?). My proposal is still
>  >  in progress, but I would like to collect input from you as early as it
>  >  is possible. I would appreciate your feedback.
>  >  Here is the current description.
>  >https://docs.google.com/document/pub?id=18Jr3UfvQvbWh2pXQ4Wm4e8-PYdV2...
>
>  Have you seenhttp://www.boost.org/doc/libs/1_47_0/libs/fusion/doc/html/index.html?
>
>  There are also additional reflection library(ies) proposed for boost.

Thank you for the link. I do know Boost.Fusion. I think I even
mentioned it in the proposal. I am aware of the following two Boost-
related libraries implementing reflection-like functionality.
http://bytemaster.github.com/dev/modules.html
http://boost-extension.redshoelace.com/docs/boost/extension/index.html
If there are any other I would be happy to learn what they are. I was
amazed to see how far you can go with reflection in Boost.RPC.
All reflection-like libraries take one of the two approaches: either
you need to perform some custom build step before the compilation that
will parse the source code and collect the information about your
classes; or you need to add a redundant "boiler-plate" code to teach
the reflection library how your class looks.
While the first approach might be the "right" one (whatever that would
mean) it requires of users to learn another tool that is not part of C+
+ compiler itself, but it processes C++ code, and its output is used
back in C++. The second approach has one significant drawback: you are
forced to repeat yourself - to specify twice the same thing that is
obvious to compiler the first time:

namespace demo {
    struct employee {
        std::string name;
        int age;
    };
}

BOOST_FUSION_ADAPT_STRUCT(
    demo::employee,   // REPETITION!
    (std::string, name) // REPETITION!
    (int, age)               // REPETITION!
)

Or you are forced to use macros with custom syntax rather than normal
structs:

BOOST_FUSION_DEFINE_STRUCT(
     (demo), employee,
     (std::string, name)
     (int, age))

But how do you convince normal (not using metaprogramming) programmers
that they should define their types like the above rather than
writing:

namespace demo {
    struct employee {
        std::string name;
        int age;
    };
}

Plus, fusion adaption macros will only work for structs: not for
private members without public access via accessors. Fusion does a
great job, but being a library there are limits to what it can do.
Also, for tools that can access private class members, there is a
security problem: encapsulation is violated.

I tried to come up with a solution to the above issues. IMO it cannot
be done without slight language support. I treat it as a compliment to
fusion library. In fact, I first came up with this idea when I was
using Boost.Spirit library and I was annoyed that I had to use macro
BOOST_FUSION_ADAPT_STRUCT to redefine my struct the second time (well,
"redefine the first time"). Indeed, I incorrectly used name
"reflection" in my proposal, because I only focus on accessing "all
sub-objects" (a couple of different definitions of "sub-object"),
because this is the thing that I found is often missing, and have good
use case for. I tied to re-use the same compiler magic that was
already standardized for type traits.
Now I can see that I did not describe my motivation well enough.

Regards,
&rzej


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]