From: Barry S. <ba...@ba...> - 2015-01-04 17:42:57
|
Version 6.2.6 (4-Jan-2015) * Fix various compiler warning. * Fix incorrect use of NULL. * Fix conversion from (const char *) to (char *) is deprecated warning. Download from https://sourceforge.net/projects/cxx/ Barry |
From: π <sun...@gm...> - 2015-01-05 23:41:23
|
Hello PyCXX people, I recently stumbled upon what I believed to be a minor PyCXX bug regarding allocation for new style classes. http://stackoverflow.com/questions/27662074/how-to-tidy-fix-pycxxs-creation-of-new-style-python-extension-class The link proposes a fix. Amazingly, there is some anonymous engineer on SO who appears to understand every line of the PyCXX source code. My hat off to this individual! The technical complexity of this library has really stretched my mental capacity to its limits. A second concern I have is regarding... http://sourceforge.net/p/cxx/code/HEAD/tree/trunk/CXX/Src/Python3/cxx_extensions.cxx extern "C" PyObject *str_handler( PyObject *self ) { try { PythonExtensionBase *p = getPythonExtensionBase( self ); return new_reference_to( p->str() ); } catch( Py::Exception & ) { return NULL; // indicate error } } There are about 50 functions of the same format and my concern applies to all of them. What if somewhere in the p->str() C++ code an exception happens that is not of type Py::Exception ? I don't think it will be caught. Shouldn't there be an extra 'catch(...)' to catch the remaining errors? I'm not too sure about the second one, the first one does appear to be a bug. π > On 4 Jan 2015, at 17:03, Barry Scott <ba...@ba...> wrote: > > Version 6.2.6 (4-Jan-2015) > * Fix various compiler warning. > * Fix incorrect use of NULL. > * Fix conversion from (const char *) to (char *) is deprecated warning. > > Download from https://sourceforge.net/projects/cxx/ > > Barry > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > _______________________________________________ > CXX-Users mailing list > CXX...@li... > https://lists.sourceforge.net/lists/listinfo/cxx-users |
From: Barry S. <ba...@ba...> - 2015-02-15 16:12:52
|
> On 5 Jan 2015, at 23:41, π <sun...@gm...> wrote: > > Hello PyCXX people, > > I recently stumbled upon what I believed to be a minor PyCXX bug regarding allocation for new style classes. > > http://stackoverflow.com/questions/27662074/how-to-tidy-fix-pycxxs-creation-of-new-style-python-extension-class I'll have to check the memory alloc bug mentioned. If you can isolate the patch I'd appreciate it. There is a lot of clutter in the SO articles. > > The link proposes a fix. Amazingly, there is some anonymous engineer on SO who appears to understand every line of the PyCXX source code. > My hat off to this individual! The technical complexity of this library has really stretched my mental capacity to its limits. If you understand the python internals I think the PyCXX is not so hard to understand. > A second concern I have is regarding... > > http://sourceforge.net/p/cxx/code/HEAD/tree/trunk/CXX/Src/Python3/cxx_extensions.cxx > > extern "C" PyObject *str_handler( PyObject *self ) > { > try > { > PythonExtensionBase *p = getPythonExtensionBase( self ); > return new_reference_to( p->str() ); > } > catch( Py::Exception & ) > { > return NULL; // indicate error > } > } > > There are about 50 functions of the same format and my concern applies to all of them. > > What if somewhere in the p->str() C++ code an exception happens that is not of type Py::Exception ? You mean a C++ exception? That would be a bug in the C++ code which needs to map the C++ exception into a Python Exception. > I don't think it will be caught. > > Shouldn't there be an extra 'catch(...)' to catch the remaining errors? > > I'm not too sure about the second one, the first one does appear to be a bug. > Barry |