
David Cournapeau skrev:
Oh, you certainly *can*, as we can use gcc to compile extensions against python built with MS compiler. But there are limitations - with C, those limitations are known, with C++, they become atrocious once you use the C++ runtime (RTTI, exception, etc...). I had to debug some stuff in sparsetools on windows 64 bits a few days ago, and this was horrible because the exceptions are lost between DLL.
Mingw (g++) will statically link its own C++ runtime. DLLs compiled with g++ do not share C++ runtime. This obviously is a problem if you need to propagate an exception from one DLL to another. MS Visual C++ does not have this issue. You get the same issue in C if a DLL statically links its own C runtime, or two DLLs use different shared C runtimes.
I call this a disadvantage :) And having exceptions in a language without gc causes more trouble than it worths IMHO. Exception-safe C++ is incredibly hard to do right.
I'd say exceptipn safe C++ is easy to do right, but C++ textbooks don't teach you how. They generally teach you all the mistakes you can do. And if a book has 'best practices' or 'effective' in the title, it is likely full of BS. The main issue is to never -- ever -- open an allocated reource outside a constructor. That includes calling new or new[]. Always use std::vector instead of new[], unless you have an extremely good reason. Always deallocate resources in a destructor. Objects should always be put on the stack (unless allocated in a constructor), and references should be used instead of pointers. For example, look at wxWidgets, that has an additional Destroy() method in the GUI classes. Destroy() must be called manually. This is a classic C++ mistake. Destroy() is not called automatically, so an exception will mess this up. Sturla Molden
In C, we can achieve almost the same effect using setjmp/longjmp. Is that bad style as well?
The standard way to handle errors in C code using the python API is goto. It works well, and if you need to jump several calls, you can always use python exception mechanism.
cheers,
David _______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev