On 07/19/2004 04:00 AM, uqeuhqhiw wrote:
> I think static reflection is something many of us want to see.
> A complete static reflection would solve lots of
> problems together:
>
> 1. Easy creation of a wide variety of efficient garbage collectors
> algorithms without further support from the compiler. E.g. by making a
> bitmap of the pointers of the objects, bitmap which could be created at
> compile time with metaprogramming and static reflection.

There's a precise garbage collector which use's Detlef's method for
calculating smart pointer offsets. It's at:

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

The doc's need more work, but the general idea is having an abstract
VISITOR class which accesses various TYPES of smart pointer's that are
contained in an object.  Each TYPE of smart pointer can contain the
overhead for a specific type of garbage collection.  The concrete
classes derived from the abstract visitor class can then implement the
coordination (I guess somewhat like the mediator design pattern) of
the garbage collection for all smart pointers.

>
> 2. Customizable serialization features, which would require minimum
> typing on the client code, like just inheriting from a serializable
> "tagging" class
>
> 3. Use of C++ classes in a RAD IDE like you do with EJB and COM components.
>
> 4. Possibility of better debugging info, instantiation of classes based
> on name given at runtime etc.
>
> A powerful reflection (which is needed to do the above things) also
> means being able to access private and protected members (to find
> pointers offsets, and also for serialization).

The smart pointers in boost-sandbox/libs/managed_ptr/ could be used
for something besides garbage collection.  The thing common to all the
smart pointers is they record their offsets, and, for each type,
SP_CONTAINER, containing a smart pointer, there would be a descriptor,
descriptor_of <SP_CONTAINER>, which provided a way to access, via an
instance of the VISITOR class, each smart pointer contained in
instances of P_CONTAINER.  The descriptors are created once, in a
static variable, before the start of main.  However, there are
problems with this approach, as discussed here:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=105395hipubvofb%40corp.supernews.com

---
[ 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                       ]

uqeuhqhiw@aaa.com (uqeuhqhiw) wrote in
news:cdfft701esf@news4.newsguy.com:

> I think static reflection is something many of us want to see.

I second that notion.

> > A powerful reflection (which is needed to do the above things) also
> means being able to access private and protected members (to find
> pointers offsets, and also for serialization).

I'm working on a custom serialization tool right now, and am having exactly
the kind of problems you describe.  I've already implemented a similar tool
in Java and it was brain dead easy using reflection.  Turning my attention
to C++ is giving me fits however...

> Any thoughts?

Just that I agree completely.  :)

---
[ 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                       ]

I think static reflection is something many of us want to see.
A complete static reflection would solve lots of
problems together:

1. Easy creation of a wide variety of efficient garbage collectors
algorithms without further support from the compiler. E.g. by making a
bitmap of the pointers of the objects, bitmap which could be created at
compile time with metaprogramming and static reflection.

2. Customizable serialization features, which would require minimum
typing on the client code, like just inheriting from a serializable
"tagging" class

3. Use of C++ classes in a RAD IDE like you do with EJB and COM components.

4. Possibility of better debugging info, instantiation of classes based
on name given at runtime etc.

A powerful reflection (which is needed to do the above things) also
means being able to access private and protected members (to find
pointers offsets, and also for serialization).

This means that there should be a low level way to access private and
protected members. Currently this is not possible.

Also, this is a field in which C is "better" than C++: in C you can
access everything, in C++ you cannot. So there is something for which C
is preferable to C++, and this should not happen by design, right?

--------
class A
{
public:
   int pubfun() {return 1;}
private:
   int privfun() {return 2;}
   int privdata;
};

int main(int argc, char* argv[])
{
   A a;

   int (A::*afunptr) ();
   afunptr = &A::pubfun;
   std::cout << (a.*afunptr)();
   //afunptr = &A::privfun;    //Error: privfun is private
                               //- cannot access.
   //int * adataptr = &a.privdata;  //Error: privdata is private
                                    // - cannot access.


   return 0;
}
----------

There SHOULD be a low level way to access to those members IMHO: C++ is
  ALSO a low-level language. I would suggest an extension for which
const_cast can cast away the access specifiers. So the above code would
become


   int (A::*afunptr) ();
   afunptr = &A::pubfun;
   std::cout << (a.*afunptr)();
   afunptr = const_cast<public int (A::*) ()>(&A::privfun);  //Ok
   int * adataptr = const_cast<public int *> &a.privdata;  //Ok



Even Java allows "low level" access to private members, with reflection,
and Java claims to be a strict language in which the user "cannot do
wrong things". Also, since Java already provides garbage collection and
serialization capabilities, there was much less need for this feature
than there is in C++, yet they allow this.

Any thoughts?
Thanks

--
3C9DED3EEFCD90CB5E70FBA09CC9D17FD64CC6C4

---
[ 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                       ]