Defensive programming?

This is a discussion on Defensive programming? within the C++ Programming forums, part of the General Programming Boards category; Code: #include <iostream> using std::cout; using std::endl; #include <string> using std::string; using std::getline; This is exactly the kind of thing ...

  1. #46
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    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...

  2. #47
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by Daved View Post
    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.

  3. #48
    Registered User
    Join Date
    Jan 2005
    Posts
    7,319
    >> 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.

  4. #49
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    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::

  5. #50
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,744
    It is of consequence. 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. In this case, some consider the former to have separate benefits, e.g. easier to read code. I personally disagree that those separate benefits exist, and even if one believes they do, that is a personal style choice that should not easily overrule the reduction of bugs.
    Ah, but you do not always have the option of fully qualifying, such as in the example I gave. I think the problem here is that you are targeting the use of using declarations that reduce the need of have to prefix with the namespace name, but other uses of using declarations are "collateral damage" from your general statements.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  6. #51
    Registered User
    Join Date
    Jan 2005
    Posts
    7,319
    >> 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.

Page 4 of 4 FirstFirst 1234
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. help please.. linkedlists/classes
    By swayp in forum C++ Programming
    Replies: 10
    Last Post: 01-18-2005, 04:14 PM
  2. Segmentation fault with structs and char pointers
    By Keybone in forum C++ Programming
    Replies: 20
    Last Post: 01-17-2004, 12:36 PM
  3. Bowling for Columbine
    By Silvercord in forum A Brief History of Cprogramming.com
    Replies: 97
    Last Post: 09-09-2003, 07:48 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21