C# namespaces are like C++ namespaces.

Quote:-How deep should you nest namespaces? Down to the level of one namespace per class?

Use common sense. In particular, don't stick to a hard-and-fast rule – that's not the way that this should work (it's like asking 'how long should a paragraph be?': anywhere between 1 line and a couple dozen, depending). One namespace per class is a particularly silly idea, though, if you think about it: that extra namespace gains you nothing over just using the class name.

Quote:-Where would you put simple structs/classes that are used in multiple different areas of your program?

Somewhere appropriate. A vector class might go into a Maths namespace. A generic Pair class might go into a Utility namespace.

Quote:-Whats the difference between putting the "using" statement inside another namespace or outside?

Inside will restrict the scope of a using directive (not statement, that's a different thing) to that namespace (up to the maximum of the file in which it is contained).

Quote:-What about inheritance and namespaces?

What do you mean, sorry? Namespaces can't inherit.

Using one or two namespaces per project is quite common. Really, they only exist to prevent name clashes between two identically named classes, such as the timer in System.Windows.Forms and System.Threading.

When making your own namespaces, take a look at how the .NET framework handles them. For example, the System.IO namespace contains everything related to input and output. Also, a general rule (although it's not a law) is that a namespace should not contain less than 5 types; otherwise, it is redundant.

Quote:Original post by MartinMM

Quote:Original post by TheUnbeliever
C# namespaces are like C++ namespaces.

Are they?, i thought c++ namespaces worked like a massive include, and that using namespace std; meant including a lot of unnecessary stuff.

C++ namespaces == C# namespaces (roughly speaking(?))
C++ using namespace std; == C# using System; (or something)

Namespaces are used, as Mike said, to avoid name clashes by grouping related 'things' in roughly logical categories (e.g. In C++, the standard library contains a container called vector – this name might interfere with a maths entity called vector; to distinguish between them, they're placed in namespaces such as std). Anything which is inside a namespace has a fully qualified name (Namespace::Identifier in C++, or Namespace.Identifier in C#) and an unqualified (just plain Identifier in both cases) name. The using directive means that you don't need to use the fully qualified name when you might otherwise.

The problem with using namespace std; in C++ isn't that it includes anything, it's that the standard library's contents are largely in the std namespace (so you'd refer to the vector by its fully qualified name std::vector) to avoid interfering, as described above, with any other code. However, this using directive is telling the compiler to place everything in the std namespace in the global namespace (or something loosely equivalent – I'm not entirely certain of what it does, technically, only the end result) so you risk having std::vector interfere with someMathLibrary::vector.

Quote:

Quote:Inside will restrict the scope of a using directive (not statement, that's a different thing) to that namespace (up to the maximum of the file in which it is contained).

And outside will restrict the scope of the using directive(:)) to that file only?, So if you have one namespace a file then there are no differences?

Hm, I think I was unclear. A using directive's maximum scope is the file it is written in, regardless of the namespace it's inside.

If you put it inside a namespace, then you can further restrict this scope:

Quote:

Quote:What do you mean, sorry? Namespaces can't inherit.

No, that was not what i meant, are there any guiding principles, like inheriting classes are put in a separate namespace, and not in the same namespace as the base class. Or something like that.

In general inheritance and the namespace won't really have any bearing on each other – although the nature of inheritance as describing an 'is-a', or generalization/specialization, relationship, and the nature of a namespace as providing a logical grouping of code (although, really, don't go overboard here – its primary purpose is to stop a single identifier referring to multiple entities) mean that they'll usually go together in a single namespace.