[C + +] I don't want to see the using namespace xxx sentence in any header file any more (translate)

Source: Internet
Author: User

Transmittal of the original text: I don ' t want to see another "using namespace xxx;" header file ever again

Transfer from http://blog.csdn.net/pleasecallmewhy/article/details/8528702

Here, I have said this without a shy word.

As a developer/team leader, I often recruit new project members and sometimes help others in other groups to interview candidates. As part of the application process, I often ask candidates to write some code, so I've checked quite a bit of code. In the recently submitted C + + code, I noticed a trend in which I always see the following code in any header file:

 
    1. using namespace Std;  

If I use our Code check System (in practice I highly recommend this system) to verify the code, the above line of code will often follow a comment "Timo will not write this." They're right, I really wouldn't write that.

So why do I persuade a lot of C + + textbooks (and maybe not a good thing) to make them think that using the code above is a very bad way? Let's start by looking at what the above code does. In general, it introduces all of the content within the namespace "Std" (or the other by the author using a using call namespace) without exception to the current namespace. Please note that I said "all content", not one or two of the class \ type \ template you want to use. The reason for introducing namespaces at the beginning of a piece of code is to enhance the modularity of the program and reduce naming conflicts. In general, it allows you to write code similar to the following, and to ensure that the compiler can choose the correct implementation:

std::vector<std::string> names;  My_cool_reimplementation::vector<our_internal_stuff::string> Othernames;  

Now, let's say we're trying to reduce the code input and use the using declaration (or, worse, two namespaces are declared) in the code above, as shown in the following code:

std::vector<std::string> names;  My_cool_reimplementation::vector<our_internal_stuff::string> Othernames;  

If the author of this code is lucky, the compiler chooses the correct implementation of the vector, or at least at the initial stage. But after a while, you will encounter some very strange compiler errors. Fortunately, you can find the reasons for these mistakes--I've had a similar problem, and it took me several days to find the cause of this kind of problem. Damn, they're going to waste you a lot of time just because you want to play 5 characters less code.

And, if you use the using declaration in the header file, you will make this kind of problem worse, because the naming conflict problem will sooner or later in a module called very very far away from the unknown, and you may need to check the three-layer call to find out why, a header file contains another direct use The header file of the using declaration can cause the namespace to be contaminated immediately, and any file that uses the namespace will cause such problems if it uses the contents of the Std namespace.

So why can you see in many textbooks that they use the using namespace std? My theory is that it does help to improve the layout of the whole book and reduce some of the visual clutter. In a paper book, you have only a limited amount of space to write text, so you have to make the most of it, plus the code examples in the book are usually simple. On the other hand, different namespace qualifiers bring a lot of visual clutter, which makes it difficult for the reader to judge the author's intentions from the context. When you want to write some efficient code in this time, the above two points are not exactly right, the compiler now most can handle 60-80 words per line (you can try, this is OK). Therefore, do not introduce namespaces in a random place.

What if you are very specific about using a using declaration in a header file? There are other ways we can reduce the need to use a using declaration-you can use one of the following, or a combination of multiple ways.

First, you only need to use typedef. I would suggest that you use this approach, even though I don't often follow my own advice, and I think it's a good way to do it in practice anyway. In fact, there are two benefits of using typedef-he makes a type name more readable, and if you choose a good name, it can make the author's intentions more obvious. Compare the following declaration methods:


Std::map<std::string, long> clientlocations;  typedef std::map<std::string, long> Clientnametozip;  Clientnametozip clientlocations;  

The second declaration-even if it is expanded into two lines-is more intuitive than the first declaration, and it avoids namespace blurring.

Another option is to limit the scope of the using declaration in two ways--just the "using" symbol you want to use, for example:

  
Using Std::string;  

    1. However, throwing this statement into the header file is almost as bad as using the "using namespace", so you should use scopes to limit its visibility to ensure that your using declaration is really only valid where the using declaration is made for the first time. For example, you can restrict the scope of a class declaration in the following ways:


    1. Namespace Bar  {    struct zzz    {      ...    };  }  class Foo  {    using namespace bar;    ZZZ M_snooze; Pulls in Bar::zzz  };  

Alternatively, you can limit the scope of the using to a function directly, for example:

 
    1. void Temp ()  {    using namespace std;    String test = "FooBar";  }  

Either way, you can limit the using scope to the code that needs to use it, rather than putting it in the code's public space. The larger your project is, the more important it is to ensure modularity and minimize unforeseen negative effects.

(go) [C + +] I don't want to see the using namespace xxx sentence in any header file any more (translate)

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.