4 ms·
> if you want a dialect of C with arrays that know their length, you can use C++ C++ doesn't have arrays which know their length.
by twic 7y ago
> if you want a dialect of C with arrays that know their length, you can use C++
C++ doesn't have arrays which know their length.
- zokier 7y agoWhat's std::array then? > combines the performance and accessibility of a C-style array with the benefits of a standard container, such as knowing its own size https://en.cppreference.com/w/cpp/container/array https://en.cppreference.com/w/cpp/container/array
- kevin_thibedeau 7y agoThey're objects that mostly behave like arrays. You can't index element two of std::array foo as 1[foo] since it isn't an actual C array.
- saagarjha 7y agoOk, but who actually uses that?
- kevin_thibedeau 7y agoThe point is to demonstrate that std::array isn't an array.
- saagarjha 7y agoOk, fair. But for almost all practical purposes, std::array is an appropriate array replacement.
- kazinator 7y agoWhat makes you so sure that if C got better arrays, those would be arrays, supporting a[i] i[a] commutativity and all? That is predicated on equivalence to *(a + i) where a is a dumb pointer whose displacement commutes.
- pjmlp 7y agoThat is a quirk of C's arrays, no other language besides Assembly allows for that. And even in Assembly, it depends on the CPU flavor which kind of memory accesses are available.
- kazinator 7y agoIt depends entirely on the whims of the assembly language design. Assembly lanuages for the Motorola 68000 could allow operand syntax like like [A0 + offset], which could commute with [offset + A0], but the predominant syntax for that CPU family has it as offset(A0) which cannot be written A0(offset). None of that changes what instruction is generated, just like C's quirk is one of pure syntax that doesn't affect the run-time.
- kazinator 7y agoA Pascal array is just ones and zeros that behave like an array. So is a Fortran array. > You can't index element two of std::array foo as 1[foo] since it isn't an actual C array. That's just a silly quirk of C syntax that is deliberately not modeled in C++ operator overloading. It's not a real capability; it doesn't make arrays "do" anything new, so it' hard to call it an array behavior. It's a compiler behavior, that's for sure. It could easily be added to C++, similarly to the way preincrement and postincrement are represented (which allows that obj++ and ++obj to be separate overloads). T &array_class::operator [] (int index) { // handles array[42] } T &array_class::operator [] (int index, int) { // Fictional!! // handles 42[array] } The dummy extra int parameter would mean "this overload of operator [] implements the flipped case, when the object is between the [ ] and the index is on the left". C++ could easily have this; the technical barrier is almost nonexistent. (I wonder what the minimal diff against GNU C++ would be to get it going.) I suspect that it's explicitly unwanted.
- kazinator 7y agoC++ has features in its syntax so that you can write objects that behave like arrays: support [] indexing via operator [], and can be passed around (according to whatever ownershihp discipline you want: duplication, reference counting). C++ provides such objects in its standard library, such as: std::basic_string<T> and std::vector<T>. There is a newer std::array also.
- pjmlp 7y agoAnd depending on the compiler they can also bounds check, even in release builds, it is a matter of enabling the right build configuration flags.