It's not a big problem, but it'll be an ugly and invasive amount of bookkeeping to manage these top-level typedefs per type deletion.
On Tue, May 7, 2013 at 1:38 PM, Hannes Röst <hroest_nospam2...@quantentunnel.de> wrote: > Hi Robert > > After some internal discussion, we have not found an obvious way to not have > the extra typedef. Is this a big problem? > > Maybe there are other people on the list that are more fluent in C++ and > could think of a way to do it? > > Greetings > > Hannes > > On 30 April 2013 07:48, Robert Bradshaw <rober...@gmail.com> wrote: >> >> On Fri, Apr 12, 2013 at 8:04 AM, Hannes Röst >> <hroest_nospam2...@quantentunnel.de> wrote: >> > Dear mailing list >> > >> > In the process of developing a rather large Cython project where we wrap >> > the >> > scientific OpenMS library (http://sourceforge.net/projects/open-ms/) >> > using >> > Cython, we have come across an issue with the C++ code that is generated >> > by >> > Cython. The issue is that Cython generates C++ that is not compatible >> > with the >> > Clang compiler. >> > >> > I hope this is the correct mailing list to report this issue since it >> > seems to >> > be a bug in Cython and not in Clang (after some discussion we have >> > concluded >> > that Clang is most likely correct in rejecting the generated code). >> > Since we do >> > not have access to the issue tracker, we hoped posting our issue here >> > would >> > clear up matters. >> > >> > The issue occurs with the following minimal testcase: >> > >> > from libcpp.vector cimport vector as libcpp_vector >> > from cython.operator cimport dereference as deref, preincrement as inc >> > >> > cdef class TestClass: >> > >> > cdef libcpp_vector[float] inst >> > >> > def __iter__(self): >> > it = self.inst.begin() >> > while it != self.inst.end(): >> > yield deref(it) >> > inc(it) >> > >> > When compiled with Cython to C++, it generates C++ that cannot be >> > compiled with >> > Clang (however it seems that gcc and MSVS accept the code). It seems >> > that the >> > same issue with Clang was already discussed here: >> > https://bugzilla.mozilla.org/show_bug.cgi?id=623303 and the conclusion >> > was that >> > Clang is correct in reporting the code as erroneous. >> > >> > In the above case, the invalid C++ code that gets generated is: >> > >> > p->__pyx_v_it.std::vector<float>::iterator::~iterator(); >> > >> > The correct code for the above case would probably be (this is just a >> > suggestion, it compiles with gcc and clang on our machines and our tests >> > run >> > through with it): >> > >> > typedef std::vector<float>::iterator _it; >> > p->__pyx_v_it.~_it(); >> > >> > >> > We have tested it with the 0.18 release as well as the newest 0.19b2 >> > build from >> > github (58131b68dc033fc7ca269d875a2aab2b4e9646a2) and the results were >> > the >> > same. >> >> Thanks for the report. Can you think of a solution that doesn't >> require a special typedef declaration for each type you might want to >> call a destructor on? >> _______________________________________________ >> cython-devel mailing list >> cython-devel@python.org >> http://mail.python.org/mailman/listinfo/cython-devel > > > > _______________________________________________ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
