Another advantage of C over Old C++ is that there's one C, defined by one standards document and maybe a few common features that are not standard but reliably present on most compilers and hardware. There isn't a list of features you're theoretically able to use but the compilers don't support (templates in Old C++) or common things you do differently in every implementation.
Pascal figures in this in that the official standard Pascal was basically unworkable as a language, due to features like the size of an array being an obligatory part of its type and the resulting lack of a way to write a function that could handle more than one size of array. Having it be optional, as we see here in C, is really the only way to go unless an array knows its own size and won't let you overstep the bounds.
> Another advantage of C over Old C++ is that there's one C, defined by one standards document and maybe a few common features that are not standard but reliably present on most compilers and hardware. There isn't a list of features you're theoretically able to use but the compilers don't support (templates in Old C++) or common things you do differently in every implementation.
I had to develop with multiple C commercial compilers between 1999 and 2002, across several OS. The code had quite a few #ifdefs because of them.
Are you aware that C11 has optional features?
> Pascal figures in this in that the official standard Pascal was basically unworkable as a language, due to features like the size of an array being an obligatory part of its type and the resulting lack of a way to write a function that could handle more than one size of array. Having it be optional, as we see here in C, is really the only way to go unless an array knows its own size and won't let you overstep the bounds.
The first ISO standard yes, but all Pascal dialects always had feature parity with C, while being more type safe, fast compile times and direct support for modules.
Most of it was made part of the ISO Extended Pascal standard, which most people ignored as the industry cared more about Turbo Pascal compatibility. Both solve your arrays example.
The common complaint that the stronger type checking languages impose performance penalty with arrays bound checking is always wrong, as the compilers allow for it to be turned off.
In both cases it is the problem with standards and vendor differentiation, you seldom get a 100% compliant implementation of any standard.
Your statement seems meaningless. It's possible to have safe code in any language (even assembly language) as long as "everyone on the team plays by the rules." The question is, how hard are the rules to understand and how obvious are deviations from them? C++ has more rules and less obvious behavior when you deviate from them, so it's strictly less safe than C.
The advantage of C++ was always that it enabled (slightly) more rapid development than C.
std::vector isn't "safe." If you're using a std::vector::iterator and someone appends to the end of the vector, your iterator may be invalidated. std::string isn't safe either. It's easy to create references to strings that don't exist any more, by returning a const reference to a string and then later deleting the string. smart pointers aren't safe-- partly because of cycles, partly because of references to smart pointers, partly because you inevitably have to convert them to something else to use them. I've been using C++ for years and I've debugged all these problems.
> I've been using C++ for years and I've debugged all these problems.
Me too, my first C++ compiler was Turbo C++ 1.0.
They are a lot safe than using the C direct pointer manipulation idioms that make it so easy to create insecure code that can explode at any moment.
What STL offers might not be 100% as safe as the Pascal family of languages offer among others, but it sure is a way lot better than using plain C idioms.
The problems you describe are quite easy to spot if a static analyzer is made part of the build.
Comments
And yet using modern C++ it is possible to have safer code than C, if everyone on the team plays by the rules that is.
Personally I would rather use another language in the Pascal family (Turbo Pascal refugee), but it is not always possible to choose.
Another advantage of C over Old C++ is that there's one C, defined by one standards document and maybe a few common features that are not standard but reliably present on most compilers and hardware. There isn't a list of features you're theoretically able to use but the compilers don't support (templates in Old C++) or common things you do differently in every implementation.
Pascal figures in this in that the official standard Pascal was basically unworkable as a language, due to features like the size of an array being an obligatory part of its type and the resulting lack of a way to write a function that could handle more than one size of array. Having it be optional, as we see here in C, is really the only way to go unless an array knows its own size and won't let you overstep the bounds.
> Another advantage of C over Old C++ is that there's one C, defined by one standards document and maybe a few common features that are not standard but reliably present on most compilers and hardware. There isn't a list of features you're theoretically able to use but the compilers don't support (templates in Old C++) or common things you do differently in every implementation.
If only this was true
http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
I had to develop with multiple C commercial compilers between 1999 and 2002, across several OS. The code had quite a few #ifdefs because of them.
Are you aware that C11 has optional features?
> Pascal figures in this in that the official standard Pascal was basically unworkable as a language, due to features like the size of an array being an obligatory part of its type and the resulting lack of a way to write a function that could handle more than one size of array. Having it be optional, as we see here in C, is really the only way to go unless an array knows its own size and won't let you overstep the bounds.
The first ISO standard yes, but all Pascal dialects always had feature parity with C, while being more type safe, fast compile times and direct support for modules.
Most of it was made part of the ISO Extended Pascal standard, which most people ignored as the industry cared more about Turbo Pascal compatibility. Both solve your arrays example.
The common complaint that the stronger type checking languages impose performance penalty with arrays bound checking is always wrong, as the compilers allow for it to be turned off.
In both cases it is the problem with standards and vendor differentiation, you seldom get a 100% compliant implementation of any standard.
Your statement seems meaningless. It's possible to have safe code in any language (even assembly language) as long as "everyone on the team plays by the rules." The question is, how hard are the rules to understand and how obvious are deviations from them? C++ has more rules and less obvious behavior when you deviate from them, so it's strictly less safe than C.
The advantage of C++ was always that it enabled (slightly) more rapid development than C.
What I mean by "everyone on the team plays by the rules." is:
- all pointer access done via smart pointers
- std::vector instead of native arrays
- Use std::vector::at() instead of std::vector::operator[]() unless profiling shows a relevant performance increase
- std:string instead of char*
- References instead of pointers for mutable parameters
If you do C like coding in C++, which is of course possible, then C++'s safety over C gets thrown out of the window.
When I get to decide, the continuous integration build is always done with all warnings enabled, warnings as errors and static analyzers tools.
The developers can do the local build as they prefer, though.
std::vector isn't "safe." If you're using a std::vector::iterator and someone appends to the end of the vector, your iterator may be invalidated. std::string isn't safe either. It's easy to create references to strings that don't exist any more, by returning a const reference to a string and then later deleting the string. smart pointers aren't safe-- partly because of cycles, partly because of references to smart pointers, partly because you inevitably have to convert them to something else to use them. I've been using C++ for years and I've debugged all these problems.
> I've been using C++ for years and I've debugged all these problems.
Me too, my first C++ compiler was Turbo C++ 1.0.
They are a lot safe than using the C direct pointer manipulation idioms that make it so easy to create insecure code that can explode at any moment.
What STL offers might not be 100% as safe as the Pascal family of languages offer among others, but it sure is a way lot better than using plain C idioms.
The problems you describe are quite easy to spot if a static analyzer is made part of the build.