[Cython] RFC: an inline_ function that dumps c/c++ code to the code emitter
nevion at gmail.com
Tue Aug 23 08:08:47 EDT 2016
> > 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++
> > as a proper construct. Same name but now, I guess braces maybe get
> > (since semicolons do too). Then to transform (mangle) the nested
> > identifiers in accordance with scoping/shadowing rules we pull in the
> > bindings to llvm/Clang to parse that complicated code, work with the AST
> > further down the rabbit-hole) appropriately and spit it back out.
> > you could detect and analyze embedded statements to your hearts content
> > 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
> > 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
> > embrace, not a detail to hide (who actually benefits in the later case?)
> > are you still against the significant convenience - and potentially only
> > to make things work when Cython is not supporting a C++ way of doing
> > (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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cython-devel