Hi, Robert Bradshaw wrote: > On Jun 26, 2009, at 10:42 PM, Stefan Behnel wrote: >> Danilo Freitas wrote: >>> cdef extern from "foo.h" namespace something: #namespace is optional >> I would prefer seeing from that header line that this block deals >> with C++. >> Enforcing that wouldn't hurt users, but improve readability, and >> make it >> easier to expand the block content to potential future syntax >> extensions that aren't allowed for C definitions. > > I'm not sure what the gain is here. Either the whole file is C++, or > it's not.
For one, the parser would always know that it is starting to parse a C++ block *before* it happens to stumble into a class definition. Then, having a clear indication at the top of a .pxd file that the following are C++ definitions makes it clear to a reader that it cannot be cimported from C code. >>> Also, objects declared inside a C++ class are taken as C types >>> (Python objects not allowed) >> Why not? They'd map to a PyObject*, which Cython code would ref- >> count its >> access to. If you change it from C++ code, you'd just be on your >> own, as >> usual. Same for the C++ destructor, which Cython won't generate for >> you. Call it an advanced feature. > > It is unclear what the semantics of an object member > would be. Would it there be a guarantee that it is set to a non-NULL > increfed value on construction? Does the dectructor have a contract > to decref it? It's probably better to require a specific cast here to > signal from this point on refcounting has to be done manually (either > by the user, or by the C++ library author). Good points. Let's forbid that for the time being. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
