I like your idea in principle, have you thought to use a tool like led/peg parser http://piumarta.com/software/peg/ using a C grammar like http://www.romanredz.se/freesoft.htm#C, you'll have more freedom to express your ideas.
Also maybe you already know this: - http://milgra.com/classc/ - pcc http://pcc.ludd.ltu.se/ has the beginings of a c++ made on top of c uses bison/yacc. - vala https://wiki.gnome.org/Projects/Vala - Class-C source-to-source compiler http://www.milgra.com/classc - https://github.com/ryanashcraft/Classified-C Cheers ! On Fri, Apr 18, 2014 at 12:17 PM, mobi phil <m...@mobiphil.com> wrote: > Hi, > > > I know that this topic was here few times, last time I came with some > questions. > > The goal of this email is both to purpose some simple tcc "meta" extension > and to ask > some further help to implement what I need. > > My intention is to extend C with some features for object (oriented) > programming. > In my previous email about the topic I mentioned that I wanted to > implement those > extensions with macros. Though I invested a lot of time, I realized that > it was rather > a stoic exercise and with the macros will be impossible to implement more > powerful > constructs like type checking. > > After lot of brainstorming, I have a better understanding of what > extensions I would like > to have and how I want to implement them. > > I will basically need 4 constructs: > > 1. a struct like construct, "black". This is the blackbox of the object. > This will be mainly > defined in the source file and holds private objects/members. So far did > not find > a better name. One candidate would be "implementation", but it is also not > really > the implementation etc. > > example: > > black MyType > { > type1 member1; > type2 member2; > type3 member3; > }; > > 2. a struct like construct, "white". Again, did not find a better name, > "interface" could have > been a candidate, but the real interface to the object will be the virtual > methods declared > inside the "white" block + the static methods that are defined outside of > the block. > > white MyType: Object /* inheritance, though there will be no > public/private keywoards for the moment */ > { > type1 aVirtualMethod(); > > type1 member1; /* this is the declaration of on accessor that will be > "bound" to the one with > same name from the /*black*/ > } > > 3. a method declaration and definiton. This will be similar to the C++ > method definition. > > /* in the header file */ > type1 MyType:.aNonVirtualMethod(); > > /* later in the implementation file */ > type1 MyType:.aNonVirtualMethod(); > > note here the usage of the ":." instead of "::" as the semantic is a bit > different than in C++ > > 4. method call > > type1 object; > object..aVirtualMethod(); > > the token here is ".." instead of "." or "->" > This is again has different semantics. But would not bother with details > for the moment. > > Further new constructs are in my mind for fibers, continuations (yes they > will be different) and and. > Decided to call this "babel C", so files will probably have extension > bh/bc (header/implementation) > > The bc file will be translated into pure C by the modified tcc. A > construct like 1. will be translated into > a C struct with some additional part etc + some glue code. (Will not go > into details, but will publish soon the details). > Construct 2 will be also translated into a struc + some glue code, the > same with 3. and 4. > > I studied the tcc parser and compiler bit more in depth. Found more or > less where I should patch. I kept things easy, > (you remember wanted to use some special syntax with @ etc. etc.), so > that my stuff fits easyl > into the parsers logic. > > What I need now and this is the minimum that would be probably nice to see > it going upstream. > My first naiv approach wast to save a pointer in the input buffer and: > -> anything that is normal C syntax, after successful parsing of a > declaration or part of a declaration, > send the input to the output > -> anything that is syntax extension, fill in a kind of template and send > the result to the output. > This task became though a bit complex for me due to the pre-processing. > Got a bit lost with token managemnt, > but probably after further hours could find the solution. Though some > hints would be welcome. > > I got the suggestion to separate the code from original tcc, keep the > parser and implement my code generation. > Not sure that this would make my life easier. Do not think this is a good > idea as the assembly code generation > bits would not disturb me (the part that would be redundant for me). > > My own first question seems to be confusing as it is not easy to ask it > :)... I am rather expecting some hints.. > The second question if you could suggest some basic changes in the parser > and supporting code that > would make life easier to implement such extensions for code generation. > > thanks a lot, > mobi phil > > _______________________________________________ > Tinycc-devel mailing list > Tinycc-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tinycc-devel > >
_______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
