The first patch - moves the exception definitions to a new header (IMP/exception). log.h includes this so no other headers have to change directly. As a side effect, exceptions are no longer exported to python. We can revert this easily enough - adds a IMP::Exception base class for all exceptions which stores a string and implements what() so the the string is passed to python - all exceptions (except ErrorException) now require a string (or const char*) in their constructor so that python gets the message - adds a ValueException to thrown when you have out of range values. I was throwing other more awkward ones before
the second patch cleans up comments in the movers and adds methods to set the radius/standard deviation.
As a side note, don't we want IMPDLLEXPORT on Linear? As it is, you end up with two separate copies of the class, on in libimp and one in _IMP. Not catastrophic, but probably not what we want. Such a problem appears to be catastrophic with exceptions :-)
Daniel Russel wrote: > - moves the exception definitions to a new header (IMP/exception). log.h > includes this so no other headers have to change directly. As a side > effect, exceptions are no longer exported to python. We can revert this > easily enough > - adds a IMP::Exception base class for all exceptions which stores a > string and implements what() so the the string is passed to python > - all exceptions (except ErrorException) now require a string (or const > char*) in their constructor so that python gets the message
This is of course the obvious solution (throwing the string away before made the Python interface a bit ugly) but I hadn't done it that way myself because my understanding is that this isn't valid C++. See the log message for this commit: $ svn log -r389 https://svn.salilab.org/imp/trunk
See also the final comment at http://www.thescripts.com/forum/thread63644.html (first Google hit I found for this).
Our current set of compilers seems to accept this code though.
> As a side note, don't we want IMPDLLEXPORT on Linear? As it is, you end > up with two separate copies of the class, on in libimp and one in _IMP. > Not catastrophic, but probably not what we want. Such a problem appears > to be catastrophic with exceptions :-)
$ svn log -r385 https://svn.salilab.org/imp/trunk
I removed it, because MSVC wouldn't compile with it in, precisely because there _isn't_ a copy of the class in libimp - it is never instantiated there. But it is possible that MSVC tricked me again with its cryptic error messages and built-in bugs.
Ben
participants (2)
-
Ben Webb -
Daniel Russel