Thread: Defensive programming?

Code:

#include <iostream>

using std::cout;
using std::endl;

#include <string>

using std::string;
using std::getline;

This is exactly the kind of thing that the "C++ Coding Standards" book I referenced earlier warns you not to do. If you put a using statement before an #include statement, you could be causing the very kinds of errors that Daved was talking about. Click on that link and read chapter 59 (then buy the book and read all 101 chapters). Try out some of the examples and you'll never put a using before an #include again.

If you have two options, one which can lead to bugs and another that removes that possibility, then the latter has an advantage over the former.

If all other things were equal then I'd agree, but unfortunately the compiler can't find all the bugs in your program. You can find a lot of bugs with your eyes that the compiler has no clue about; but if there's a lot of extra clutter, you might skip right over it, especially if you're giving your code a quick 'once over' because Product Management wants the product out the door last week...

Originally Posted by Daved

You actually just made my argument for me, even though you misunderstood it. In C++ we prefer to use other solutions over pointers in many cases because pointers are more error-prone. Likewise, a reason to explicitly state the namespace is because not doing so is more error-prone.

I fully agree that pointers should be avoided wherever feasible -- and I'm not arguing that importing entire namespaces via "using namespace" is probably not a good idea. I'm arguing that specifically, the std:: namespace is so well known (or should be) that any errors caused by name conflicts with the standard library should be cast in the "bonehead" category.

I'd happily accept C++ without the "using namespace" mechanism, if they'd put all the std:: stuff back into the global scope, where it should have remained, IMHO.

>> I'm arguing that specifically, the std:: namespace is so well known (or should be) that any errors caused by name conflicts with the standard library should be cast in the "bonehead" category.

Ok, I just disagree. There are a lot of names in the std namespace that I don't know, and I suspect I'm not the only one. In addition, at least one example of std:: helping to avoid an error was the fault of the compiler, not the programmer, and so being intelligent or knowledgable would only help you solve the problem, not avoid it.

I'd happily accept C++ without the "using namespace" mechanism, if they'd put all the std:: stuff back into the global scope, where it should have remained, IMHO.

Wouldn't that be the same as globally saying using namespace std; ?
The global namespace is overflowing with names enough as it is. If anything, they should be moving all the legacy C names into its own namespace, like: old::

>> Ah, but you do not always have the option of fully qualifying, such as in the example I gave.

The "other uses" of using statements are not in question, there are often exceptions to general rules. The swap example is a specific exception that doesn't apply to the question of whether using statements are generally good or bad. You might say that #define's should generally be avoided. This statement is valid despite the fact that include guards should use #defines.