Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nullptr as default argument results in unreported exception during import #60

Open
mamoll opened this issue Mar 5, 2016 · 3 comments · May be fixed by #406
Open

nullptr as default argument results in unreported exception during import #60

mamoll opened this issue Mar 5, 2016 · 3 comments · May be fixed by #406
Labels

Comments

@mamoll
Copy link

mamoll commented Mar 5, 2016

The code at the bottom can be compiled like so:

clang++ -std=c++11 -I/opt/local/include -I/opt/local/Library/Frameworks/Python.framework/Versions/3.5/include/python3.5m  -shared -o foo.so nullptr_error.cpp -L/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib -lpython3.5 -L/opt/local/lib -lboost_python

When importing the resulting module in Python I see the following error:

>>> import foo
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: initialization of foo raised unreported exception

If I replace nullptr with NULL, then there is no error. This is with Boost 1.59 installed via MacPorts on the latest version of OS X with the latest version of Xcode.

#include <boost/python.hpp>

struct Foo
{
    Foo() : foo_(1) {}
    void setFoo(int * foo = nullptr) { foo_ = foo ? *foo : 1; }
    int getFoo() { return foo_; }
    int foo_;
};

BOOST_PYTHON_MODULE(foo)
{
    boost::python::class_<Foo>("Foo", boost::python::init<>())
        .def("setFoo", &Foo::setFoo, ( boost::python::arg("foo")=nullptr))
        .def("getFoo", &Foo::getFoo)
        ;
}
@ofloveandhate
Copy link

i am getting the same or a similar unhelpful error using python3 when i import if i add bases<BaseT> to a certain class in my library...

initialization of _pybertini raised unreported exception

literally all i add is a bases to my class_, and i cannot import my library any more. this is with boost & boost.python versions 1.66; and Xcode Version 8.0 (8A218a), with

clang version 4.0.0 (trunk 289544)
Target: x86_64-apple-darwin15.6.0
Thread model: posix

my python3 line to compile your example is

g++ -std=c++11 -I/usr/local/include -I/Users/ofloveandhate/anaconda/include/python3.6m  -shared -o foo.so nullptr_error.cpp -L/Users/ofloveandhate/anaconda/lib -lpython3.6m -L/usr/local/lib -lboost_python3-mt

with boost and boost.python installed from homebrew, and some anaconda install on the path.

to check my sanity, i compiled your above test example, and get the same problem, 22 months later. pretty sure it is the same problem as i am experiencing.

if i compile my code with python2 installed at /usr/local/bin which resolves to version 2.7.13 installed from brew using this

g++ -std=c++11 -I/usr/local/include -I/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/include/python2.7  -shared -o foo.so nullptr_error.cpp -L/usr/local/opt/python/Frameworks/Python.framework/Versions/2.7/lib -lpython2.7 -L/usr/local/lib -lboost_python

i get the following much better error message:

RuntimeError: extension class wrapper for base class bertini::Observer<bertini::tracking::AMPTracker> has not been created yet

in fact, compiling your example using python2 yields this error:

TypeError: No to_python (by-value) converter found for C++ type: std::nullptr_t

why does python2 yield much better error reporting?
is there a way to make the python3 error message more helpful? what are the circumstances in which this particular error can be generated?

@ofloveandhate
Copy link

i again encountered this just now (feb 10 2018). i got

initialization of _pybertini raised unreported exception

upon import of my "successfully" built library. and the issue was that i had not yet exposed an enum. would have been clearly reported by python2, not with python3.

@dfaure-kdab
Copy link

dfaure-kdab commented Mar 19, 2021

I think the lack of precise error reporting was fixed in #280.
But I'm not sure if the problem with nullptr was fixed.

@huangqinjin huangqinjin linked a pull request Dec 12, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants
@stefanseefeld @ofloveandhate @dfaure-kdab @mamoll and others