7 ms·

> #define ARRAY(T,S) T S;size_t S##_length;size_t S##_capacity I don't understand why you don't wrap this in a struct, something like (not tested): #defin

> #define ARRAY(T,S) T S;size_t S##_length;size_t S##_capacity I don't understand why you don't wrap this in a struct, something like (not tested): #define MAKE_ARRAY_T(T) typedef struct array_##T { T data; size_t length; size_t capacity; } array_##T; (This could be generalized for types that don't paste cleanly with ##, requiring the user to specify an extra type name.) This would buy you several advantages: - shallow copies of arrays using = - easier parameter passing - easier declarations due to real type names: array_int my_integer_array;

tines 10y ago
This way you either have to declare every type you want to use this with at file scope (which is fine and some people do this, but it's a little irksome), or not be able to pass them as parameters to functions. Also it doesn't solve the problem of function genericity.
to3m 10y ago
Shallow copies aren't important to me, and after years of using C++ templates and C# generics I've come to quite like having the type where I can see it! As for why I didn't use this approach in general, a couple of reasons: - I often have arrays of pointers. Now you need a second parameter, to give the struct its name... - You need to decide in advance all the possible array types you're going to have, and keep the list up to date. I wanted this to feel a lot more like using std::vector - You can't redeclare a struct, even with the same declaration. So if you have MAKE_ARRAY_T(int) in one header, because your object has an array of int, and MAKE_ARRAY_T(int) in another, because ditto, you can't include both headers from the same file. So again you need to be able to give the type a name - Structs can't be mixed and matched as flexibly as variables. So say you've got MAKE_ARRAY_T(int,Module1Ints) in the header for module 1 and MAKE_ARRAY_T(int,Module2Ints) in the header for module 2 - both are arrays of ints, and you avoid the naming problems I described above. But now you can't use one in place of the other, even when this would make sense It also doesn't help with passing your arrays into your generic array functions, since you don't have a single type that you can pass around. So you're restricted to passing in the 3 individiual pieces, or inlining snippest of code via macro, like mine does. Something I did try in the past was using anonymous structs: #define ARRAY(T) struct { T *p; size_t len, cap; } However, anonymous structs are always different, even if they're structurally equivalent, so... no go. (I also dimly remember Visual Studio not even being able to show you the struct in the debugger!) But I guess trying that out was probably a stepping stone on the way to my thinking of the code I've put here.
- tom_mellior 10y ago
  > It also doesn't help with passing your arrays into your generic array functions, since you don't have a single type that you can pass around. So you're restricted to passing in the 3 individiual pieces, or inlining snippest of code via macro, like mine does. When I did something like this, the type definition macro also defined strongly typed implementations of all the array functions for the given type T. Then a call is a real function call and is only inlined if the compiler chooses to do it. The other points you mention were not problems in the particular application I was working on, but yes, these are interesting trade-offs.

tines 10y ago

This way you either have to declare every type you want to use this with at file scope (which is fine and some people do this, but it's a little irksome), or not be able to pass them as parameters to functions. Also it doesn't solve the problem of function genericity.

to3m 10y ago

Shallow copies aren't important to me, and after years of using C++ templates and C# generics I've come to quite like having the type where I can see it! As for why I didn't use this approach in general, a couple of reasons: - I often have arrays of pointers. Now you need a second parameter, to give the struct its name... - You need to decide in advance all the possible array types you're going to have, and keep the list up to date. I wanted this to feel a lot more like using std::vector - You can't redeclare a struct, even with the same declaration. So if you have MAKE_ARRAY_T(int) in one header, because your object has an array of int, and MAKE_ARRAY_T(int) in another, because ditto, you can't include both headers from the same file. So again you need to be able to give the type a name - Structs can't be mixed and matched as flexibly as variables. So say you've got MAKE_ARRAY_T(int,Module1Ints) in the header for module 1 and MAKE_ARRAY_T(int,Module2Ints) in the header for module 2 - both are arrays of ints, and you avoid the naming problems I described above. But now you can't use one in place of the other, even when this would make sense It also doesn't help with passing your arrays into your generic array functions, since you don't have a single type that you can pass around. So you're restricted to passing in the 3 individiual pieces, or inlining snippest of code via macro, like mine does. Something I did try in the past was using anonymous structs: #define ARRAY(T) struct { T *p; size_t len, cap; } However, anonymous structs are always different, even if they're structurally equivalent, so... no go. (I also dimly remember Visual Studio not even being able to show you the struct in the debugger!) But I guess trying that out was probably a stepping stone on the way to my thinking of the code I've put here.

tom_mellior 10y ago
> It also doesn't help with passing your arrays into your generic array functions, since you don't have a single type that you can pass around. So you're restricted to passing in the 3 individiual pieces, or inlining snippest of code via macro, like mine does. When I did something like this, the type definition macro also defined strongly typed implementations of all the array functions for the given type T. Then a call is a real function call and is only inlined if the compiler chooses to do it. The other points you mention were not problems in the particular application I was working on, but yes, these are interesting trade-offs.