6 ms·
Again the operator overloading thing. Yes, it's true. && might do something different than you might expect if you're a C programmer. If you're a C++ program
by dkarl 16y ago
Again the operator overloading thing.
Yes, it's true. && might do something different than you might expect if you're a C programmer. If you're a C++ programmer, then you know somebody might have overloaded the && operator. Yes, they could do it in some weird and unexpected way. Just like somebody can declare a weird and unexpected macro in C.
Yes, people who define C++ classes you use can screw you with dangerous or incorrect behavior, like throwing exceptions from destructors. Just like people who write C libraries can screw you with dangerous or incorrect behavior.
auto_ptr is not useless. At least, I assume it's good for something. Who knows? If not, who cares? boost::shared_ptr is "poor man's garbage collection," not auto_ptr. If you cite the documented behavior of a type as a huge and unwelcome surprise, then gosh, I know exactly how to avoid surprises like that: read the freaking documentation before you use the type.
Oh, and again with the "I can't tell what this code does." Here's a crazy scenario in C: call a function. Do you know what the code does? No, you don't. How awful! Unless you look at the function you just called, or maybe just glance at its documentation.
Half of these criticisms of C++ boil down to, "It's okay for functions to have unknown behavior that I have to learn about before using them, because I'm used to that, but it's not okay for types to have any kind of unknown behavior, because I'm used to C, where that is not the case."
- dzorz 16y agoActually you can't overload && although you can overload &.
- coliveira 16y ago> It's okay for functions to have unknown behavior that I have to learn about before using them, because I'm used to that, but it's not okay for types to have any kind of unknown behavior, because I'm used to C, It is not an issue of behavior but of understanding. In C++, a large number of things can be happening in a single line: an operator being called, a type conversion, a template instantiation, an overriden function in one of a dozen of classes, a constructor called in some part of the hierarchy, in some namespace... who knows. You have to be smart enough to figure out what is going on in each of these cases. As you code base grows, this makes it increasingly hard to understand what is going on.
- mattgreenrocks 16y agoBy that logic, you shouldn't use any dynamic language, because someone could monkey-patch every function and you'd have no guarantee what exactly was being called. Also, you forgot macros in your list of gripes, as they can stomp on literally ANYTHING indiscriminately, despite being declared far away from the actual invocation point.
- fleitz 16y agoA friend of mine actually encountered #define FALSE 1 in some header file he included from a 3rd party project. It was straight C. I'm not sure why after finding that he decided to file a bug report rather that not touch any of that code.
- asomiv 16y ago#define FALSE 1 is not that uncommon in C because C in its infinite wisdom doesn't have true/false literals so people have to invent those by themselves. Glib goes into great lengths to avoid namespace conflicts so it defines the GBoolean type and G_TRUE/G_FALSE. Whether that really is better than #define TRUE/FALSE, I don't know.
- tmp43522 16y ago#define FALSE 0 is the common one