The @encode directive returns a const char * which is a coded type descriptor of the various elements of the datatype that was passed in. Example follows:
struct test
{ int ti ;
char tc ;
} ;
printf( "%s", @encode(struct test) ) ;
// returns "{test=ic}"
I could see using sizeof() to determine primitive types - and if it was a full object, I could use the class methods to do introspection.
However, How does it determine each element of an opaque struct?
@Lothars answer might be "cynical", but it's pretty close to the mark, unfortunately. In order to implement something like @encode()
, you need a full blown parser in order to extract the the type information. Well, at least for anything other than "trivial" @encode()
statements (i.e., @encode(char *)
). Modern compilers generally have either two or three main components:
The front end must parse all the source code and basically converts the source code text in to an internal, "machine useable" form.
The back end translates the internal, "machine useable" form in to executable code.
Compilers that have an "intermediate end" typically do so because of some need: they support multiple "front ends", possibly made up of completely different languages. Another reason is to simplify optimization: all the optimization passes work on the same intermediate representation. The gcc
compiler suite is an example of a "three stage" compiler. llvm
could be considered an "intermediate and back end" stage compiler: The "low level virtual machine" is the intermediate representation, and all the optimization takes place in this form. llvm
also able to keep it in this intermediate representation right up until the last second- this allows for "link time optimization". The clang
compiler is really a "front end" that (effectively) outputs llvm
intermediate representation.
So, if you want to add @encode()
functionality to an 'existing' compiler, you'd probably have to do it as a "source to source" 'compiler / preprocessor'. This was how the original Objective-C and C++ compilers were written- they parsed the input source text and converted it to "plain C" which was then fed in to the standard C compiler. There's a few ways to do this:
yacc
and lex
to put together a ANSI-C parser. You'll need a grammar- ANSI C grammar (Yacc) is a good start. Actually, to be clear, when I say yacc
, I really mean bison and flex
. And also, loosely, the other various yacc
and lex
like C-based tools: lemon, dparser, etc...perl
with Yapp or EYapp, which are pseudo-yacc
clones in perl
. Probably better for quickly prototyping an idea compared to C-based yacc
and lex
- it's perl
after all: Regular expressions, associative arrays, no memory management, etc.Note: I have no personal experience using any of these tools to do anything like adding @encode()
, but I suspect they would be a big help.
@Lothar makes a good point in his comment. I had actually intended to include lcc
, but it looks like it got lost along the way.
lcc
C compiler. This is a C compiler that is particularly small, at least in terms of source code size. It also has a book, which I highly recommend.tcc
C compiler. Not quite as pedagogical as lcc
, but definitely still worth looking at.poc
Objective-C compiler. This is a "source to source" Objective-C compiler. It parses the Objective-C source code and emits C source code, which it then passes to gcc
(well, usually gcc
). Has a number of Objective-C extensions / features that aren't available in gcc
. Definitely worth looking at.You would implement this by implementing the ANSI C compiler first and then add some implementation specific pragmas and functions to it.
Yes i know this is cynical answer and i accept the downvotes.
One way to do it would be to write a preprocessor, which reads the source code for the type definitions and also replaces @encode
... with the corresponding string literal.
Another approach, if your program is compiled with -g
, would be to write a function that reads the type definition from the program's debug information at run-time, or use gdb
or another program to read it for you and then reformat it as desired. The gdb
ptype
command can be used to print the definition of a particular type (or if that is insufficient there is also maint print type
, which is sure to print far more information than you could possibly want).
If you are using a compiler that supports plugins (e.g. GCC 4.5), it may also be possible to write a compiler plugin for this. Your plugin could then take advantage of the type information that the compiler has already parsed. Obviously this approach would be very compiler-specific.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With