Boris Bralo wrote:
> Hi all,
> What is main reason for not introducing reflection in c++?
> When I think about possible implementation I don't see too much
> overhead over RTTI. I know that this is debatable, but in most cases,
> when RTTI overhead is acceptable (i.e. "normal" , non-embedded
> scenarios ), a little bit larger memory footprint for reflection data
> is also acceptable.
> I don't know if it's a popular belief, but I see reflection as a main
> point in favor of java and c#.
> Am I missing something?

I support reflection in C++ also and see RTTI as a means of doing it.
But the memory overhead would be far greater than you have assumed since
the classes needed to do full reflection in C++ would be much greater
than what typeid gives one now.

My understanding that reflection in C++ is being worked on by the C++
standards committee in the form of something called XVT. However my
understanding, from inquiring about this, is that this is being done
strictly within the comittee and not with any outside contributions. I
just wish them good luck and hope they succeed.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <bAonf.3661$Dd2.2562@newsread3.news.atl.earthlink.net>,
Edward Diener No Spam <eldiener_no_spam_here@earthlink.net> writes
>My understanding that reflection in C++ is being worked on by the C++
>standards committee in the form of something called XVT. However my
>understanding, from inquiring about this, is that this is being done
>strictly within the comittee and not with any outside contributions. I
>just wish them good luck and hope they succeed.
? As the Committees are composed of people who volunteer to do the work,
I have no idea what you mean. If you have something to contribute, do
so.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:
> In article <bAonf.3661$Dd2.2562@newsread3.news.atl.earthlink.net>,
> Edward Diener No Spam <eldiener_no_spam_here@earthlink.net> writes
>
>> My understanding that reflection in C++ is being worked on by the C++
>> standards committee in the form of something called XVT. However my
>> understanding, from inquiring about this, is that this is being done
>> strictly within the comittee and not with any outside contributions. I
>> just wish them good luck and hope they succeed.
>
> ? As the Committees are composed of people who volunteer to do the work,
> I have no idea what you mean. If you have something to contribute, do so.

What I meant is that this was being done only by members of the C++
standards committee. I thought what I meant was obvious from the mention
above.

Since I am not a member of the C++ standard committee and could not be
at least for practical reasons, and since I offered to contribute and
was told that it was not wanted, I made the assumption that this work
was strictly being done only by C++ standards commitee members.

I would be glad to contribute via e-mail and the Internet if I could in
any work being done regarding reflection in C++. But if it required me
to be a member of the C++ standards committee, go to meetings, and
physically meet with others I do not have the time or practical means to
do so.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

===================================== MODERATOR'S COMMENT:
 Please do quote appropriate context when replying to messages.


===================================== END OF MODERATOR'S COMMENT
Since reflection data is per class, the overhead should not be so big.
I think that main problem is how to play it nice with other parts of
standard (inlining, templates etc.).

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Boris Bralo wrote:

> Since reflection data is per class, the overhead should not be so big.
> I think that main problem is how to play it nice with other parts of
> standard (inlining, templates etc.).

Reflection need not be related to classes only so your statement that
"reflection data is per class" is not necessarily true at all. There is
no reason not to generate reflection data for global objects which exist
outside of classes.

Ideally reflection data is generated for a particular final module, an
executable or a shared library, so that the logistics of distributing
the module need not involve distributing the reflection data separately.
Of course it will probably meed to be stored originally in an object
file, on a per compilation unit basis, before it could be combined into
a final module. So I would say that reflection data would most probably
need to be stored per compilation unit.

Inlining would not affect C++ reflection at all except in the ease of
generating reflection data. Reflection should not care about whether a
function is inlined or not since it is not relevant to reflection data,
which deals with type information.

Templates are a compile time mechanism. C++ reflection, as I would
define it, is a run-time mechanism. Therefore C++ reflection when
invoked at run-time need have no knowledge of templates whatsoever,
while being able to "reflect" on functions and classes instantiated from
template code just like any other functions and classes.

Of course template programmers may also want a compile time reflection
mechanism in order to make template metaprogramming easier, but that is
not my concern when I hear about C++ reflection even though I would
agree that it might be valuable to C++ as a separate type of reflection
feature.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Boris Bralo wrote:
> Hi all,
> What is main reason for not introducing reflection in c++?
> When I think about possible implementation I don't see too much
> overhead over RTTI. I know that this is debatable, but in most cases,
> when RTTI overhead is acceptable (i.e. "normal" , non-embedded
> scenarios ), a little bit larger memory footprint for reflection data
> is also acceptable.
> I don't know if it's a popular belief, but I see reflection as a main
> point in favor of java and c#. =20
> Am I missing something?
>=20
> Boris
>=20
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with=
 ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu   =
 ]
> [              --- Please see the FAQ before posting. ---              =
 ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                      =
 ]
>=20
IMHO I don=B4t think reflections are useful, can you give an example wher=
e=20
you really need it?
also, I think that=B4s a feature for scripting languages

marcel

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Edward,

You have been misinformed. A great deal of work on the C++ language and
its library is done by people who are not on the committee. For
example, John Maddock and Peter Dimov are respected contributors,
responsible for a great deal of TR1, yet neither is on the committee or
has ever attended a meeting. Something like a third of all the library
DR's accepted come from non-committee members. The views of people who
post on comp.std.c++ find their way into commitee discussions too.

If you want some feature in C++0X, write a proposal. Ask me privately
how to get an official document number and where to send the document
so it gets in a mailing. That is the mechanism for contributing major
proposals. For minor proposals, comments, and critiques of papers in
the committee mailings, post them here on comp.std.c++.

--Beman Dawes

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

>Reflection need not be related to classes only so your statement that
>"reflection data is per class" is not necessarily true at all. There is
>no reason not to generate reflection data for global objects which exist
>outside of classes.
"Per type" should be more precise.

>Inlining would not affect C++ reflection at all except in the ease of
>generating reflection data. Reflection should not care about whether a
>function is inlined or not since it is not relevant to reflection data,
>which deals with type information.
Unless you want to do something with object of reflected type. For
example when you want to invoke some method you got via reflection.This
is not possible if method is gone i.e inlined.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

>IMHO I don   t think reflections are useful, can you give an example where
>you really need it?
>also, I think that   s a feature for scripting languages
Aspect oriented programming, development tools such as debuggers, class
browsers, GUI builders, EJB-like stuff...

Boris


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 12/14/2005 04:11 PM, Marcel wrote:
[snip]

> IMHO I don   t think reflections are useful, can you give an example where you really need it?
> also, I think that   s a feature for scripting languages


I'd think it could be useful for serialization, and I know it would be
useful for collecting cycles in reference counting garbage collectors.
In the latter case, reflection could be used to enumerate all the smart
pointers contained in a given class.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Boris Bralo wrote:

>>Inlining would not affect C++ reflection at all except in the ease of
>>generating reflection data. Reflection should not care about whether a
>>function is inlined or not since it is not relevant to reflection data,
>>which deals with type information.
>
> Unless you want to do something with object of reflected type. For
> example when you want to invoke some method you got via reflection.This
> is not possible if method is gone i.e inlined.

Because a method is inlined does not mean that it is "gone" any more
than it does if one invokes a method specified at compile time. The
compiler has to generate code in either case whether the method is
inlined or not. I think your concern here is creating a problem where
one should not practically exist.

Personally, although it would be nice to eventually see in C++, I would
be happy to see an initial C++ run-time reflection mechanism which
merely allowed for the discovery of C++ type information without the
ability of creating objects from types. The latter can come later, if at
all, as far as I am concerned. I grant it would be a nice feature to be
able to create objects from type information at run-time, and that it
has some clever uses as Python shows.

For an initial iteration of C++ run-time reflection, KISS would be a
good principle, and the main idea should simply be to discover C++ type
information from an object or a type at run-time, and be able to drill
down as far as necessary with compound types. That would be eminently
useful for RAD environments, debuggers, 3rd party introspection tools,
and like uses of C++ reflection.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

>>>Inlining would not affect C++ reflection at all except in the ease of
>>>generating reflection data. Reflection should not care about whether a
>>>function is inlined or not since it is not relevant to reflection data,
>>>which deals with type information.

>> Unless you want to do something with object of reflected type. For
>> example when you want to invoke some method you got via reflection.This
>> is not possible if method is gone i.e inlined.

>Because a method is inlined does not mean that it is "gone" any more
>than it does if one invokes a method specified at compile time. The
>compiler has to generate code in either case whether the method is
>inlined or not. I think your concern here is creating a problem where
>one should not practically exist.

Reflection is runtime facility and in runtime inlined methods are
effectivelly gone. The same is true for non-exported (hidden in gcc
lingua) types/methods in shared libraries on some
architectures/compilers (win32 and gcc 4.0 on *nix). In inline case,
one may provide non-inlined copies for reflection but that may be too
much overhead.
My point is that we maybe cannot have "full" reflection facilities like
java and c#, but something between that and typeid().

Boris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Virtanen Antti wrote:
> On 2005-12-14, Edward Diener No Spam <eldiener_no_spam_here@earthlink.net> wrote:
>
>
>>>>My understanding that reflection in C++ is being worked on by the C++
>>>>standards committee in the form of something called XVT. However my
>>>>understanding, from inquiring about this, is that this is being done
>>>>strictly within the comittee and not with any outside contributions. I
>>>>just wish them good luck and hope they succeed.
>
>
> Me too. I do not see any reason (in this thread or anywhere else)
> for not having reflection in C++. It would pose some overhead, which
> would be unacceptable in some projects, but why not provide the
> possibility for reflection and let the programmer control it?

I agree with you here. A compiler vendor could provide a switch whether
to include reflection data in generated object files and in the final
module, much like the switch compiler vendors now provide a switch
whether to include debug data in generated object files and in the final
module.

>
>
>>I would be glad to contribute via e-mail and the Internet if I could in
>>any work being done regarding reflection in C++. But if it required me
>>to be a member of the C++ standards committee, go to meetings, and
>>physically meet with others I do not have the time or practical means to
>>do so.
>
>
> As the committee is composed of smart people it is obvious they have read
> the relevant papers and are aware of the existing reflection implementations
> for C++. Yet no one has referred to them in this thread? Anyway, if one
> is going to do some real work on the subject one should go through them.

I have tried to go through this route in the past to no avail. I would
rather work on my own or with others who are interested in my ideas,
than try to appeal to those who are not interested in C++ run-time
reflection or already have their own group.

>
> I don't claim to know all of them, but here are two reflection implementations
> which have been created for real need:
>
> "Non-intrusive object introspection in C++." by Tyng-Ruey Chuang,
> Y.S. Kuo and Chien-Min Wang.
> Software - Practise and Experience 2002;32;191-207

I was not aware of this effort and will investigate.

>
> "Reflection in C++" by Stefan Roiser. (CERN EP/LBC, TU Vienna)
> LCG SEAL Reflection team.

Contact with this person has proved elusive. I believe this
implementation has been susbsumed into a larger application called ROOT
to the degree that it appears to be too well hidden for me to pursue.

>
> Of these two the former might serve as a basis for possible addition
> to C++ standard. Due to non-intrusive nature it poses very little
> overhead and should not break anything in existing programs. (Or perhaps
> someone could point out the problems?) It is not "real reflection"
> but adequate for most purposes IMHO.

My ideas for real C++ run-time reflection involved using the typeid
mechanism to create extended type information in the form of a class
hierarchy. Like typeid now, this extended type information would be
available initially either from a type itself or from an object of that
particular type. The extended type information would need compiler
language support, at the extended typeid level, and not just library
support, and of course the data would need to have been generated by the
compiler as chosen by the programmer. Within this class hierarchy one
could explore information about any accessible type in the module.

The type would obey the visibility rules current in C++ so that
attempting to access, for example, a private member of a class type from
outside that class, would not be allowed. The run-time type mechanism
would only apply to run-time constructs, so that much of the type
information necessary for templates, as an example of a compile time
mechanism, would be unavailable and unnecessary. While it would be ideal
to be able to create an object from a type, the initial C++ run-time
reflection should have the nore modest goal of simply allowing an
investigation of any type in the final module.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Dietmar Kuehl <dietmar_kuehl@yahoo.com> wrote:
> This depends on your needs. I wouldn't even dream of using reflection
> in high performance numeric code but in areas more related to user

Even if we're talking about some kind of compile-time, or static reflection?

E.g., in a past project I used a class to model the state vector of a
rigid body (p,v,q,w) (position, velocity, orientation, angular velocity).
Being a vector, this needs addition and scalar multiplication.  It is trivial
to implement that by hand.  But if one had some for_each_field<> loop
statement, one could have the compiler do the work.  E.g., for addition:

// Requires:  All fields of T are assignable and have operator+() defined.
template< typename T > T const operator+( T const& x, T const& y ) {
  T z;
  for_each_field< T > { z.field = x.field + y.field; }
  return z;
}

For

struct state {
  vector_3   p;
  vector_3   v;
  quaternion q;
  vector_3   w;
};

this would expand to

state const operator+( state const& x, state const& y ) {
  state z;
  z.p = x.p + y.p;
  z.v = x.v + y.v;
  z.q = x.q + y.q;
  z.w = x.w + y.w;
  return z;
}

This should be just as efficient as hand-written code.

The same mechanism could be used to implement generic serialization.

-Gerhard
--
Gerhard Wesp
Zuerich, Switzerland
+41 (0)76 505 1149 (mobile)
+41 (0)44 668 1878 (office)
+41 (0)44 200 1818 (office fax)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Larry wrote:
> On 12/17/2005 05:59 PM, Dietmar Kuehl wrote:
>> generic mapping to relation databases) and generic GUIs I use reflection
>> also for generic object navigation a la XPath.
>
> Could you give some more details.

In my current project which uses C#, I need to create reports. These
use XPath expressions in their formatting information (I'm using HTML
for an example although the real format is something else):

  <table rows="path:Building/Stories/Areas[@Area > 1.5]">
    <tr>
     <td value="path:../Name"/>
     <td value="path:A"/>
     <td value="path:B"/>
     <td value="path:Area"/>
    </tr>
  </table>

This table would get a "Project" object as context node and print
the areas making up each storey of a building. Of course, there is
something involved interpreting the description and filling in the
corresponding stuff. This is where reflection is used. The
corresponding portions of the involved class would look like this
(using C++ notation):

  struct Project {
    // ...
    Building* Building() const;
  };

  struct Building {
    // ...
    std::vector<Storey*> Storeys() const;
  };

  struct Storey {
    // ...
    std::string        Name() const;
    std::vector<Area*> Areas() const;
  }

  struct Area {
    // ...
    double A() const;
    double B() const;
    double Area() const;
  };

Obviously, the types returned are not just using a short notation
for something which would be more like to return iterators and
smart pointers but the above should give the idea. Without something
like reflection I could clearly create a similar device at the cost
of maintaining corresponding attribute maps. This would to some
extend defeat the whole approach. On the other hand, it would also
provide better control.
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Boris Bralo wrote:
>>>>Inlining would not affect C++ reflection at all except in the ease of
>>>>generating reflection data. Reflection should not care about whether a
>>>>function is inlined or not since it is not relevant to reflection data,
>>>>which deals with type information.
>
>
>>>Unless you want to do something with object of reflected type. For
>>>example when you want to invoke some method you got via reflection.This
>>>is not possible if method is gone i.e inlined.
>
>
>>Because a method is inlined does not mean that it is "gone" any more
>>than it does if one invokes a method specified at compile time. The
>>compiler has to generate code in either case whether the method is
>>inlined or not. I think your concern here is creating a problem where
>>one should not practically exist.
>
>
> Reflection is runtime facility and in runtime inlined methods are
> effectivelly gone.

The phrase "effectively gone" is not meaningful here. All we should care
about for run-time reflection is whether we can find the name of the
method and the types of its parameters and return values. If you think
that run-time reflection should also be able to call a method from its
type, something which I am not entirely convinced is very important at
least in the first iteration of a runtime reflection for C++, the code
is still there to be called whether it is inlined or not if we can find
it in the module.

> The same is true for non-exported (hidden in gcc
> lingua) types/methods in shared libraries on some
> architectures/compilers (win32 and gcc 4.0 on *nix).

That has nothing to do with "inline" as far as I have ever experienced.
If the method is imported into a module, there is no reason why run-time
reflection can not find its name and type information.

> In inline case,
> one may provide non-inlined copies for reflection but that may be too
> much overhead.

The overhead will exist in any situation. Run-time reflection should be
part of C++ but the programmer should be able to turn it on or off as he
pleases. Let's not start worrying about "overhead" and then justifying
the non-inclusion of C++ run-time reflection by that argument. That's a
path of not adding anything to a language.

> My point is that we maybe cannot have "full" reflection facilities like
> java and c#, but something between that and typeid().

I agree with you on this as a cautionary comment about C++ run-time
reflection. I believe we can have at least C++ run-time reflection
facilities which can report full type information at run-time, and that
is at least worth working toward, as there are many environments that
would benefit. Whether we can have run-time reflection which invokes
function calls or the creation of objects at run-time, from type
information, is a diffifcult issue but I will gladly settle for run-time
reflection without it at least for a start. There is no reason to say we
must have all or nothing.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Boris Bralo wrote:
> >IMHO I don   t think reflections are useful, can you give an example where
> >you really need it?
> >also, I think that   s a feature for scripting languages
> Aspect oriented programming, development tools such as debuggers, class
> browsers, GUI builders, EJB-like stuff...

The kinds of development tools you're mentioning typically have access
to the source code. Do you have examples of applications that need
reflection that don't also need/use the source code of the program?

Bob


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Bob Bell wrote:
> Boris Bralo wrote:
>=20
>>>IMHO I don=B4t think reflections are useful, can you give an example w=
here
>>>you really need it?
>>>also, I think that=B4s a feature for scripting languages
>>
>>Aspect oriented programming, development tools such as debuggers, class
>>browsers, GUI builders, EJB-like stuff...
>=20
>=20
> The kinds of development tools you're mentioning typically have access
> to the source code. Do you have examples of applications that need
> reflection that don't also need/use the source code of the program?

Shipping source code with libraries should be as unnecessary to=20
development tools as it is unnecessary to using libraries in a program.=20
Your bringing it up here simply reinforces the benefit of C++ run-time=20
reflection.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi
>> Reflection is runtime facility and in runtime inlined methods are
>> effectivelly gone.
>The phrase "effectively gone" is not meaningful here. All we should care
>about for run-time reflection is whether we can find the name of the
>method and the types of its parameters and return values. If you think
>that run-time reflection should also be able to call a method from its
>type, something which I am not entirely convinced is very important at
>least in the first iteration of a runtime reflection for C++,

I think that reflection without that is of limited use. When we have RT
information we should be able to do something useful with it.

>the code
>is still there to be called whether it is inlined or not if we can find
>it in the module.

No, without source code we cannot. The only way we can do it is to have
non-inlined copy of the function somewhere in the module.

>> The same is true for non-exported (hidden in gcc
>> lingua) types/methods in shared libraries on some
>> architectures/compilers (win32 and gcc 4.0 on *nix).
>That has nothing to do with "inline" as far as I have ever experienced.
>If the method is imported into a module, there is no reason why run-time
>reflection can not find its name and type information.

Yes, but the problem is same. The symbol in case is simply not visible
outside the shared module.

In practice,  we have three kind of objects:
- compile time objects - methods that are inlined, templates
- "module link time" objects - all except above, even non-exported
methods/classes
- runtime objects - only exported methods/classes

Language model has only notion of compile time and runtime.  I'm not
aware of the current status of module development (like java "import")
but I belive that it will address this issue.

I think that extended RTTI may include only objects from third
category.

>> In inline case,
>> one may provide non-inlined copies for reflection but that may be too
>> much overhead.

>The overhead will exist in any situation. Run-time reflection should be
>part of C++ but the programmer should be able to turn it on or off as he
>pleases. Let's not start worrying about "overhead" and then justifying
>the non-inclusion of C++ run-time reflection by that argument. That's a
>path of not adding anything to a language.

I agree, but this one is _huge_, considering how much C++ programmers
love inlining.

Boris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Boris Bralo wrote:
> Hi
>
>>>Reflection is runtime facility and in runtime inlined methods are
>>>effectivelly gone.
>>
>>The phrase "effectively gone" is not meaningful here. All we should care
>>about for run-time reflection is whether we can find the name of the
>>method and the types of its parameters and return values. If you think
>>that run-time reflection should also be able to call a method from its
>>type, something which I am not entirely convinced is very important at
>>least in the first iteration of a runtime reflection for C++,
>
>
> I think that reflection without that is of limited use. When we have RT
> information we should be able to do something useful with it.

Ideally, yes, if by "something useful" you mean creating objects from
types at run-time. By objects here I mean any construct which has a
type, such as non-member functions also.

>
>
>>the code
>>is still there to be called whether it is inlined or not if we can find
>>it in the module.
>
>
> No, without source code we cannot. The only way we can do it is to have
> non-inlined copy of the function somewhere in the module.

I am not cognizant of how object code looks in their final binary form
in modules and whether or not it is possible to jump to inline functions
and execute them at run-time if one could mark them in some way.

But let us suppose this is impossible. Your point is well taken if we
need to create objects from types. As you suggest, a compiler
implementation of C++ run-time reflection could create a non-inlined
version of the inlined code when the end-user asks it to create
reflection data.

>
>
>>>The same is true for non-exported (hidden in gcc
>>>lingua) types/methods in shared libraries on some
>>>architectures/compilers (win32 and gcc 4.0 on *nix).
>>
>>That has nothing to do with "inline" as far as I have ever experienced.
>>If the method is imported into a module, there is no reason why run-time
>>reflection can not find its name and type information.
>
>
> Yes, but the problem is same. The symbol in case is simply not visible
> outside the shared module.
>
> In practice,  we have three kind of objects:
> - compile time objects - methods that are inlined, templates
> - "module link time" objects - all except above, even non-exported
> methods/classes
> - runtime objects - only exported methods/classes
>
> Language model has only notion of compile time and runtime.  I'm not
> aware of the current status of module development (like java "import")
> but I belive that it will address this issue.
>
> I think that extended RTTI may include only objects from third
> category.

I still do not see the issue with the second category. A non-exported
method/class in a shared library is a run-time object from within that
shared library code, and in the case of C++ run-time reflection both
finding out information about the type of the object and creating
objects from that type, could still be used to do so from within the
shared library code.

If the practical example is at run-time not being able to access that
type or create objects from that type from outside the shared library
code, that seems normal to me when an object has not been exported.

Can you give an example of how this might affect C++ run-time reflection
negatively in your opinion ?

>
>
>>>In inline case,
>>>one may provide non-inlined copies for reflection but that may be too
>>>much overhead.
>
>
>>The overhead will exist in any situation. Run-time reflection should be
>>part of C++ but the programmer should be able to turn it on or off as he
>>pleases. Let's not start worrying about "overhead" and then justifying
>>the non-inclusion of C++ run-time reflection by that argument. That's a
>>path of not adding anything to a language.
>
>
> I agree, but this one is _huge_, considering how much C++ programmers
> love inlining.

If one wants a C++ run-time reflection mechanism which allows one to
create objects from types, and I agree with you this would be extremely
valuable, then if their is much inlined code, and the programmer has
"turned on" the generation of C++ run-time data for the unit and/or
module, then one pays that price if the inlined code needs to be
generated as non-inlined functions for that purpose. This is an issue
but I think one which a compiler implementation can resolve in a number
of different ways. Some of the ways for resolving this issue when
generating C++ run-time reflection data:

1) Do not inline any code.
2) Inline code for execution, but create a non-inlined copy for C++
run-time reflection use as part of the relection data generated.
3) Provide a compiler switch to control the above choice.
4) Add a new keyword to the C++ language, which relates to "inline", to
control this choice at the level of each possibly inlined function.

Without wishing to seem impractical, while acknowledging that run-time
creation of inlined functions may have issues, I do not think they are
unsolvable or should affect the design of a C++ run-time reflection
mechanism. But I agree they should be mentioned when creating a C++
run-time reflection specification.

Edward Diener

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Edward Diener No Spam wrote:
> My understanding that reflection in C++ is being worked on by the C++
> standards committee in the form of something called XVT.

Bjarne had a presentation on something called XTI (eXtended Type
Information) in Kopenhagen and he wanted to provide more details on it
at one of the next meetings. I haven't seen anything on XTI since then.

If you want something in the standard, you should probably find out if
anybody else is working on it, e.g. by posting to this forum, and if
this is not the case, you should consider working on it yourself,
possibly with the help of others. Whether you are a member of the
committee is irrelevant with respect to submitting proposals. However,
you should probably find someone attending the meetings to present
your view and your proposal at the meetings. I know that there are
several people interested in refection in C++ but as far as I can tell
their priorities are on other topics than to work on reflection
themselves.
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Marcel wrote:
> can you give an example where you really need it?

I have many situations where I can work around the lack of reflection
at the cost of manually providing information which is already availabe
to the compiler imposing extra work and ample opportunities for errors.
Apart from various forms of persistance (e.g. serialization or a
generic mapping to relation databases) and generic GUIs I use reflection
also for generic object navigation a la XPath.

> also, I think that=B4s a feature for scripting languages

This depends on your needs. I wouldn't even dream of using reflection
in high performance numeric code but in areas more related to user
interface it comes in handy to let the user formulate their needs
rather than having to hardcode them somehow (or to maintain manual
type information).
--=20
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 12/17/2005 05:59 PM, Dietmar Kuehl wrote:
[snip]

> generic mapping to relation databases) and generic GUIs I use reflection
> also for generic object navigation a la XPath.

Could you give some more details.  I'd like to see if
fields_visitor:

http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/fields_visitor/

could satisfy your requirements for generic object navigation.  The
test
in:

http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/libs/policy_ptr/test/sp_graph_dfs_print_test.cpp?

prints the nodes in a graph and thereby demonstrates a type of node
navigation.
[snip]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 2005-12-14, Edward Diener No Spam <eldiener_no_spam_here@earthlink.net> wrote:

>>> My understanding that reflection in C++ is being worked on by the C++
>>> standards committee in the form of something called XVT. However my
>>> understanding, from inquiring about this, is that this is being done
>>> strictly within the comittee and not with any outside contributions. I
>>> just wish them good luck and hope they succeed.

Me too. I do not see any reason (in this thread or anywhere else)
for not having reflection in C++. It would pose some overhead, which
would be unacceptable in some projects, but why not provide the
possibility for reflection and let the programmer control it?

> I would be glad to contribute via e-mail and the Internet if I could in
> any work being done regarding reflection in C++. But if it required me
> to be a member of the C++ standards committee, go to meetings, and
> physically meet with others I do not have the time or practical means to
> do so.

As the committee is composed of smart people it is obvious they have read
the relevant papers and are aware of the existing reflection implementations
for C++. Yet no one has referred to them in this thread? Anyway, if one
is going to do some real work on the subject one should go through them.

I don't claim to know all of them, but here are two reflection implementations
which have been created for real need:

"Non-intrusive object introspection in C++." by Tyng-Ruey Chuang,
Y.S. Kuo and Chien-Min Wang.
Software - Practise and Experience 2002;32;191-207

"Reflection in C++" by Stefan Roiser. (CERN EP/LBC, TU Vienna)
LCG SEAL Reflection team.

Of these two the former might serve as a basis for possible addition
to C++ standard. Due to non-intrusive nature it poses very little
overhead and should not break anything in existing programs. (Or perhaps
someone could point out the problems?) It is not "real reflection"
but adequate for most purposes IMHO.

--
// Antti Virtanen -//- http://lokori.iki.fi/ -//- 050-4004278

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi all,
What is main reason for not introducing reflection in c++?
When I think about possible implementation I don't see too much
overhead over RTTI. I know that this is debatable, but in most cases,
when RTTI overhead is acceptable (i.e. "normal" , non-embedded
scenarios ), a little bit larger memory footprint for reflection data
is also acceptable.
I don't know if it's a popular belief, but I see reflection as a main
point in favor of java and c#.
Am I missing something?

Boris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]