<BASE HREF="/home/vollmann/winuser/orgs/wg21/reflection/options/n1751.html">

<HTML
><HEAD
><TITLE
>Aspects of Reflection in C++</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.60"></HEAD
><BODY
CLASS="ARTICLE"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="ARTICLE"
><DIV
CLASS="TITLEPAGE"
><H1
CLASS="TITLE"
><A
NAME="AEN2"
>Aspects of Reflection in C++</A
></H1
><SPAN
CLASS="FIRSTNAME"
>Detlef&nbsp;</SPAN
><SPAN
CLASS="SURNAME"
>Vollmann<BR></SPAN
><DIV
CLASS="AFFILIATION"
><SPAN
CLASS="ORGNAME"
>vollmann engineering gmbh<BR></SPAN
></DIV
><SPAN
CLASS="ADDRESS"
>      <A
HREF="mailto:dv@vollmann.ch"
>dv@vollmann.ch</A
>
    </SPAN
><TABLE
><TR
><TD
ALIGN="RIGHT"
><B
>Document Number: </B
></TD
><TD
>JTC 1/SC22/WG21/N1751 J16/05-0011</TD
></TR
><TR
><TD
ALIGN="RIGHT"
><B
>Date: </B
></TD
><TD
>2005-01-14</TD
></TR
><TR
><TD
ALIGN="RIGHT"
><B
>Project: </B
></TD
><TD
>     JTC1.22.32<BR>
     Programming Language C++
     <BR>Evolution Working Group
    </TD
></TR
><TR
><TD
ALIGN="RIGHT"
><B
>Reference: </B
></TD
><TD
>ISO/IEC IS 14882:2003(E)</TD
></TR
></TABLE
><HR></DIV
><BLOCKQUOTE
CLASS="ABSTRACT"
><DIV
CLASS="ABSTRACT"
><A
NAME="AEN19"
></A
><P
><B
>Abstract</B
></P
><P
>There exist a lot of applications where reflection comes in as a
useful technique.  So, quite a number of people think that some
mechanisms supporting reflection should be added to the next version of C++.
 </P
><P
>This paper presents
several typical applications of reflection,
several different aspects of reflection
and several different currently existing approaches to reflection
in C++ and other languages.
Then it describes how the different applications can be implemented
based on the different kinds of reflection.
 </P
></DIV
></BLOCKQUOTE
><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Note: </B
>This paper was put together in a rush.  It is not a fully researched
academic paper or a complete survey of all options and existing
approaches.  It does not meet formal academic standards and
uses sometimes sloppy terminology.
 </P
><P
>Also this paper is not an actual proposal.
It provides some background on reflection and is intended to serve as
a starting point
for the discussion about reflection and how it can be added to C++.
 </P
></BLOCKQUOTE
></DIV
><DIV
CLASS="SECTION"
><HR><H1
CLASS="SECTION"
><A
NAME="APPLICATIONS"
>Applications</A
></H1
><P
>This section simply presents some typical applications of reflection.
It does not present any solutions/realizations here,
but intends to span the problem domain for which reflection is
assumed to be a solution.
The later sections will then discuss whether and how these applications can be
realized using the different kinds of reflection.
 </P
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="RDB"
>Externalization</A
></H2
><P
>Typical applications of reflection is all kind of externalization:
<P
></P
><UL
><LI
><P
>(De-)Serialization to/from a flat file</P
></LI
><LI
><P
>Transmission through a stream connection</P
></LI
><LI
><P
>Persistence on an external DB</P
></LI
></UL
>
  </P
><P
>The latter example has some interesting details.
If the external DB is table based, the externalization often consists
of two parts: a first part to define the DB schema, i.e. to create
the table definitions in some form, and a second part to actually
write objects to a table (or read from a table).  As example, let's have
<PRE
CLASS="PROGRAMLISTING"
>class JournalEntry
{
    // ...
private:
    string description;
    Date valueDate;
    Money amount;
};</PRE
>
  </P
><P
>For the first part, we would have something like
<TT
CLASS="LITERAL"
>createTableDef(ofile, Person)</TT
>
which then should write into <TT
CLASS="VARNAME"
>ofile</TT
> something like
<PRE
CLASS="PROGRAMLISTING"
>create table journal_entry
(
    description  varchar(80),
    valueDate date,
    amount numeric(17,2)
)</PRE
>
  </P
><P
>In the second part, a call like
<PRE
CLASS="PROGRAMLISTING"
>JournalEntry curEntry;
// ...
myDb.store(curEntry);</PRE
>
should actually store the user object in the DB.
  </P
><P
>While this second part typically poses no special problems,
given the usual reflection facilities, the first part requires
information not directly available from the C++ code above.
So the limiting of <TT
CLASS="VARNAME"
>description</TT
> to 80 characters in the
table definition is something, for which the information must be
provided somehow.
Also the mapping of the C++ class <TT
CLASS="CLASSNAME"
>Date</TT
>
to the DB type <SPAN
CLASS="TYPE"
>date</SPAN
>, though it seems simple,
requires a lot of information not directly available to the compiler;
the same holds for the mapping from
<TT
CLASS="CLASSNAME"
>Money</TT
> to <SPAN
CLASS="TYPE"
>numeric</SPAN
>.
  </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="CODEANALYSIS"
>Code Analysis</A
></H2
><P
>Quite a lot of general Java applications exist that provide a static
analysis of the source code.  They all build on published, standardized
interfaces to collect their information.
For C++, the number of such tools is much smaller, one of the reasons
being the lack of such an interface.
Some of these tools provide simple metrics information,
others create graphical representations of the code,
and still others create automated tests based on class definitions,
like <A
HREF="#JCRASHERBIB"
>JCrasher</A
>.
  </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="DEVTOOLS"
>Development Tools</A
></H2
><P
>Another category of tools provide not only useful information
based on the source code, but also insight on runtime structures.
Such tools help to explore unknown program code and often even
support runtime debugging.  An example of such a tool is
<A
HREF="#EDOBSBIB"
>eDOBS</A
>.
Other tools create test cases based on the analysis of the
runtime behaviour of a program, like <A
HREF="#SABICUBIB"
>Sabicu</A
>.
  </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="AOP"
>Aspect-Oriented Programming</A
></H2
><P
>So-called aspect-oriented mechanisms provide interesting solutions
to some programming problems.  Common to these approaches is that
they provide mechanisms to act on the edges of a call graph;
i.e. before a function is called or after it returns some
specific actions are performed.  Well-kown and very general
examples of this approach
are <A
HREF="#ASPECTJBIB"
>AspectJ</A
> or
<A
HREF="#ASPECTCXXBIB"
>AspectC++</A
>,
but the same approach is found in tools like profilers or tracers.
   </P
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H1
CLASS="SECTION"
><A
NAME="REFLASPECTS"
>Aspects of Reflection</A
></H1
><P
>Reflection can be catagorized along two orthogonal design principles:
<P
></P
><UL
><LI
><P
>at which time reflection is provided, and</P
></LI
><LI
><P
>functionality provided by the reflection mechanism.</P
></LI
></UL
>
This section discusses different aspects of these principles.
 </P
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="COMPILETIME"
>Compile-Time Reflection</A
></H2
><P
>Compile-time reflection generally provides mechanisms at the source code
level. These mechanisms provide information that can be directly
derived from the source code, i.e. information about types and their
definitions, variables and executable code like expressions or
control structures.
  </P
><P
>This information can then be used to inject or transform code,
to instantiate templates or to generate external data: from simple metrics
information to full-fledged representations of the source code entities.
This external data together with some injected code can then
be used to provide such information at runtime.
  </P
><P
>An interesting question in C++ is: When is compile-time?
A rough distinction of different phases during compilation could be
made by separating preprocessing, template instantiation and
code generation.  (This is not really an accurate description
of the C++ compilation model, but sufficient for this discussion.)
Is information available on preprocessor macros or physical
locations, i.e. source file names and line numbers?
More interestingly, is information available about template
instantiations and which function of an overload set is called
in an expression, or what automatic conversions are applied?
A related question is: Is reflection recursive, i.e. is e.g.
injected code itself a possible object for reflection?
  </P
><P
>Most existing approaches for C++ (see <A
HREF="#APPROACHES"
>below</A
>)
are realized as
pre-compilers that pre-run an external preprocessor, so while typically
physical location information is preserved, information about
preprocessor macros is not possible and not visible.
With this approach, information about template instantiations
or overload resolution is not available.
But a native reflection mechanism could provide such information,
though some of it only at link time (due to <SPAN
CLASS="MARKUP"
>export</SPAN
>).
  </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="RUNTIME"
>Runtime Reflection</A
></H2
><P
>Runtime reflection provides mechanisms during program execution.
Information available generally includes what objects currently exist of
a specific class or which variables have which values.
But it also comprises typical debugging information like stack frames
or even contents of processor registers.
  </P
><P
>The manipulation mechanisms include changing values, calling functions
or creation of new instances of a type, but also modification of
existing functions or classes or addition of new ones.
Related to debugging, runtime reflection also provides
notification mechanisms for events like calling or leaving a function
or creation or deletion of an object.
  </P
><P
>In many existing approaches, (limited) runtime reflection
is provided by creating a meta-data repository and injecting respective
code using compile-time reflection.
  </P
><P
>As already noted above, compile-time and runtime are neither exactly
specified here nor do they desribe all possible points when reflection
is possible.  At least two more phases can be usefully distinguished,
namely link time and load time.
  </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="INTROSPECTION"
>Introspection</A
></H2
><P
>Reflection can either be a purely informational facility or can provide
manipulation facilities.  Introspection is generally the informational
part of reflection, the mechanism to examine all kind of structure
of a program.
At compile-time, introspection provides information such as what
base classes or what members a class has, but also what statements
are in a function definition.
At runtime, introspection allows to ask an object about its type,
to query the values of an object's data member or to examine
the call stack at a specific point in execution.
Also at runtime, introspection provides notification of specific events,
such as the invocation or exiting of a function, the creation
of an object or the throwing of an exception.
  </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="MOP"
>Self-Modification</A
></H2
><P
>Self-modification generally provides mechanisms to manipulate
the reflected entity.
At compile-time it allows the deletion, transformation
or injection of source code, e.g. addition of members to a class
or replacing the target of a function call.
At runtime, self-modification allows to invoke functions, to change
the values of objects or to create new objects.
More importantly, self-modification allows the introduction of new
classes and functions at runtime and to make them an inherent part
of the running executable.
  </P
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H1
CLASS="SECTION"
><A
NAME="APPROACHES"
>Existing Reflection Approaches for C++</A
></H1
><P
>This section presents several (proposed) approaches to provide
reflection facilities for C++.
 </P
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="SRCTRANS"
>Source-Code Transformation</A
></H2
><P
>A number of tools exist for analysis and transformation of C++
source code, e.g. <A
HREF="#OPENCXXBIB"
>OpenC++</A
>,
<A
HREF="#PUMABIB"
>PUMA</A
> or <A
HREF="#PIVOTBIB"
>The Pivot</A
>.
They generally work at compile-time on preprocessed source code
providing an introspection interface and a modification interface.
The latter can be used to build a repository with meta-data with which
a related library can provide runtime introspection and even
(limited) runtime self-modification.
  </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="METACODE"
>Metacode</A
></H2
><P
>Daveed Vandevoorde's <A
HREF="#METACODEBIB"
>Metacode</A
>
extension is a (not yet officially) proposed
extension for C++0x.  While the main objective (according to the
presentation given at the Oxford meeting) is a simpler replacement for
template metaprogramming, with appropriate functions in
<TT
CLASS="LITERAL"
>stdmeta</TT
> it can serve as a complete replacement
for the <A
HREF="#SRCTRANS"
>above</A
> source code tools.
It can possibly even provide more functionality, as it is part
of the compiler and can therefore provide information about
template instantiations and overload resolutions.
  </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ARNO"
>Arne Adams' Reflection Library</A
></H2
><P
>Arne Adams provides a <A
HREF="#ARNESLIBBIB"
>reflection library</A
>
mainly targeted at database schema generation.
Though the current definition interface and implementation is (very)
ugly, it provides some interesting functionality, e.g. a compile-time
iteration over the data members of a class (and therefore through
overload resolution easily distinguished actions on differently
typed members).
  </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="META"
>Meta-Object Protocol</A
></H2
><P
>The author has presented an <A
HREF="#MOPBIB"
>approach</A
>
to implement a full runtime meta-object
protocol on top of compile-time reflection.  This approach can be used
to roll an own application-level meta-object facility, but it can
not really replace a built-in runtime self-modification facility.
  </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="JAVA"
>Java Approaches</A
></H2
><P
>Java provides a number of reflection mechanisms.
  </P
><P
>The standard <A
HREF="#JAVAREFLBIB"
>Java Reflection</A
>
provides essentially compile-time introspection information
and some runtime manipulation through a runtime interface.
  </P
><P
>The <A
HREF="#JDIBIB"
>Java Debug Interface</A
> defines
a superset of the functionality of the standard Java reflection
and provides that through
an external interface.  Its main purpose is to reflect an executing
Java program through an external program, but it can also be used
to reflect the own program.
It has a comprehensive runtime introspection interface, including
notifications on all kind of events, but has only limited runtime
modification functionality.
  </P
><P
>The third-party <A
HREF="#BCELBIB"
>Java ByteCode Engineering Library</A
>
is essentially the Java counterpart for the C++ source code transformation
tools.  It works not on source code level but on byte code, but that
has enough information to provide a full compile-time introspection
and modification functionality.
  </P
><P
>An interesting recent addition to the Java language are
<A
HREF="#JAVAANNOTATIONSBIB"
>Java Annotations</A
>.
These provide a mechanism for the programmer to define additional meta-data
for a class that can be accessed through the Java reflection mechanisms.
  </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="MIRRORS"
>Mirrors</A
></H2
><P
><A
HREF="#MIRRORSBIB"
>Mirrors</A
> are an interesting approach
for a reflection mechanism in a language.  It can be used for all
kind of reflection: compile-time, runtime, introspection and modification.
A particularly interesting property of mirrors is that they are not intrusive,
i.e. they are not part of the interface of a class, and that even
runtime reflection can be realized separated from the running
executable.
  </P
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H1
CLASS="SECTION"
><A
NAME="AEN133"
>Applications Revisited</A
></H1
><P
>This section looks again at the applications presented in the first section
and discusses some approaches to implement them.
 </P
><P
>The <A
HREF="#RDB"
>externalization</A
> applications can
generally be implemented based on inspection only.
While the DB schema generation can be done with
compile-time introspection only,
the actual externalization/storing/reading requires either runtime
introspection or a facility to inject additional code at compile-time.
The problem where the DB schema generation requires additional
information can be solved with a mechanism like the Java annotations.
 </P
><P
><A
HREF="#CODEANALYSIS"
>Code analysis</A
> can generally be done
using compile-time introspection only.  This poses no specific
problems.
 </P
><P
><A
HREF="#AOP"
>Aspect-oriented programming</A
> can generally
be done using compile-time reflection only.  But it requires not only
introspection but full-fledged modification mechanisms.
This is how most AOP implementations today work, the Java based
using byte code manipulations, and AspectC++ using PUMA.
 </P
><P
>The <A
HREF="#DEVTOOLS"
>runtime development tools</A
>
described in the first section can generally be implemented
using runtime introspection, sometimes with limited modification
facilities such as invocation of functions or manipulation
of object values.
 </P
></DIV
><DIV
CLASS="SECTION"
><HR><H1
CLASS="SECTION"
><A
NAME="FUTURE"
>Future Work</A
></H1
><P
>This paper tried to present some aspects of a reflection facility
in C++.  Actually, most reflection mechanisms can be based on
or implemented using compile-time reflection.  That can probably be realized
using the Metacode approach, for which an official proposal is expected
from Daveed Vandevoorde.
 </P
><P
>Nevertheless, an additional Standard Library interface for runtime reflection,
including compile-time introspection information, should be
defined for C++0x.  Such an interface should probably be based
on the mirror approach.
 </P
></DIV
><H1
><A
NAME="AEN148"
>References</A
></H1
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="EDOBSBIB"
></A
><P
>[eDOBS]&nbsp;<I
>  <A
HREF="http://www.se.eecs.uni-kassel.de/se/index.php?edobs"
TARGET="_top"
>http://www.se.eecs.uni-kassel.de/se/index.php?edobs</A
>.
 </I
>.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="JCRASHERBIB"
></A
><P
>[JCrasher]&nbsp;<I
>  <A
HREF="http://www.cc.gatech.edu/jcrasher/"
TARGET="_top"
>http://www.cc.gatech.edu/jcrasher/</A
>.
 </I
>.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="SABICUBIB"
></A
><P
>[Sabicu]&nbsp;<I
>  <A
HREF="http://www.cs.washington.edu/homes/taoxie/sabicu/"
TARGET="_top"
>http://www.cs.washington.edu/homes/taoxie/sabicu/</A
>.
 </I
>.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="ASPECTCXXBIB"
></A
><P
>[AspectC++]&nbsp;<I
>  <A
HREF="http://www.aspectc.org/"
TARGET="_top"
>http://www.aspectc.org/</A
>.
 </I
>.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="ASPECTJBIB"
></A
><P
>[AspectJ]&nbsp;<I
>  <A
HREF="http://eclipse.org/aspectj/"
TARGET="_top"
>http://eclipse.org/aspectj/</A
>.
 </I
>.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="JAVAANNOTATIONSBIB"
></A
><P
>[Annotations]&nbsp;<I
>  <A
HREF="http://java.sun.com/j2se/1.5.0/docs/guide/language/annotations.html"
TARGET="_top"
>http://java.sun.com/j2se/1.5.0/docs/guide/language/annotations.html</A
>.
 </I
>.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="JDIBIB"
></A
><P
>[Java Debug Interface]&nbsp;<I
>  <A
HREF="http://java.sun.com/j2se/1.4.2/docs/guide/jpda/jdi/index.html"
TARGET="_top"
>http://java.sun.com/j2se/1.4.2/docs/guide/jpda/jdi/index.html</A
>.
 </I
>.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="JAVAREFLBIB"
></A
><P
>[Java Reflection]&nbsp;<I
>  <A
HREF="http://java.sun.com/j2se/1.4.2/docs/guide/reflection/spec/java-reflectionTOC.doc.html"
TARGET="_top"
>http://java.sun.com/j2se/1.4.2/docs/guide/reflection/spec/java-reflectionTOC.doc.html</A
>.
 </I
>.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="BCELBIB"
></A
><P
>[Java ByteCode Engineering Library]&nbsp;<I
>  <A
HREF="http://jakarta.apache.org/bcel/"
TARGET="_top"
>http://jakarta.apache.org/bcel/</A
>.
 </I
>.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="MIRRORSBIB"
></A
><P
>[Mirrors]&nbsp;<I
>  <A
HREF="http://bracha.org/mirrors.pdf"
TARGET="_top"
>http://bracha.org/mirrors.pdf</A
>.
 </I
>.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="PIVOTBIB"
></A
><P
>[The Pivot]&nbsp;<I
>  <A
HREF="http://www-unix.mcs.anl.gov/workshops/DSLOpt/Talks/DosReis.pdf"
TARGET="_top"
>http://www-unix.mcs.anl.gov/workshops/DSLOpt/Talks/DosReis.pdf</A
>.
 </I
>.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="OPENCXXBIB"
></A
><P
>[OpenC++]&nbsp;<I
>  <A
HREF="http://opencxx.sourceforge.net/"
TARGET="_top"
>http://opencxx.sourceforge.net/</A
>.
 </I
>.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="PUMABIB"
></A
><P
>[PUMA]&nbsp;<I
>  <A
HREF="http://ivs.cs.uni-magdeburg.de/~puma/"
TARGET="_top"
>http://ivs.cs.uni-magdeburg.de/~puma/</A
>.
 </I
>.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="ARNESLIBBIB"
></A
><P
>[Arne Adams]&nbsp;<I
>  <A
HREF="http://www.arneadams.com/reflection_doku/index.html"
TARGET="_top"
>http://www.arneadams.com/reflection_doku/index.html</A
>.
 </I
>.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="METACODEBIB"
></A
><P
>[metacode]&nbsp;<I
>  <A
HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2003/n1471.pdf"
TARGET="_top"
>ISO/IEC JTC1/SC22WG21/N1471</A
>.
 </I
>.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="MOPBIB"
></A
><P
>[Meta-Object Protocol]&nbsp;<I
>  <A
HREF="http://www.vollmann.ch/en/pubs/meta/index.html"
TARGET="_top"
>http://www.vollmann.ch/en/pubs/meta/index.html</A
>.
 </I
>.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
></DIV
></BODY
></HTML
>