This page is not finished yet

People who want or have to code part of their applications and/or libraries in C should really limit themselves to the clean interfaces provided by Cecil or the external mechanism. This page mentions some facts you should be aware of before you start.

First and above all, SmartEiffel generates one unique type name in the C code for each living type present in the Eiffel code. This type is of the form Txyz where xyz represents the number corresponding to the name of the type, including its parameters in the case of generic types. (More details about this in our research papers). When you compile your application, you can find them in a mangling table, somewhere in the C code, which looks like this:

D 2  T1489 R BOOLEAN_CONSTANT 210,253
A 1  T945  R BIT_CONSTANT 945
A*1  T218  R TAG_NAME 218
A 1  T602  R TYPE_BIT_1 602

But don't use this information ! The mangling table is only valid for one specific compilation of one specific application with one specific compiler and specific libraries...

Indeed, when computing a type code, collisions may occur, and affect this process. Thus, the number (and name) corresponding to each type depends not only on the type name, but also on the order in which they are compiled. That is, on the application and libraries compiled... They also depend on the compilation mode used, and the version of the compiler you're using. So what is T145 now may become T234 the next time you compile...

Consequently, do not, ever, rely on the type numbers in the generated C code, because they are not constant ! (Except for a few ones which have a fixed, hard-coded name). So don't bother writing in your own C code things such as new123 or T456, because the only thing we guarantee in this case is that your code shall break one day or another...

OK, so now you understand why you cannot use type numbers, but you still want to know what those things in the mangling table mean. :)

First, a big caveat. Although it hasn't changed a lot and has been very stable for quite some time now, the mangling table coding may change in the future ! As I'm writing these lines, we have no plans to change it, and we prefer keeping it the way it is. But once again, we do not commit ourselves to the current representation.

A 1  T220  R E_DEBUG 220
A 6  T326  R FIXED_ARRAY[RUN_FEATURE] 389,384,367,352,326,53
D 2  T166  R BOOLEAN_CONSTANT 169,168
A*1  T215  R E_ENSURE 215
A 1  T37   E NATIVE_ARRAY[STRING] 37

Liveness

The first field shows whether the type is Dead or (A)Live, that is whether instances of this type are ever created at run-time. (Ok, it should have been L, instead of A...)

Tagless

When the second character on a line is a star *, it marks an untagged type, that is a type on which there is no late binding but only static calls. Note that the type inference algorithm used in SmartEiffel increases the number of such types.

# of live subtypes

Number of concrete, live descendants of the type (including itself). It is thus the number of items in the last field.

Type mangled name

The type name in the C code. As explained above, the ID number varies.

Reference

Is the type a Reference or an Expanded one?

Full type name

Self-explanatory...

Live subtypes list

A comma-separated list of type IDs listing all the live descendants of the current type (including itself, if it is a live one).