4 ms·

Kinda? I think the problem is you have to keep the array and its length together and always remember to call the appropriate array functions with the appropria

Kinda? I think the problem is you have to keep the array and its length together and always remember to call the appropriate array functions with the appropriate lengths. This isn't made easier by the fact that many string/array methods have variants that expect (and only respect) null-terminated strings (i.e. where you actually don't keep a length and rely on a terminal null-byte). The language could have decided that the first byte is the length and used that convention in string/array functions, but instead we have the convention you point out that the array is really referenced only by its first element and array-indexes are just sleight-of-hand for pointer addition.

taeric 9y ago
I get that. I'm saying the reason you can't universally have an array type with the length attached as a struct is because of aliasing. Precisely because you couldn't have two arrays use the same values in memory. Otherwise, the allocator couldn't keep track of the memory with an array like reference. Consider, in c, you can have an array and pass it in two parts to two different functions. Each getting passed a different length. You couldn't do that if the array had it's length as an intrinsic property. You could have split the function space into operations that work on parts of an array and those that work on a full array. So, not claiming this as a full blocker. And I don't know which is ultimately better. We know where we are. Seems easy to speculate we could have avoided a lot of errors. I just don't know if I agree it is guaranteed.
- ryanianian 9y ago
  Oh I see what you're saying - you can have `char * x = "foo"` and `char * y = &x[1]` (or something - I forget the exact syntax). That's a very good point! So to be regular you'd need a whole host of other commands to deal with substrings. I guess that makes the point that what they chose is probably correct, but it's still quite disappointing that the stdlib doesn't help more to prevent you from shooting yourself in the foot with pretty common operations and data-types.

taeric 9y ago

I get that. I'm saying the reason you can't universally have an array type with the length attached as a struct is because of aliasing. Precisely because you couldn't have two arrays use the same values in memory. Otherwise, the allocator couldn't keep track of the memory with an array like reference. Consider, in c, you can have an array and pass it in two parts to two different functions. Each getting passed a different length. You couldn't do that if the array had it's length as an intrinsic property. You could have split the function space into operations that work on parts of an array and those that work on a full array. So, not claiming this as a full blocker. And I don't know which is ultimately better. We know where we are. Seems easy to speculate we could have avoided a lot of errors. I just don't know if I agree it is guaranteed.

ryanianian 9y ago
Oh I see what you're saying - you can have `char * x = "foo"` and `char * y = &x[1]` (or something - I forget the exact syntax). That's a very good point! So to be regular you'd need a whole host of other commands to deal with substrings. I guess that makes the point that what they chose is probably correct, but it's still quite disappointing that the stdlib doesn't help more to prevent you from shooting yourself in the foot with pretty common operations and data-types.