w.weston@ntlworld.com (Bill Weston) wrote in message news:<d05617ba.0209161435.5f5019b@posting.google.com>...
 > shannon.barber@myrealbox.com (Shannon Barber) wrote in message news:<de001473.0209130800.330e455c@posting.google.com>...
 > > template<class T>
 > > struct reflection
 > > {
 > > //black magic needed here
 > > };
 > >
 > >
 > > reflection<MyClass>::Public_Properties;
 > > reflection<MyClass>::Private_Methods;
 > > reflection<MyClass>::Protected_Base_Classes;
 > > reflection<MyClass>::Public_Typedefs;
 > > reflection<MyClass>::Private_Enums;
 > > reflection<MyClass>::Everything;
 > > reflection<MyClass>::All_Properties;
 > > etc...
 > >
 > >
 > > If anyone has any ideas on how to do this with C++ now, I'm all ears!
 > >
 > What about, as a wild suggestion, multiply-inheriting from each of
 > your public methods as one typelist of functor classes... your private
 > methods as another etc.  Then on the plus side you can use
 > Alexandrescu's techniques to iterate over them at compile time.  On
 > the minus side you have to downcast to the appropriate functor type to
 > call it.  On the plus side of that you can do dynamic_casts and
 > program dynamically.
 > hth
 > Bill Weston

After mulling it over for weeks I finally got it through my thick
skull what you were talking about - and painful is the only thing that
comes to mind now that I do :0)

It works backwards from the way I was thinking about the problem.  The
advantage would be that Loki/meta-template code builds the class.  You
feed the reflection defitions to a class builder, which builds the
class and maintains the reflection information.

While this doesn't help with existing classes, it does have potential
as a means to making new classes with reflection.  How would the
inherited methods access properties of the reflection-built class?

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Aatu Koskensilta wrote:
> Chris Uzdavinis wrote:
>
>>Francis Glassborow <francis.glassborow@ntlworld.com> writes:

[...snip...]
>>I'm not trying to start a language war, but I think that the two
>>really can fit nicely together.  With the "right tool for the job", it
>>still seems to me that could be looking to use a real programming
>>language for a preprocessor, possibly integrating a scheme (or
>>whatever) interpreter as a code generating pre-processor.  That way we
>>get the best of both worlds.
>
>
> I don't think that bringing a whole another language into C++
> (effectively turning the C++ compiler into a
> lisp/scheme/haskell/ML/whatever interpreter) is feasible.

   Well, there are two ways that such importation of a whole other language into
C++ can occur.  One is the overt way of modification of the core language
itself.  (This appears to be the technique to which you refer above.)  The other
  is the back-door way of bringing in a whole language (or programming paradigm)
via library-based contortion of the existing language.

   Between the two, I consider the former as proper language design by language
experts and the latter as a hack.  Hacks are beneficial to demonstrate in a
prototype what can be done much better in the production version.  Conversely,
standardization of hacks is completely unwelcome to me, not to mention abusing
the entire concept of standardization.  If C++ needs meta-programming
techniques, then let it be in the language itself instead of via a library of
inherently fragile hacks.

> Implementing
> one language right is hard enough, and keeping all the parts of C++
> hanging together is not trivial without the huge amount of additional
> design it would take to integrate a fundamentally different language
> (and its type system) into C++.

   Hmmmmm, designing one language or two to perform meta-programming in the core
language.  I wish that were in fact the trend that I saw emerging, either
designing one core C++ language or two (C++ with another) to handle
meta-programming.  Instead, we see trends of *library* designers instead of core
language designers doing a very fragile job of meta-programming.  I am very
uncomfortable about standardization (or de facto standardization in the
up-coming library technical report) of fragile/contrived meta-programming
libraries.  (Likewise, I am very uncomfortable about standardization of several
other complicated extensive-ramification concepts, such as smart pointers and
garbage collection, via fragile *libraries*.)

[...snip...]
>>Do you think that this would even be a possibility for the direction
>>of the language?  Is it even conceivable that a standardized language
>>like C++ could make use of another language whose specification is
>>outside its control?

   'Tis better to it in the core C++ language than as fragile C++98 libraries.

> I don't see why it should. Requiring that a conforming C++ compiler also
> contains a Haskell or Scheme interpreter/compiler seems not the way to go.
>
> Perhaps the compiler implementators, if pressed hard enough to convince
> them of necessity, would agree to some standardisation process for an
> API which would allow "scripting" the C++ compiler.

   Standardizing various reflection primitives in the core language (instead of
as fragile C++98 libraries) would be a useful endeavor, allowing C++ source code
to learn what the compiler knows would allow ways of doing
conditional-compilation and the like using modern better-disciplined reflection
language constructs instead of the crude C preprocessor antique.
---
[ 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 <3DA74CD9.6000905@tellabs.com>, Dan'l Miller
<Daniel.Miller@tellabs.com> writes
>  Hmmmmm, designing one language or two to perform meta-programming in the core
>language.  I wish that were in fact the trend that I saw emerging, either
>designing one core C++ language or two (C++ with another) to handle
>meta-programming.  Instead, we see trends of *library* designers instead of core
>language designers doing a very fragile job of meta-programming.  I am very
>uncomfortable about standardization (or de facto standardization in the
>up-coming library technical report) of fragile/contrived meta-programming
>libraries.  (Likewise, I am very uncomfortable about standardization of several
>other complicated extensive-ramification concepts, such as smart pointers and
>garbage collection, via fragile *libraries*.)
I see something very similar to the original development of C with
classes. Basically this seems to have been providing C with OO tools via
a pre-processor like fix. This led to C++ in its own right.

Now we are enhancing C++ with libraries for metaprogramming, we could
then have C++ with metaprogramming with a front end that translated this
into pure C++ supported with near incomprehensible libraries. I wonder
if there is a way to short circuit this by adding real support for
metaprogramming to C++. I think we should be very wary of just adding
features. Instead we should look at the needs of mp, decide what core
enhancements will make that native to C++ and release a TR on the
subject. This should allow us to gain real experience before
incorporating true support for mp into C++1x. I think that trying to do
a proper and well considered study in time for C++0x is out of the
question. We need to move such radical work forward in two stages, TR
which would hopefully lead to some real experience in the field, then
possibly incorporation into the following standard.

In fact, when I think about it, I think that several other major changes
might benefit from a similar two stage route. I am thinking of such
things as GC, MT and DLL support.

--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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                       ]

"Rob" <nospam@does.not.exist> wrote
> That's more or less where I was going when I suggested that we need
> to consider the capabilities required rather than the particular
> implementation(s) in Loki.
>
> Loki gives some fuel for interesting debates;
>
> 1)   It uses advanced features of the current language, that a lot of
>          compilers don't yet support. [Does any compiler actually
>         handle all of Loki without compiler specific workarounds?]

gcc 2.95.3 required a couple of minor modifications, gcc 3.2 works,
and it is believed that Comeau compiles it flawlessly (full checks
have not yet been done run though).  And if Comeau does barf on
something, I'm inclined to suspect the code not the compiler.  The
Intel compilers also work with the reference source code.  Code
Warrior almost works (everything compiles, but correct results are not
produced in one case!).  Borland & MSVC required ports.

>
> 2)   It demonstrates some interesting capabilities and concepts
>          that rely on quite advanced features.  That raises the question
>          in my mind: are some of those capabilities better implemented
>          as part of the language itself.
>
Well, we need more type information at compile-time.
---
[ 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                       ]

Aatu Koskensilta <aatu.koskensilta@xortec.fi> writes:

> Also,
> if we had to write a C++ parser and semantic analyser, there is nothing
> to guarantee that the particular C++ compiler we use agrees with our
> parsing/analysing code.

No, but if you write an ISO C++ parser, then the standard gaurentees
that any particular ISO C++ compiler agrees with your
parsing/analysing code.

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man
---
[ 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                       ]

Andy Sawyer <andys@evo6.com> writes:

| Aatu Koskensilta <aatu.koskensilta@xortec.fi> writes:
|
| > Also,
| > if we had to write a C++ parser and semantic analyser, there is nothing
| > to guarantee that the particular C++ compiler we use agrees with our
| > parsing/analysing code.
|
| No, but if you write an ISO C++ parser, then the standard gaurentees
| that any particular ISO C++ compiler agrees with your
| parsing/analysing code.

How so?  There are lost of places where ISO C++ leaves things
implementation-defined or unspecified.

--
Gabriel Dos Reis                    gdr@integrable-solutions.net


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Chris Uzdavinis wrote:
> Francis Glassborow <francis.glassborow@ntlworld.com> writes:
>
>
>>Right. What Loki does is show the kind of thing we might like to do
>>in a simpler way. What we now need to do, vis-   -vis metaprogramming
>>is to consider how we can support it with less contorted
>>mechanisms. Loki has shown us a potential and let us realise that
>>that potential has enough benefits so that some are willing to go
>>through almost mind-bending contortions to achieve those
>>benefits. Now we need, IMO, to se how we could empower more
>>programmers to achieve similar objectives.
>
>
> Since meta-template programming is basically attempting to do
> functional language pattern matching, the thought that keeps crossing
> my mind is: why invent another language that is grafted onto C++ (more
> template stuff) when we already have Scheme, Haskell, etc., were
> designed to do?

They all have type systems wildly different from the C++ one.

> I'm not trying to start a language war, but I think that the two
> really can fit nicely together.  With the "right tool for the job", it
> still seems to me that could be looking to use a real programming
> language for a preprocessor, possibly integrating a scheme (or
> whatever) interpreter as a code generating pre-processor.  That way we
> get the best of both worlds.

I don't think that bringing a whole another language into C++
(effectively turning the C++ compiler into a
lisp/scheme/haskell/ML/whatever interpreter) is feasible. Implementing
one language right is hard enough, and keeping all the parts of C++
hanging together is not trivial without the huge amount of additional
design it would take to integrate a fundamentally different language
(and its type system) into C++.

> That would make it possible to write elegant meta-programming code
> without having to mess around with the C++ language so directly.

Not without writing a C++ parser and semantics analyser in those
languages first. The advantage of having the compile-time
metaprogramming language a part of the C++ language is that we work
within the C++ type system, and can make use of it automatically. Also,
if we had to write a C++ parser and semantic analyser, there is nothing
to guarantee that the particular C++ compiler we use agrees with our
parsing/analysing code.

> While nothing stops me from using Scheme (or even perl, etc) as a
> preprocessor on my own, it would be nice if there were a formal way to
> do this such that I can distribute code that depends on such a
> processor and expect it to work portably without lots of custom
> configurations, etc.
>
> Do you think that this would even be a possibility for the direction
> of the language?  Is it even conceivable that a standardized language
> like C++ could make use of another language whose specification is
> outside its control?
>

I don't see why it should. Requiring that a conforming C++ compiler also
contains a Haskell or Scheme interpreter/compiler seems not the way to go.

Perhaps the compiler implementators, if pressed hard enough to convince
them of necessity, would agree to some standardisation process for an
API which would allow "scripting" the C++ compiler.

--
Aatu Koskensilta (aatu.koskensilta@xortec.fi)

"Wovon man nicht sprechen kann, daruber muss man schweigen"
  - Ludwig Wittgenstein, Tractatus Logico-Philosophicus

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

"Andrei Alexandrescu" <andrewalex@hotmail.com> wrote in message
news:alp28o$1rqa35$1@ID-14036.news.dfncis.de...
 >
 > "Rob" <nospam@does.not.exist> wrote in message
 > news:alh72s$rn3$1@fang.dsto.defence.gov.au...
 > > I agree that C++0x would benefit if some of the advanced capabilities
 > > provided in Loki (or being investigated using Loki) were included in
 > the
 > C++
 > > language
 > > or library.   But I disagree with your (implied?) assertion that Loki
 > should
 > > be dropped in as is;  I'm certainly uncomfortable with a library that
 > relies
 > > on clever macro trickery (eg for managing lists of types) as part of
 > the
 > > standard
 > > library.  In many ways, it could almost be argued that --- if those
 > features
 > > need
 > > to be a core part of C++ --- then the language needs to be extended to
 > > support them cleanly.
 >
 > In fact, it's funny how Loki gave a lot of "negative incentive" - it
 > exposes
 > limitations in compilers and in the expressiveness of the language :o).

<grin>

That's more or less where I was going when I suggested that we need
to consider the capabilities required rather than the particular
implementation(s) in Loki.

Loki gives some fuel for interesting debates;

1)   It uses advanced features of the current language, that a lot of
         compilers don't yet support. [Does any compiler actually
        handle all of Loki without compiler specific workarounds?]

2)   It demonstrates some interesting capabilities and concepts
         that rely on quite advanced features.  That raises the question
         in my mind: are some of those capabilities better implemented
         as part of the language itself.

Although C++ is based around providing more advanced capabilities
for expressing concepts, it is sometimes quite difficult to express
simple concepts in the language.  For example, I recall an article
by Andrei (following a gauntlet being thrown down by Scott Meyers)
on implementing a min function;   the actual solution required a
lot of thought and use of facilities in Loki.    Sort of showed up that
we have a language that can compute a minimum, but still has a
long way to go in expressing the *general concept* of a minimum.






      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

"Rob" <nospam@does.not.exist> wrote in message news:<alh72s$rn3$1@fang.dsto.defence.gov.au>...
> In many ways, it could almost be argued that --- if those features
> need
> to be a core part of C++ --- then the language needs to be extended to
> support them cleanly.

Templated typedefs, which I believe have been proposed as an addition
to the language, would go a long way towards eliminating these macros.
 Hopefully they'll make it in.  The template language as it standard
is too verbose IMO to currently be a convenient meta-language.
---
[ 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.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow <francis.glassborow@ntlworld.com> writes:

> Right. What Loki does is show the kind of thing we might like to do
> in a simpler way. What we now need to do, vis-   -vis metaprogramming
> is to consider how we can support it with less contorted
> mechanisms. Loki has shown us a potential and let us realise that
> that potential has enough benefits so that some are willing to go
> through almost mind-bending contortions to achieve those
> benefits. Now we need, IMO, to se how we could empower more
> programmers to achieve similar objectives.

Since meta-template programming is basically attempting to do
functional language pattern matching, the thought that keeps crossing
my mind is: why invent another language that is grafted onto C++ (more
template stuff) when we already have Scheme, Haskell, etc., were
designed to do?

I'm not trying to start a language war, but I think that the two
really can fit nicely together.  With the "right tool for the job", it
still seems to me that could be looking to use a real programming
language for a preprocessor, possibly integrating a scheme (or
whatever) interpreter as a code generating pre-processor.  That way we
get the best of both worlds.

That would make it possible to write elegant meta-programming code
without having to mess around with the C++ language so directly.

While nothing stops me from using Scheme (or even perl, etc) as a
preprocessor on my own, it would be nice if there were a formal way to
do this such that I can distribute code that depends on such a
processor and expect it to work portably without lots of custom
configurations, etc.

Do you think that this would even be a possibility for the direction
of the language?  Is it even conceivable that a standardized language
like C++ could make use of another language whose specification is
outside its control?

--
Chris
---
[ 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.research.att.com/~austern/csc/faq.html                ]

shannon.barber@myrealbox.com (Shannon Barber) wrote in message news:<de001473.0209130800.330e455c@posting.google.com>...
> What Loki needs from C++0x is a way to access type information at
> compile-time about classes, unions, structs, enums, etc...  We already
> have a bridge to allow run-time iteration of information about types
> in a typelist.  Given compile-time reflection, we can implement
> run-time reflection to our liking.
>
> Today, I worked out an implementation that builds a typelist of a
> function's parameters, however it requires typeof and the use of a
> dubious partial specialization (which gcc 2.95.3 compiles per my
> desire) that I do not believe is standard.
> It is a small blow to C++ Reflection Beast, but we need some method of
> compile-time class discovery to deal a fatal one.
>
> Given compile-time reflection, it ought to be possible to provide a
> meta-template implementation of any fundlemental design pattern (and
> thus any combination there-of).  It would also add all the benefits of
> run-time reflection, but you would be able to control which classes
> have run-time reflection.
>
> template<class T>
> struct reflection
> {
> //black magic needed here
> };
>
>
> reflection<MyClass>::Public_Properties;
> reflection<MyClass>::Private_Methods;
> reflection<MyClass>::Protected_Base_Classes;
> reflection<MyClass>::Public_Typedefs;
> reflection<MyClass>::Private_Enums;
> reflection<MyClass>::Everything;
> reflection<MyClass>::All_Properties;
> etc...
>
>
> If anyone has any ideas on how to do this with C++ now, I'm all ears!
>
What about, as a wild suggestion, multiply-inheriting from each of
your public methods as one typelist of functor classes... your private
methods as another etc.  Then on the plus side you can use
Alexandrescu's techniques to iterate over them at compile time.  On
the minus side you have to downcast to the appropriate functor type to
call it.  On the plus side of that you can do dynamic_casts and
program dynamically.
hth
Bill Weston
---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Alf P. Steinbach" <alf_p_steinbach@yahoo.no.invalid> wrote in message
news:3d76bee6.96102593@news.online.no...
 >
 > Well, the title says it all.
 >

I agree that C++0x would benefit if some of the advanced capabilities
provided in Loki (or being investigated using Loki) were included in the C++
language
or library.   But I disagree with your (implied?) assertion that Loki should
be dropped in as is;  I'm certainly uncomfortable with a library that relies
on clever macro trickery (eg for managing lists of types) as part of the
standard
library.  In many ways, it could almost be argued that --- if those features
need
to be a core part of C++ --- then the language needs to be extended to
support them cleanly.





      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Rob wrote:
> "Alf P. Steinbach" <alf_p_steinbach@yahoo.no.invalid> wrote in message
> news:3d76bee6.96102593@news.online.no...
>  >
>  > Well, the title says it all.
>  >
>
> I agree that C++0x would benefit if some of the advanced capabilities
> provided in Loki (or being investigated using Loki) were included in
the C++
> language
> or library.   But I disagree with your (implied?) assertion that Loki
should
> be dropped in as is;  I'm certainly uncomfortable with a library that
relies
> on clever macro trickery (eg for managing lists of types) as part of
the
> standard
> library.

Loki does not "rely" on those macros. They are just add-ons to make
using Loki an easier thing to do. If there is a feeling that those
macros can not be part of the standard - Loki can live without them.
I do not share the feeling though. There are macros in the standard
toolchest now and we use them daily. Say, assert. No big deal.
I do not think that anyone would argue against sertain fixes that need
to be done - apparently new standard is going to have some sort of
type traits and some other things (operator typeof?) that should be
used by Loki II instead of the ones that Loki I uses.


>  In many ways, it could almost be argued that --- if those features
> need
> to be a core part of C++ --- then the language needs to be extended to
> support them cleanly.


I do not think there is a great deal of new features that are needed
to support Loki.Matvei.



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

"Rob" <nospam@does.not.exist> wrote in message
news:alh72s$rn3$1@fang.dsto.defence.gov.au...
> I agree that C++0x would benefit if some of the advanced capabilities
> provided in Loki (or being investigated using Loki) were included in
the
C++
> language
> or library.   But I disagree with your (implied?) assertion that Loki
should
> be dropped in as is;  I'm certainly uncomfortable with a library that
relies
> on clever macro trickery (eg for managing lists of types) as part of
the
> standard
> library.  In many ways, it could almost be argued that --- if those
features
> need
> to be a core part of C++ --- then the language needs to be extended to
> support them cleanly.

In fact, it's funny how Loki gave a lot of "negative incentive" - it
exposes
limitations in compilers and in the expressiveness of the language :o).

Andrei

--
All new!  THE C++ Seminar: Oct. 28-30 in Vancouver, WA.
http://www.thecppseminar.com/






      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

What Loki needs from C++0x is a way to access type information at
compile-time about classes, unions, structs, enums, etc...  We already
have a bridge to allow run-time iteration of information about types
in a typelist.  Given compile-time reflection, we can implement
run-time reflection to our liking.

Today, I worked out an implementation that builds a typelist of a
function's parameters, however it requires typeof and the use of a
dubious partial specialization (which gcc 2.95.3 compiles per my
desire) that I do not believe is standard.
It is a small blow to C++ Reflection Beast, but we need some method of
compile-time class discovery to deal a fatal one.

Given compile-time reflection, it ought to be possible to provide a
meta-template implementation of any fundlemental design pattern (and
thus any combination there-of).  It would also add all the benefits of
run-time reflection, but you would be able to control which classes
have run-time reflection.

template<class T>
struct reflection
{
//black magic needed here
};


reflection<MyClass>::Public_Properties;
reflection<MyClass>::Private_Methods;
reflection<MyClass>::Protected_Base_Classes;
reflection<MyClass>::Public_Typedefs;
reflection<MyClass>::Private_Enums;
reflection<MyClass>::Everything;
reflection<MyClass>::All_Properties;
etc...


If anyone has any ideas on how to do this with C++ now, I'm all ears!



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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 <alp28o$1rqa35$1@ID-14036.news.dfncis.de>, Andrei
Alexandrescu <andrewalex@hotmail.com> writes
>In fact, it's funny how Loki gave a lot of "negative incentive" - it
>exposes
>limitations in compilers and in the expressiveness of the language :o).

Right. What Loki does is show the kind of thing we might like to do in a
simpler way. What we now need to do, vis-   -vis metaprogramming is to
consider how we can support it with less contorted mechanisms. Loki has
shown us a potential and let us realise that that potential has enough
benefits so that some are willing to go through almost mind-bending
contortions to achieve those benefits. Now we need, IMO, to se how we
could empower more programmers to achieve similar objectives.


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Well, the title says it all.

Cheers,

- Alf

(Who'd like a small change in Loki: the ability to return a smart-
pointer from a Factory (if it isn't there already)).

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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