David Abrahams said:
[EMAIL PROTECTED] [EMAIL PROTECTED] writes:
I'm very interested in having a reflection library available, but I
can't afford any time to helping with the work, sorry. However, I'd
suggest you take into consideration XTI, which is an idea for
reflection in C++ from
[EMAIL PROTECTED] [EMAIL PROTECTED] writes:
For fields, I do not think it is particularly useful to provide access
exclusively to the actual instance variables. It seems, however, that
access control specifiers of public, private, and protected are not
useful, however, because first of all,
A couple more questions.
I'm afraid I don't have the time or expertise to create a full C++
compiler (tho it would be interesting to try using Spirit). If I were
to
base a reflection framework on PDT, its parser and toolset comes as
binaries for the following platforms:
alpha
apple
hp9000s700
[EMAIL PROTECTED] said:
A reflective framework could be in three stages: a preprocessing
stage (which creates the reflection data), an optional code
generation/transformation stage, then a compilation stage. In this
sense, it would be both a compile and run-time framework.
Sounds like a
On Wed, 18 Dec 2002, William E. Kempf wrote:
I don't know if there's a
policy about library submissions depending on closed-source tools. I
don't think there should be a problem (after all, most compilers Boost
supports are closed-source), but it seems prudent to ask up-front.
I'm
[EMAIL PROTECTED] [EMAIL PROTECTED] writes:
I'm very interested in having a reflection library available, but I can't
afford any time to helping with the work, sorry. However, I'd suggest you
take into consideration XTI, which is an idea for reflection in C++ from
Bjarne Stroustrup (there's
On Wed, Dec 18, 2002 at 07:53:25AM -0800, [EMAIL PROTECTED] wrote:
I agree. OTOH, I think a full-fledged reflection library will be some ways
off. We could start with a bare-bones system designed to explicitly
support serialization, but I think it would slow down the adoption of the
existing
Jeremy Maitin-Shepard [EMAIL PROTECTED] writes:
On Wed, Dec 18, 2002 at 07:00:56PM -0500, David Abrahams wrote:
FWIW, I don't think it would be smart to put *too* many eggs in this
basket. Because XTI is based on debug symbol information, it is
neccessarily limited in certain ways that a
For fields, I do not think it is particularly useful to provide access
exclusively to the actual instance variables. It seems, however, that
access control specifiers of public, private, and protected are not
useful, however, because first of all, it seems that it would be
nearly impossible
[EMAIL PROTECTED] [EMAIL PROTECTED] writes:
A reflective framework could be in three stages: a preprocessing stage
(which creates the reflection data), an optional code
generation/transformation stage, then a compilation stage. In this sense,
it would be both a compile and run-time
On Tue, Dec 17, 2002 at 09:55:14AM -0800, [EMAIL PROTECTED] wrote:
Were talking exclusively about reflection now... I don't want this muddled
with the serialization discussion. They are separate topics. :-)
Perhaps, but it would be quite disappointing if after going to the
whole trouble of
[EMAIL PROTECTED] wrote:
Finally, is there anyone interested in working on a
reflection framework?
I've been recently drafting some interfaces for purely compile-time
reflection framework. It will clearly need a compiler support to implement;
the current plan is to prototype it in GCC. It's an
snip
I don't really know. There are other truly open alternatives that
might be worth looking into, e.g. GCC_XML, and Synopsis/OCC (get it as
part of the Synopsis package at synopsis.sf.net).
I've looked briefly at GCC_XML; I haven't seen Synopsis. In many ways I
would prefer one based on
On Tue, 17 Dec 2002, Aleksey Gurtovoy wrote:
I've been recently drafting some interfaces for purely compile-time
reflection framework. It will clearly need a compiler support to implement;
the current plan is to prototype it in GCC. It's an on-and-off project,
though :).
Cool. Would you care
14 matches
Mail list logo
