Hi! first about boost preprocessor: There is this framework called cos, that has some interesting approach to object oriented c. http://ldeniau.web.cern.ch/ldeniau/oopc.html (preciselly http://sourceforge.net/projects/cos/) This framework uses macros similar to BOOST. And wrote from scratch my ones, but what I did was more like in cos.
Unfortunately all went well well until I realized that I need to carry over type information for type safety, and that was impossible with macros. Given an expression (not yet 100% decided about the syntax) $[MyClass]object := @(new, $MyClass); [MyClass] on the left side specifies the type as attribute $MyClass on the right side is a global factory later I want something like $[MyOtherClass]otherObject := @(now, $MyOtherClass, $object) need to carry over (during compilation) the type of $object for type checking (polymorfism etc) the @(....) "decorator" is a function call. (I call decorators all the extensions) Another option is to just pull out the TCC parser into a separate > piece of code. The actual parser code is fairly straightforward, so > once copied into another project/sub-project/file it should be fairly > easy to extend. If your extensions are going to have similar syntax to > existing TCC constructs (e.g. if class/object declarations are similar > to structure declarations) then you should even be able to copy&paste > syntax forms. From that point you would just need to provide the > function that the parser actually calls. I assume that this would also > be a good way to dip your toes into compiler design without jumping > into the deep end all at once. > Indeed, thanks for suggesting, was thinking yesterday after spending 2 hours to hack the tcc... Was trying to understand how to build into the existing tcc source both "direct" compilation using my decorators. As you may have noticed the syntax is a bit special. Uses '@' and '$'. @ for decorators, and $ for referencing decorator instances. (These are supposed to be more than objects) The reason to use these is that the parsing/grammar would be easier and the syntax will be also more visible (though a bit more typing) regards mp
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
