As additional information, we tried to do the af_array checks in the CALL macro using templates etc. The problem that we ran into was that there are functions that have arguments as void* / T* and these arguments we're going to the af_array (which is a void*) templated function. So right now, the CHECK_ARRAYS macro is the best solution we found.

Do we really need another name space unified ? Neither the c/cpp API's have any name space like this. The only thing it is encapsulating is that symbol manager class and the checkArrays functions.

Another question is about, why can't we have CHECK_ARRAYS in ArrayFire C-API instead of unified API ? That way, we can add all the checks for af_array in one place. We do not do any af_array check in C-API right now, but if we do add any checks for af_array in future, the checks will become fragmented.

Adding the unified namespace was @umar456's recommendation.

Having check array's in the c-api is of no use. When someone is using that backend by default (instead of going through the unified API), those checks will not do anything except add code. The role of these checks is limited to the unified api.

I think code(checks) fragmentation is much worse issue than having one or two additional statements that doesn't degrade performance.

Sure, the their role as they are written now is limited to unified API. But if we have individual checks in respective backend, we won't need to do this CHECK_ARRAYS in unified API all together. Yes, i think that is possible.

Just to confirm: if I do something like af_mul(a, b) and both arrays are on different devices will it return a AF_ERR_ARR_BKND_MISMATCH now ?

@jramapuram, that is the idea yes.

build arrayfire tegra ci