Re:Getting Past C
by dbaupp on Tuesday January 03, 2017 @06:32PM
(#13314316)
So 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++).
[ Parent
| on HN ]
I agree that having to remember is a problem, it's one of the many shortcomings of C that it doesn't let you differentiate between types at compile time.
Pointing into subsections works fine. You just have to create a type for it. This solution doesn't have the same problems as strings because you don't rely on a terminating entry, and it's what languages like Rust or Java do as well.
You can allocate dynamic arrays on the stack in C just fine with alloca(). The only performance cost is when checking bounds, but since it's a dynamic array, it's the same cost you'd pay in Rust.
Creating a type for it, for each type of array, will require exactly the macro array thing I was talking about. And see the sibling comment for how dynamic arrays/alloca isn't relevant, I'm just talking about static arrays. (Dynamic arrays on the stack do have a performance cost, as they get in the way of the compiler's optimiser/code generator: having non-fixed stack frames makes accessing locals annoying.)
Re:Getting Past C
by awinter-py on Tuesday January 03, 2017 @09:24PM
(#13315180)
agree -- inability to do variable-sized arrays on the stack is the root of the problem.
I'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.
What do you mean? Variable-length arrays are OK in C.
Not in C11, they were removed due to security issues and became an optional language feature.
Re:Getting Past C
by awinter-py on Wednesday January 04, 2017 @07:48AM
(#13317782)
oops -- you're right.
https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html
Legal in C99, available in C++ on gcc/clang.
Optional in C11, not accepted in ANSI C++17.