[Cython] RFC: an inline_ function that dumps c/c++ code to the code emitter

[Jason Newton]

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

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.

-Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20160823/d6e10f87/attachment.html>