2

Possible Duplicate:
“using namespace” in c++ headers

I'm a c# developer in the WPF world, but I've decided to do all of my Winrt development in C++.

One thing im getting confused over is the use (or not) of using statements in header files (as opposed to typing out the fully qualified type names).

Its so much easier to have using statements in header files. A lot of the Microsoft Winrt samples include using statements in headers which keeps the code clear and easy to read. However, I've been going through the c++ samples in the preview of John Petzolds new book, and he demands that headers be free of all using statements.

I dont understand the pro's and con's, and when I google it I get lots of opposing opinions.

Can anyone give me a definitive explanation of this issue as it related to the Winrt world (im not interested in c++ in other environments)

Thanks

Community
  • 1
  • 1
Dean Chalk
  • 20,076
  • 6
  • 59
  • 90
  • In any environment it is a bad practice because it imports all the symbols in the namespace to every translation unit where you would include the header file.Instead just use fully qualified names or *using namespace declaration* in the source files. – Alok Save Sep 28 '12 at 12:25
  • There is no definitive answer, other than that many C++ developers think that code without namespace prefixes are unclear and hard to read. It takes away the reason for using namespaces at all. – Bo Persson Sep 28 '12 at 12:28
  • I would like to answer this, because I think that there is some good WinRT-specific advice that does not apply to the supposed duplicate (because that deals with C++ in general). Since this question has been closed, I will answer it here in the comments. Please forgive the lack of formatting. The Windows Runtime platform uses [a ton of different namespaces](http://msdn.microsoft.com/en-us/library/windows/apps/br211377.aspx) and a lot of those namespaces have really long names. Whether this is a good things is debatable, but it is what it is. Fully qualifying names everywhere in your code – James McNellis Sep 28 '12 at 17:34
  • is not a viable option (ok: you can do it, but your code will be a mess). I've found it useful to declare a header file (say, "namespaces.hpp") that shortens all of the namespaces. Specifically, I think it's helpful to define a `namespace win { }` and use using directives _in that namespace_ to pull each of the `Windows.*` namespaces that I am using into the `win` namespace. For example, `namespace win { using namespace Windows.UI.Xaml; using namespace Windows.UI.Xaml.Controls; }`. There should rarely be any conflicts (I know of none, and I believe it is intended that platform types have – James McNellis Sep 28 '12 at 17:35
  • unique simple names, even across different namespaces). If there are conflicts, the compiler will tell you and you can easily use using declarations or typedefs to resolve them. In C++/CX, I've also found it useful to include all of the types from `Platform` in that `win` namespace, since those are platform namespaces too. You can do this for other types and namespaces as well. For example, in my test apps I shorten long namespaces like `cxxreflect::reflection` and `cxxreflect::metadata` into a single `cxr` namespace (I do this only in apps, not in the library itself, so that I'm not – James McNellis Sep 28 '12 at 17:38
  • forcing anything on other clients of the library). It is evil, horrible, and wrong to use using directives in a header file _in the global namespace_. But renaming namespaces or aggregating namespaces under another namespace is just fine (and is a good idea, especially when writing code for WinRT, if you want to keep your sanity). – James McNellis Sep 28 '12 at 17:40

1 Answers1

9

In C++, it is very much customary to avoid using namespaces in header files, for several reasons.

Unlike C#, C++ doesn't have a nice tidy module system. Anything you do in a header affects every file which includes it. So if one header has a using namespace, if effectively pollutes not just the header file itself, but all files which include it. That can lead to surprising name clashes.

So in C++, the most common convention is this: never put using namespace in a header. In source files, you can do it if you want to, but many people avoid it even there.

Another reason is that this can actually aid readability:

If I refer to a vector<int>, it's not really clear what that is. It could be any vector class defined anywhere in any of my included headers.

But if I write std::vector<int>, then I know that this is the standard library header. It tells me where a type comes from. I think that makes the code both clearer and more easy to read.

Of course, there are tricks you can use to make this more manageable, if you refer to certain types a lot, or if certain namespaces have long, verbose names.

Long namespace names can be aliased:

namespace foo = VeryLongNamespaceName; 
// now I can do foo::bar instead of VeryLongNamespaceName::bar

or individual names can be imported from a namespace:

using std::cout; 
// now I can refer to `cout` without the std prefix

Of course, it is not a coincidence that C++ developers tend to use flat namespace hierarchies and short namespace names.

Nearly all of the C++ standard library is in the std namespace, which is a bit easier to type than the .NET equivalent. (std::vector<T> vs System.Collections.Generic.List<T>). Short names and a flat hierarchy means that you can actually live without using namespace statements.

Can anyone give me a definitive explanation of this issue as it related to the Winrt world (im not interested in c++ in other environments)

There is no such thing as "the WinRT world" in this context. If you write C++ code in your WinRT application, then you should follow C++ conventinos and best practices. If you write C# code in your WinRT application, then you should follow C# best practices, and so on.

Nowhere do WinRT guidelines state "please disregard everything you would normally do in the language you're using". WinRT is an API, not a language.

As for why Microsoft's samples do otherwise: they're samples. Their goal is to illustrate specific concepts and give you a starting point, and not to teach you to write good code in general. It is assumed that you can take the concepts they illustrate, and fit it into your own code without copying the various shortcuts taken in the samples. Many samples also omit error handling code for the same reason. It's irrelevant for the purposes of the sample, but certainly not irrelevant in a real application.

jalf
  • 243,077
  • 51
  • 345
  • 550