Re: Questions about __cxa_throw and type_info

[Brian Ellis <nullroute at yahoo dot com>]

> Unfortunately for you our approach is much simpler than handling all
> of C++ -- we only handle Java, which has single inheritance (it is
> more complicated really, but our C++ code doesn't know that), and we
> only handle the subset of exceptions that Java can use.

One of the "black magic" concepts that I plan to introduce is what I currently call "detached derivision". The concept is like a cross between sister-class implementation (thru virtual inheritance) and/or passing a child class type to it's parent templated class. You declare a class deriving detached from it's parent and it is not yet able to be instanced until it is reattached. The detached class may add data members and override virtuals like a sister class. At runtime, the detached class may be reattached to any exposed child (even runtime dynamic classes) of the parent that it was originally detached from. This is roughly something that can be achieved by either of the two mechanisms mentioned above, but at the cost of knowing all manor of types that you will need to sister with or using a template resulting in large amounts of code replication. The implementation of this will both use the virtual inheritance mechanisms to allow extra data members and will augment the
 virtual tables to allow the child to call methods of the unknown super class with out the code replication of the templated mechanism.

>  Also we rely
> on gcj to emit a lot of metadata describing class and vtable layout.

It would be nice to have the compiler emit the all of the metadata. It would certainly save me a lot of parser grief. I have been teaching myself lex/yacc so that I can write a compiler for the language that will produce the byte-code, but when it comes to parsing the c++ headers... there is no need to reinvent the wheel when your's is already a lot rounder than any square wheel I could produce. The only concern that I have with this level of automation is that the dynamic code to be executed may come from untrusted sources and I wish to instill good security practices in the users of this extension language. The best way I can think to accomplish this is to make developers actively think about what they want to expose to extensions and what they want to keep hidden. By forcing them to write interface declarations that will be compiled into metadata and the headers for the exposed classes, I can at least ensure that more thought than just adding an attribute to the class or
 sending a cmdline parameter to the compiler will be forced onto developers.

> Doing this for C++ would be a nice library project IMO, say as an
> adjunct to libffi.  One nice thing about having a standard C++ ABI is
> having higher-level tools to manipulate it.. :-)

Even with a standard C++ ABI, exception header structure and stack frame personality are still platform and implementation specific. Having a library to abstract the details of these would clearly be a best practice in order to keep revisions from breaking my runtime interaction as well as allow others to more easily experiment in these areas. Currently, I accept the fact that I will have to abstract this in my design in order to make this project compatible with other compilers (which will probably make good practice for designing an abstraction library in the first place).

Peanut Gallery> Oh yeah.. and exacly what "other" compilers would I want to make this compatible with.

> In libgcj we only catch the subset of exceptions that are "java-like".
> I looked at this problem a little bit years and years ago but we
> punted on it ... we didn't need the full generality and it looked
> super hard.

A clearly simpler aproach would be to require all exceptions be derived of a common base (std::exception would be a good pick for this), but I specificly want to leave this as framework independent as possible in order to not raise incompatibilities with any other established frameworks (such as the horrifying MFC). If a decision like that were made, I could use simple throw-catch conventions provided by c++. In order to make the interpreter throw or catch arbitrary types without a compile-time understanding of what types it will deal with, I really need to dig deeper than the surface of the throw-catch simantics. Likewise if I were to make this interoperable with other exception types (not even considerred for v1), I would certainly have to implement my own personality function.

- Brian





 
____________________________________________________________________________________
It's here! Your new message!  
Get new email alerts with the free Yahoo! Toolbar.
http://tools.search.yahoo.com/toolbar/features/mail/