Namespace information compromises the readability in C++

Question

I'm new to C++ and had a background in C. The one thing which is quite difficult for me to adopt is to frequently use scope operator e.g. std:: Well, i'd avoid it usage by putting using namespace std at the start of my source code but a lot of people doesn't use this method as they think this may bite them in future.

Plus, the visual-studio also shows error/warning messages along scope operator e.g.

cannot convert from 'std::vector<int,std::allocator<_Ty>> *' to 'std::shared_ptr<std::vector<int,std::allocator<_Ty>>>'

Though the above message is verbose but its such a pain to read it (?). I think it can be simple to read if it was in this form

cannot convert from 'vector<int,allocator<_Ty>> *' to 'shared_ptr<vector<int,allocator<_Ty>>>'

1) Why everyone is using std::, even for cout, cin, endl ? Why would anyone use the labels for some other purpose anyways?

2) Is their a workaround in Visual studio to not show me error/messages/syntax-highlights with a prefix std:: ?

Answer 1

Although, as pointed out in the comments, code like using namespace std; is considered bad practice, you can avoid repeated use of the namespace prefix in code like std::cout, by specifying individual scoped elements in using statements.

Something like this:

using std::cout;  //
using std::cin;   // You can, from then on, just use 'cout', 'cin' and 'endl'
using std::endl;  //

For very common elements, like those listed in the above code, you can put the relevant using lines in a header file - typically, your 'global' header that you use to build your precompiled header.

Answer 2

For starters there is a difference in name lookup for qualified and unqualified names.

Consider for example the following program.

#include <iostream>

class A
{
private:    
    int x = 10;

public:
    operator int() const { return x; }
    friend void f( const A & )
    {
        std::cout << "f( const A & )\n";
    }
};

void f( int )
{
    std::cout << "f( int )\n";
}

int main() 
{
    const A a;

    f( a );

    ::f( a );

    return 0;
}

The program output is

f( const A & )
f( int )

Secondly using using directives can result in name collisions or selecting a wrong function due to the overload resolution.

Apart of this the code can be less readable because the reader will not know for example whether endl is std::endl or a user defined function defined in some namespace that is included in the name lookup due to numerous using directives.

There are situations when you need to use an explicit or an implicit using directive.

For example if you want to use declarations from the namespace std::placeholders or when you want to declare an inline namespace. But the scope of these directive is usually very limited. Another example is using using declarations. But again try to make their scopes as small as possible.

Answer 3

Inside a limited scope, for example within a function, it's logical to use using namespace std or any other using.

Repeating namespace names is tedious when you can avoid it at no cost. I 've seen lots of code infested with std::, especially when it comes to the usage of std::forward, std::move, std::function, std::thread etc.

C++ keywords like using are there for a reason; Unconditionally saying that "using namespace std is bad" is erroneous.

Answer 4

To answer your 2), I believe the answer is "No, there's no way to change the way VS writes out error messages to strain out all the std::".

The good news is that these error messages used to be much worse. You'd get error messages for all N variations on a given template, and then have to parse out the tiny spec of signal from the ocean of noise. Not fun. Heaven help you if you were using nested templates like std::vector<std::vector<std::string> > >.

So while template error messages can still be a bit verbose, the information presented is actual information, not spam spam spam eggs and spam without the eggs.

Oh, and >> used to always parse as a stream operator, so you had to add spaces between the >s for a nested template. UP HILL, BOTH WAYS!!!