[SciPy-dev] reimplementation of lfilter

Charles R Harris charlesr.harris@gmail....
Wed Sep 23 10:31:10 CDT 2009

On Wed, Sep 23, 2009 at 9:07 AM, Sturla Molden <sturla@molden.no> wrote:

> David Cournapeau skrev:
> > It can be a full rewrite, but still should be sent as patches. If I am
> > the one to review, I would prefer this way. That's especially
> > important to track regressions.
> >
> >
> Well.. I didn't intend this for inclusion in SciPy, at least not in the
> beginning. I needed it for some neuroscience software I am writing.
> > It is a fundamental problem of C++. Different compilers do not
> > propagate exceptions the same way, and that's a problem when different
> > compilers are involved (happens easily when the C and C++ compilers
> > are not the same, for example). That has been a problem on every new
> > platform I have tried to port numpy and scipy to.
> >
> Does this mean we cannot use g++ to compile extensions at all, when
> Python VM is compiled with MSVC? Or does the rule just apply to the
> particular extension, like C and Fortran runtimes?
> I don't like the complexity of C++. But it has some advantages over C
> for scientific computing; notably STL containers, templates for
> generics, the std::complex<> type, and so on. The problem with C++ is
> that it encourages bloat ugly style, and OOP stuff is  etter left in
> Python.
> I personally like exceptions because they remove the need for lot or
> error checking. In C, we can achieve almost the same effect using
> setjmp/longjmp. Is that bad style as well?
The setjmp/longjmp machinery has been used (zeros.c, for instance), but I
thinks it makes the C code less transparent and should be avoided unless the
traditional use of return values is so ugly you can't bear to look at the
code. C really doesn't have very good error handling, that may even be a
feature in a low level language.

It might be useful to think up some way that setjmp/longjmp could be used in
some sort of standard error handling template.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-dev/attachments/20090923/0829c4c8/attachment.html 

More information about the Scipy-dev mailing list