Sorry I've let this linger so long.

I'm going to merge over your Windows build-support changes largely as they are, but I'm going to spend some time re-doing the 64-bit size changes - I think we need to use std::ptrdiff_t for strides in order to support reversed arrays, even if we switch to std::size_t for shapes. And that will be a bit more of a disruptive change, as it means they won't have the same Index Vector typedefs anymore.

I'll also be adding some assert statements to verify that ndarray::Array objects never get created with sizes larger than std::ptrdiff_t's max, as that could cause problems all over the library. I'd be happy to accept a pull request in the future that moved that checking from array creation down to the places where those problems could occur, to allow such arrays to be created and used as long as certain operations were avoided, but for now I don't think that will be worth the extra effort. Note that this should also avoid any problems converting ndarray::Array objects to Python, assuming Py_ssize_t is equivalent to std::ptrdiff_t, as I believe it should be on most modern systems.

Build system changes finally merged. I'll do the integer type changes next (but after the Boost.NumPy integer type changes).

@ChrisLS I think I finally have everything working (as described in my previous comment) and ready to merge to master on branch #37. Would you mind taking a look and verifying that this works for you (especially on Windows)?

Ok, great! :) Sure, I'll have a look at it as well as re-verifying the tests on Windows and Linux

I went through the code and find the changes elegant and well-working. It nearly worked directly with Windows, with one nasty bug. Let's go through it:

1. The build requires m4, which is not by default loaded as tool on Windows. This can, however, be easily achieved by adding env.Tool('m4') after line 36 to SConstruct.

2. The header cxxabi.h is not available on Windows, but is used in views.cc. It is not required on Windows at all, so I just guarded it:

   #ifndef _MSC_VER
   #include "cxxabi.h"
   #endif
   

3. The really nasty bug was in include/ndarray/swig/PyConverter.h: on line 257, you are extracting the value of an unsigned long long from the Python variable. For some reason, this function is broken on Windows (at least on my compiled Anaconda version of Python) and leads to an immediate crash. I just replaced it with the signed counterpart (PyLong_AsLongLong) to have it working flawlessly (of course, only as long as the bounds are preserved). I'm not sure on how to handle this issue best.

With these changes, compilation and tests worked.

Looking forward to have the x64 version from master on Windows! :)

I've put in fixes for all three issues you found, with the last one just really a workaround - I've switched to PyLong_AsLongLong with some additional error checking on Windows only.

Could you verify that this now works for you? And, if you have some time in the future, I may open up a new issue for the PyLong_AsUnsignedLongLong problem and ask you to take a closer look at what triggers it.

Ok, I went over this again, and found your implementation of PyConverter.h clean and safe. There's just one compilation issue: in PyConverter.h, line 265 currently is:

            PyErr_Set(PyExc_OverflowError, "Negative integer in conversion to unsigned");

and should be

            PyErr_SetString(PyExc_OverflowError, "Negative integer in conversion to unsigned");

With that change, everything works as expected!

As much as I'd like to, I don't expect to have the time to dig deeper into the PyLong_AsUnsignedLongLong issue. With some luck, this gets resolved by the Python developers in a future release anyway.

Merged to master!

Once again, sorry this took so incredibly long, and thanks for your contribution!