C and C++ distinguish between the language and its implementations (compiler plus runtime). Producing good error messages is the compiler's job, not the language's.
I write compilers as a hobby. Providing good error messages is incredibly difficult—the compiler has a ton of information at hand, but it’s hard to know what’s actually useful to present, largely because you can only guess at the programmer’s actual intent.
And of course C++ harks back to an era where error messages were not considered much of a concern. It took the Clang project for C compilation errors to start improving (including kicking gcc's ass), and C is not the most difficult language to parse/validate.
Depending on how the language works and what it allows you to do, your compiler's error messages can only be so helpful, though. I mean, imagine replacing "C and C++" in your message with "Brainfuck". Error messages would be guaranteed to be very low-level, so won't help you solve the actual higher-level problems.
I'd say a language is bad at error handling if it doesn't let you check if a procedure failed or not. What C does it that it compiles even if you ignore this, which is a different issue. Java, Rust, etc. wouldn't compile if you totally ignored it, but you that doesn't mean you have to do proper error handling, beyond satisfying the compiler/type system.
Yes, but in the cited example of basic_string, providing useful error messages isn’t actually that hard. It would be more interesting to hear an argument about what specific C++ features make providing useful error messages hard (if indeed they do) for which precise reasons, that would warrant the accusation that the language designers (rather than he compiler writers) didn’t pay attention to usability.
Having comprehensible error messages is related to being a simple language, IMO. C++ compile-time errors are notorious for being unreadable. I'm not familiar with the output of what(), but I'd wager that the problem is a consequence of all the abstraction.
Oh please. C and C++ programs can be coded to fail gracefully and "a lot of languages" fail in unpredictable and unfortunate ways and shitty programmers still don't catch those magic errors. This is a matter of crappy engineering, not per se crappy language.
> let the c compiler catch errors, or must I rewrite a full parser?
In the long run you always want to do it specifically for your language, because otherwise giving usable error messages and debugging information becomes impossible.
So is GCC. The point is you still need to look at where the error is because the closest syntactically correct program to what you wrote is probably not the program you wanted to write.
A language which is not error prone will usually lead to a combination of the programmer making less mistakes and the language catching those mistakes the programmer makes (whether at compile-time or runtime, or more problematically attempting to DWIM those mistakes thankfully language design has rather moved away from that very bad idea).
Programmers making mistakes is a fact of life, that C is error-prone is what makes those mistakes into significant and recurring issues.
reply