OpenCL interoperability does not work on 64-bit OS

受影響的入口點位於 arrayfire/opencl.py 的第 88 行和第 156 行附近，以及該檔案中其他使用 c_int_t 的位置。先閱讀這些 ctypes 宣告，然後重現 64 位元 Windows OpenCL/PyOpenCL 設定；完成的標準是裝置 ID 以及共用的裝置、內容和佇列值不再溢位，並且互通性正常運作。

Currently the OpenCL interoperability does not work on 64-bit Windows machine. The reason for this is the use of c_int_t which defaults to long on Windows (which on the other hand is 32-bit). This can be problematic with things like device IDs as they can easily go over 2^32/2-1. For example https://github.com/arrayfire/arrayfire-python/blob/master/arrayfire/opencl.py#L88 uses c_int_t, as well as a few other functions in the same file. This can be fixed by replacing the c_int_t with, for example, c_void_ptr_t as it is used with the context. Is there by the way some specific reason why context is treated differently?

There is also another issue. When the context is created by PyOpenCL, the input device, context and queue values are input as python ints in order to use the same context and queue, but on Windows you get <class 'OverflowError'>: int too long to convert errors then. These can be avoided by casting them to, for example, c_int64-types. For example in https://github.com/arrayfire/arrayfire-python/blob/master/arrayfire/opencl.py#L156, replace safe_call(backend.get().afcl_add_device_context(dev, ctx, que)) with safe_call(backend.get().afcl_add_device_context(ct.c_int64(dev), ct.c_int64(ctx), ct.c_int64(que))) (using c_void_p seems to work too).

I haven't tested these changes extensively, but they do seem to get things working on 64-bit Windows. I can provide a PR if needed.