C++ Runtime Defined Classes?

[Steven T. Hatton]

As I was reading through some of the stuff in the Standard, I started to
wonder if there might be reason to define classes in response to runtime
conditions, say, to match some kind of new data record format. It may be
an extremely overelaborate approach to problem solving, but it may also
have arguments in its favor. Does anybody know of a system which can
accept a class definition at runtime, compile it, then instantiate the
class in the running program?

What about runtime template processing?

No, not Emacs. I'm talking C++ here.

 

[Pete Vidler]

As I was reading through some of the stuff in the Standard, I started to
wonder if there might be reason to define classes in response to runtime
conditions, say, to match some kind of new data record format. It may be
an extremely overelaborate approach to problem solving, but it may also
have arguments in its favor. Does anybody know of a system which can
accept a class definition at runtime, compile it, then instantiate the
class in the running program?

[snip]

You would need a compiler on the target system. This is not as difficult
as it sounds -- Windows XP and up have at least the visual C++ .NET 2002
(even 2003, depending on what version of .NET is installed), Linux and
other unices generally have gcc. Or you could just distribute gcc with
your app.

The reason .NET ships with a C++ (and C#, VB.NET, etc) compiler in its
framework is that it takes this precise approach. In Reflection.Emit (I
think it's called) they take a String with the code, which is then
written out to a temporary file, compiled and a pointer to an
instantiated object of that class is returned. I believe -- I'm a little
rusty on the details.

There are two basic problems here:

1) You need a compiler on the platform, or you need to distribute your
own. It must work correctly. You must be able to interface with it
adequately. It must be standard conforming to the extent that you don't
have to worry too much about errors in standard code on every single
platform.

2) You must be able to interface with the generated code. To tell the
truth this is probably the hard part.

Oh, and don't forget that C++ compilers tend to be very slow (by
comparison to C#, for example) so this technique is probably not worth
the effort in the vast majority of cases.

-- Pete

 

[Steven T. Hatton]

Oh, and don't forget that C++ compilers tend to be very slow (by
comparison to C#, for example) so this technique is probably not worth
the effort in the vast majority of cases.

Thanks for the description. What I was thinking about would specifically
leverage MI. I don't know what C#'s object specification looks like, but I
suspect it doesn't provide for nearly as complex a class structure as one
can create in C++. Again, this may be overelaborate for any practical
application. OTOH, there may be practical uses for complex subobject
latices.

 

[Claudio Puviani]

As I was reading through some of the stuff in the
Standard, I started to wonder if there might be
reason to define classes in response to runtime
conditions, say, to match some kind of new data
record format.

There are cases where one might want to do that.

It may be an extremely overelaborate approach
to problem solving, but it may also have arguments
in its favor.

It's just another wrench in the generic programming toolkit. Just one that
C++ doesn't provide.

Does anybody know of a system which can accept
a class definition at runtime, compile it, then instantiate
the class in the running program?
LISP.

What about runtime template processing?
LISP.

No, not Emacs.

LISP works fine without EMACS. Always has.

I'm talking C++ here.

Then no. C++ does no support runtime code creation. What you can do is
programmatically generate the source files, invoke the compiler/linker to
build a shared library/DLL/component and then load/connect to the result.
You'd just better hope you don't need to use that class in the next few
milliseconds.

Claudio Puviani

 

[Steven T. Hatton]

LISP works fine without EMACS. Always has.

Actually, Mathematica smells a lot like Emacs/Lisp. But then so does J***,
not to mention that Mozilla is the offspring of XEmacs, using JavaScript as
Lisp in C atire. All of these tend toward runtime defintion and
instantiation to one degree or another.

Then no. C++ does no support runtime code creation. What you can do is
programmatically generate the source files, invoke the compiler/linker to
build a shared library/DLL/component and then load/connect to the result.
You'd just better hope you don't need to use that class in the next few
milliseconds.

I know it heads off topic, but I'm wondering of anybody knows of research
along these lines. This idea seems to dovetail with the emerging template
metaprogramming school. http://www.boost.org/libs/mpl/doc/

 

[Claudio Puviani]

Actually, Mathematica smells a lot like Emacs/Lisp.

It has a lot of overlap.

But then so does J***,

There isn't even a shred of resemblance between Java and LISP on any level.
If you ever say something like that in a LISP forum, do it anonymously
because someone will track you down and beat you senseless with parentheses.

not to mention that Mozilla is the offspring of XEmacs
Huh?

, using JavaScript as Lisp in C atire.

Great scott! Having a built-in list type does NOT make a language LISP-like!

All of these tend toward runtime defintion and
instantiation to one degree or another.

My copy of the Java language definition must be missing the chapter that
deals with runtime definition of classes.

I know it heads off topic, but I'm wondering of anybody knows of research
along these lines. This idea seems to dovetail with the emerging template
metaprogramming school. http://www.boost.org/libs/mpl/doc/

Template metaprogramming is static. Dynamic type creation is a completely
different field with distinct problems, limitations, and solutions. It could
be implemented by opening access to the VMT (probably through a standard
API) so that you could build new ones or modify existing ones, but this is a
can of worms the size of Shai-Hulud.

Claudio Puviani

 

[Steven T. Hatton]

There isn't even a shred of resemblance between Java and LISP on any
level. If you ever say something like that in a LISP forum, do it
anonymously because someone will track you down and beat you senseless
with parentheses.

I do know one XEmacs maintainer who quipped that Gosling is the epitomy of
evil. But I don't think he would deny Java's origin. The XEmacs
documentation is rather explicit about it.

Great scott! Having a built-in list type does NOT make a language
LISP-like!

There's more to it. I don't recall the details, but I read a discussion of
this a while back. Considering Zawinski and Andreessen were XEmacs
maintainers before starting Netscape Communication, there's more than
likely a connection. It's not just JavaScript either. It's pretty clear
to me the got the idea and knowhow for the event loop at the heart of
Mozilla (Mosaic -> Mozilla) from XEmacs.

My copy of the Java language definition must be missing the chapter that
deals with runtime definition of classes.

JSP's been doing it for quite some time. But there is now a pretty solid
infrastruture for passing soucecode around to be compiled automatically on
remote systems using XML. So the literature says.

Template metaprogramming is static. Dynamic type creation is a completely
different field with distinct problems, limitations, and solutions. It
could be implemented by opening access to the VMT (probably through a
standard API) so that you could build new ones or modify existing ones,
but this is a can of worms the size of Shai-Hulud.

Do you mean to say new templates or new classes being created dynaimcally? I
was thinking about using templates at runtime as, well, templates, and
passing type infromation to them, thus creating new types 'on the fly'