|
|
|
|
|
|
by alok99
2118 days ago
|
|
|
Of course a C-style array in C++ doesn't have a defined end. It doesn't have an end in C either. But in C++ you don't need to be using those anyway. Part of the issue is that, while you can use the usual C idioms in C++ (e.g. a function takes an array and its length as arguments), you don't need to, especially if you're using C++ correctly. This is one of the points of the article. Like hellofunk said, this has nothing to do with the type system. But the solution to what you're talking about is fundamental C++: use the standard library. |
|
|
The safety-critical real-time embedded systems where strong static typing would be most useful often don't have the standard library available. Even in C it's not unusual to need to justify every line of code in the final product, which precludes linking against an all-inclusive libc—at best you might get a vetted subset. The design constraints, too, are often incompatible: "no vararg functions" (printf), "no recursion" (qsort/bsearch), "no dynamic memory allocation" (malloc). Where C++ is allowed it is often with additional restrictions like "no RTTI" and "no exceptions" which would rule out large portions of the STL, including most collection types. By the time you take all these coding standard issues into account you generally find that you're writing in a novel language which is just enough like C++ to cause confusion. C++ programming for these environments is not like the C++ which is taught in schools or practiced in other fields. There is a lot to unlearn.