<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">> I have another idea/iteration to run by you then.  One of your chief<br>
> quibbles, although I don't think it's your underlying one, is Cython must<br>
> understand what's going on.  So how about we support a block of C/C++ code<br>
> as a proper construct.  Same name but now, I guess braces maybe get involved<br>
> (since semicolons do too).  Then to transform (mangle) the nested<br>
> identifiers in accordance with scoping/shadowing rules we pull in the python<br>
> bindings to llvm/Clang to parse that complicated code, work with the AST (or<br>
> further down the rabbit-hole) appropriately and spit it back out.  Obviously<br>
> you could detect and analyze embedded statements to your hearts content to<br>
> decide to do something smart about that (you mentioned exception handling<br>
> and return statement as concerning items).<br>
><br>
> The potential hazards here are that LLVM/Clang is brought in (LLVM is<br>
> already on ~ everybody's linux boxes as a graphics shader dependency) and<br>
> it's [python] api changes somewhat often.  I've used it before with success<br>
> for python driven C++ POD boiler plate (IO, size checks, visitors methods<br>
> etc) autocoding.<br>
><br>
> If you can understand the underlying C/C++ and get over that Cython will<br>
> always run on a C/C++ compiler in our universe,  and make that a feature to<br>
> embrace, not a detail to hide (who actually benefits in the later case?) -<br>
> are you still against the significant convenience - and potentially only way<br>
> to make things work when Cython is not supporting a C++ way of doing things<br>
> (say things aren't finished/working yet)?<br>
<br>
</div></div>That would help solve the analysis, though enormous cost in complexity<br>
(one now has two ASTs one must understand and reconcile, and a huge<br>
amount of C++ knowledge must be baked in to understand the AST (or<br>
even lower levels) and it'd be neigh impossible to do "partial<br>
analysis" for features we don't yet understand, probably harder than<br>
putting them into Cython itself modulo parsing) and making LLVM/Clang<br>
a dependency for Cython is probably a non-starter as well.<br></blockquote><div><br></div><div>Well, one thing occurred to me is that leaning on Clang may be the only way you'll be able to remove/improve the DRY violating Cython side declaration of C/C++ land stuff.</div><div> </div><div>-Jason</div></div></div></div>