This may sound like C++ has a strong type system, but it's only a little stronger than that of C, if at all.
This may sound like C++ has a strong type system, but it's only a little stronger than that of C, if at all.
You’ve made a few comments now about a language that you don’t seem to actually use or know.
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.
"C++ is to C what lung cancer is to lung" - Unix Haters Handbook