C++ good coding style - always fully qualify library types?

Question

What is generally considered good coding style in C++ where you use types from the standard library? For example, if I have a using namespace std; directive would you still expect to see library types fully qualified like so: std::string or is it acceptable to just use string as the type identifier?

If you do fully qualify, can you expain the rationale behind it?

Answer 1

I'd prefer using:

using std::string;
string whatever;

than fully bringing the namespace in.

In any case library developers should avoid type names that conflict with the standard ones although string probably is quite common.

For libraries other than standard I like to qualify if the nesting namespaces is not too long, if it is just typedef it to a meaningful name that includes the library name or something like that.

Answer 2

Generally I will fully qualify namespaces instead of using using namespace x mostly when I deal with header files. Source files may not want to have that namespace assumed and you shouldn't force it on the source files that include your header file.

I do both using namespace x and fully qualify namespaces depending on a personal judgement call about if I will re-use the type multiple times or not in source files.

Answer 3

fully qualify in header files. import the namespace in the .cpp files.

keeps the global namespace from being cluttered by a simple #include

Answer 4

namespace is basically introduced to minimize conflicts symbol names such as function, class, and variables. It is okay that you just use string than std::string unless your own library has string in its own space. I'm virtually not using very common namespace like std.

Answer 5

Totally subjective question: I would say acceptable to just use string. IDE/compiler are clever enough to find out what you mean. If you have objects with the same name, for example 2 string types. Then you have a different problem because the compiler won't know what you mean AND the coder won't know what you mean.

Other reason to not use library names is because of cluttering the code: In C# system.xml.xmltextreader is just overkill. XmlTextReader is enough to under stand what it is. Where it's located is almost never the issue

Answer 6

I do tend to adhere to two rules:

• In header files, you want to qualify type names with the full namespace and never, ever want to put something like using namespace std; as this can/will cause interesting problems due to unexpected naming conflicts that you will need to track down at 1am.
• In implementation files, I do tend to pull in symbols I use from other namespaces using using std::string; or similar. Actually, I'm not a 100% consistent with this as I often don't pull in the std namespace, but do pull in the project namespaces but that's personal preference. Never, ever put using namespace somethingorother; above any #include, though.

Answer 7

In general, i'd prefer (1) to using directive like using std::string; string hello; as what Jimenez noted previously; (2) i also use a anonymous namespace, subsequently use the using namespace directive to import all names into my anonymous namespace like this namespace { using namespace std; // or using std::string string blah_blah_blah; }

Answer 8

Just for what it's worth, there are a few things you can do by pulling a namespace with a using directive that you can't do by qualifying names. The canonical example is probably writing a generic sort function. If a swap has been defined for the type being sorted, you want to use that, but if it doesn't have a swap of its own, you want to use std::swap.

To accomplish this, you can write your code like:

using namespace std;
// ...
template <class T>
void my_sort(std::vector<T> &x) {
    // ...
    if (x[j] < x[k])
        swap(x[j], x[k]);

Now, if there's a swap in the namespace of whatever type is being sorted, it'll be found by argument dependent lookup. If there's not, std::swap will be found because you've made it visible with the using directive.

Answer 9

The whole point should be to avoid confusion and generate clear code. Omitting namespaces can in some cases obfuscate the origin of a function or class, but adding always full namespaces can become unbearable.

• Avoid using namespace in header files
• Use using namespace in source for "obvious" libraries (e.g. std, or the library to test in a test program)
• You can alias namespaces in your source to keep it short and readable:

Example

namespace fs = boost::filesystem;
bool fileExists = fs::exists(fs::path(filePath));

EDIT, for completeness: using namespace in header files pollutes source files with imported namepaces in a non-obvious way ('nuf explanations of this already in this thread).

Answer 10

I always fully qualify within headers. I never put "using..." statements in headers.

My preference is to fully qualify in implementation files as well, however if the organization standard is to incorporate "using..." statements within the implementation files I will do so,

Answer 11

If you do not fully qualify, you will have great hassle when moving inline methods from headers to CPP files or vice versa, and you definitely want one style across your projects.

Otherwise it's no problem, sometimes I qualify despite existing using statement. In headers it is a problem, Unless it is within scope:

// somefile.h
namespace VisionMap
{
     namespace X
     {
         using namespace Y;   // Does not impact the header's user, 
                              // as would if it was in the global scope.
     }
}