4 ms·
No, you just allocate enough space to store an extra int at the start for the length, and return a typed pointer to the actual data. Then you need an accessor t
by dreta 10y ago
No, you just allocate enough space to store an extra int at the start for the length, and return a typed pointer to the actual data. Then you need an accessor that checks bounds, if you want safe access. Both of these problems are solved by simple macros.
- AReallyGoodName 10y agoArrays and pointers in C already have that int. That's why sizeof() works. The issue is an extra if statement on every single array and pointer access.
- dbaupp 10y agoThey don't, sizeof is a compile-time constant. On a pointer, sizeof() just reports the size of the pointer itself (i.e. 4 or 8 bytes on most modern platforms), not the size of the data to which it points (and sizeof(*pointer) reports the size of the type to which pointer points, it doesn't know anything about how many values of that type are stored). For an array, the length is known statically (i.e. it's in the type), and so the computation can be done at compile time.
- steveklabnik 10y agoAnd this is such a misconception that it's often cited as a footgun: http://www.cplusplus.com/faq/sequences/arrays/sizeof-array/ http://www.cplusplus.com/faq/sequences/arrays/sizeof-array/ > A beginner will often try something along the lines of size = sizeof( myarray ) (which is incorrect).
- caf 10y agosizeof isn't always a compile-time constant: if it's applied to variably-modified type, it's not (obviously).
- dbaupp 10y agoOh, yes, I'd forgotten about VLAs... Compile-time constant, except for sometimes.
- dbaupp 10y agoSo you want the array to have type foo * ? Ignoring that this doesn't let the compiler help the programmer with arrays (you still have to manually remember to use the accessor, not []), you also have to manually remember which pointers are pointers and which are arrays, and this representation doesn't work for pointing into subsections of an array (a similar problem to C-style strings), nor does it work well for putting arrays on the stack, which means one is forced to allocate every array (both of which mean the safe C is likely slower than the equivalent in Rust or even C++).
- awinter-py 10y agoagree -- inability to do variable-sized arrays on the stack is the root of the problem.
- dbaupp 10y agoI'm not even talking about variably sized arrays, just creating a statically sized one and passing it into functions that take dynamically-sized one. For instance, a read function that fills an existing buffer doesn't care if the buffer is on the heap or on the stack, it only cares that it doesn't overrun the bounds. alloca-style variable arrays is a whole other can of worms of danger and complexity.
- dbaupp 10y agoI'm not even talking about variably sized arrays, just creating a statically sized one and passing it into functions that take dynamically-sized one. For instance, a read function that fills an existing buffer doesn't care if the buffer is on the heap or on the stack, it only cares that it doesn't overrun the bounds. alloca-style variable arrays is a whole other can of worms of danger and complexity.
- PeCaN 10y agoThis is what I really like about Ada. Variable-sized arrays and structs on the stack is easy, safe, and efficient in Ada.
- enriquto 10y ago