On Tue, Jul 16, 2013 at 11:01 PM, deadalnix <span dir="ltr"><<a href="mailto:deadalnix@gmail.com" target="_blank">deadalnix@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wednesday, 17 July 2013 at 05:12:00 UTC, Timothee Cour wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
what's a non-full C front end? If it's not a real C front end it's gonna<br>
break with certain macros etc. Not good.<br>
<br>
</blockquote>
<br></div>
Macro are processed before parsing? No need for a full C frontend to handle macros.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I see no point in re-implementing a C front end when we can simply use an<br>
existing one to do the job (eg clang). This would also allow to parse C++<br>
just as well.<br>
</blockquote>
<br></div>
When you only need a very limited part of the fronted, it make sense. Here we don't need to parse function body for instance, and we can skip most of semantic analysis (if not all ?).<br>
</blockquote></div><div><br></div><div>you'd still need to parse C files recursively (textual inclusion...), handle different C function calling conventions, different C standards, you'd need a way to forward to dmd different C compiler options (include paths to standard / custom libraries), and eventually people will want to parse C++ as well anyways. That can be a lot of work. Whereas using existing tools takes much less effort and is less error prone.</div>
<div><br></div>