Well, std::cout is implicitly convertible to void*, and if the compiler also decides it's OK to cast the right-hand side to void*, you'll have a perfectly good pointer comparison (Comeau online also compiles it fine). This just shows why one is recommended to avoid overloading conversion operators.
What exactly makes C++ difficult?
Quote:Original post by visitor
Well, std::cout is implicitly convertible to void*, and if the compiler also decides it's OK to cast the right-hand side to void*, you'll have a perfectly good pointer comparison (Comeau online also compiles it fine). This just shows why one is recommended to avoid overloading conversion operators.
Whoa, didn't know about ostream::operator void* *facepalm*.
As for this, it seems that operator void* is there so you can check whether "a failbit or badbit is set". If you ask me and if I understand it right, this is blatantly bad operator overloading abuse.
On the other hand, this is what makes these work:
Besides, implicit conversion to void* is considered safer than conversion to bool, since void* is good for very few things (as there is not implicit conversion from void* to other pointer types in C++).
A way to avoid some of the issues with implicit conversion is the safe bool idiom.
It looks that C++0x adds explicit conversion operators. Then streams could define an explicit conversion to bool, and it would work implicitly only in boolean contexts.
//getline returns std::cin which is implicitly converted to void* for testingwhile (getline(s, std::cin)) {...}int n;//same hereif (!(std::cin >> n)) { //bad user not inputting a number}if (std::cin >> n) { //good, we have successfully read a number}Besides, implicit conversion to void* is considered safer than conversion to bool, since void* is good for very few things (as there is not implicit conversion from void* to other pointer types in C++).
A way to avoid some of the issues with implicit conversion is the safe bool idiom.
It looks that C++0x adds explicit conversion operators. Then streams could define an explicit conversion to bool, and it would work implicitly only in boolean contexts.
Vast swathes of legacy code that doesn't document the assumptions it was based upon, or which has always been unsafe but has always appeared to work. That's what makes C++ hard.
It's not only C++ of course, but the potential for these kinds of things seems much greater with C++ than any other mainstream language due to the sheer number of language features and quirks.
It's not only C++ of course, but the potential for these kinds of things seems much greater with C++ than any other mainstream language due to the sheer number of language features and quirks.
Quote:For example the Visual C++ compiler will gladly compile and run the following innocent looking program while most others like gcc won't:#include <iostream>int main (int argc, char * const argv[]) { // insert code here... std::cout < "Hello, World!\n"; return 0;}
MSVC8:
warning C4552: '<' : operator has no effect; expected operator with side-effect
MSVC9:
error C2678: binary '<' : no operator found which takes a left-hand operand of type 'std::ostream' (or there is no acceptable conversion) could be 'built-in C++ operator<(const char [15], const char [15])' or 'built-in C++ operator<(void *, void *)' while trying to match the argument list '(std::ostream, const char [15])'
C, and it's descendant C++, is considered a difficult language because unlike many other languages (Algol, Pascal, Ada, Java/C#) it was not designed to stop bad programmers from writing bad programs. It was designed to let good programmers write fast, effective programs.
It is my considerable experience that there are a lot of bad programmers out there.
It is my considerable experience that there are a lot of bad programmers out there.
I'd like to emphasize two things:
1) Very nearly every program crash from native languages is a pointer mistake.
2) Since the mid seventies, about three quarters of all significant security vulnerabilities in software (as tracked by CERT, I believe), are the result of buffer overrun/underrun mistakes.
Real software is complex, and real, very skilled developers make plenty of mistakes when dealing with pointers. Believing that it's "not that hard" isn't just misguided, it's actually dangerous.
1) Very nearly every program crash from native languages is a pointer mistake.
2) Since the mid seventies, about three quarters of all significant security vulnerabilities in software (as tracked by CERT, I believe), are the result of buffer overrun/underrun mistakes.
Real software is complex, and real, very skilled developers make plenty of mistakes when dealing with pointers. Believing that it's "not that hard" isn't just misguided, it's actually dangerous.
Quote:Original post by Promit
I'd like to emphasize two things:
1) Very nearly every program crash from native languages is a pointer mistake.
2) Since the mid seventies, about three quarters of all significant security vulnerabilities in software (as tracked by CERT, I believe), are the result of buffer overrun/underrun mistakes.
Real software is complex, and real, very skilled developers make plenty of mistakes when dealing with pointers. Believing that it's "not that hard" isn't just misguided, it's actually dangerous.
It is also interesting to note that this article mentions only 2 out of 19 major mistakes to be C/C++ specific (namely "Buffer Overflows" and "Format String Problems", otoh null-ptr-deref is also available in C#) (ref: 19 Deadly Sins of Software Security).
C# maybe makes your application less dangerous in those two respects X, but it doesn't prevent you from many other stupid mistakes (while above two are admittedly uber dangerous, they are by far not the only ones): "The Bathroom Wall of Code" is about a snippet of code of crypto, which has spreaded over the whole internet and everybody seems to be using it. But the snippet has a huge and stupid security hole (now included in hundreds of apps), more or less introduced by C#/.net (w.r.t.
Quote:Bregma), because C#/.net did not prevent the initial author to use blatantly stupid parameters for the crypography related classes (and the classes didn't, too).
unlike many other languages (Algol, Pascal, Ada, Java/C#) it was not designed to stop bad programmers from writing bad programs
X: I intentionally said less dangerous (because of the .net-layer) instead of "more stable", because there are many potential-points-of-failure that make your application crash, both in C# and C or C++. And some points are even easier to get right in C++ than in C#.
Because no one seems to have mentioned it yet, I'd like to point the OP to the C++ FAQ Lite. It should be more than enough proof that C++ isn't the easiest language to learn.
Quote:Original post by phresnelTo claim that simply moving to a managed language frees you from security problems would be absurd. But that table actually includes the numbers. If you focus on client applications -- which is a filter I should've mentioned initially -- the buffer overflows are far and away the biggest problem of all.
It is also interesting to note that this article mentions only 2 out of 19 major mistakes to be C/C++ specific (namely "Buffer Overflows" and "Format String Problems", otoh null-ptr-deref is also available in C#) (ref: 19 Deadly Sins of Software Security).
C# maybe makes your application less dangerous in those two respects X, but it doesn't prevent you from many other stupid mistakes [...]
XSS and SQL attacks are of course major problems for web apps, but not really related to this discussion, I think.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
