何时使用名称空间或结构？

Question

I was just reading a little bit on them from http://www.cplusplus.com/doc/tutorial/namespaces/ and it seems like a struct is capable of the same things? Or even a class for that matter. Maybe someone here can better define what a namespace is, and how it differs from a struct/class?

Answer 1

Namespaces and class-types are not capable of the same things. Namespaces are mainly used to group types and functions together to avoid name collisions, while class-types hold data and operations that work on that data.

To just group functions and objects by using a class-types you'd have to make them static:

struct X {
    static void f();
};

Without static you'd have to create instances of the class-types to use them. A namespace is much better suited here:

namespace X {
    void f();
}

Another important thing are using declarations and directives:

namespace X {
    void f();
    void g();
}

void h() {
    using X::f;
    f(); // f() now visible in current scope
    using namespace X;
    f(); g(); // both visible
}

With class-types there simply is no mechanism that allows that.

What class-types give you over namespaces is that you can have multiple instances with differing state - if you need that use a class-type.

Answer 2

Well, seems everyone's going at it, so I'll add my own arguments.

First things first, namespace and struct are completely different beasts: they have different syntax and different semantics.

The obvious:

• a struct introduces a type, you can use as templates argument
• a namespace can be spread in several files

Syntactically:

• both can be "aliased", namespace with namespace ns = mylong::name::space; and struct with typedef mylong::name::Space lilstruct;
• ADL (or Argument Dependent Lookup) is tailored for namespaces

Semantically:

• a namespace only defines a scope for the definition of symbols, which allows to group together objects that work together (classes and free-functions) while isolating them for the rest of the world (name clashes). As such it often represents a logical unit of work within the project (for small projects, there is a single namespace).
• a struct or class defines a logical binding between data and the methods to act upon it, which is the corner stone of encapsulation. It usually has one clear responsability and a number of invariants.

Note that sometimes a struct or class is just used to bind together objects that work together without having any logic, for example struct Person { std::string name, firstName; }; struct Person { std::string name, firstName; }; .

That being said: there is no point in C++ for a struct of static methods. It's just a perversion from Java or C# and their "pure" OO approach. C++ supports free functions, so there is no point not using them, especially since it's better for encapsulation (they don't have access to private/protected parts, so you can't mess up an invariant and they don't depend on the representation of the class either).

Answer 3

When creating your own library, it's normally good practice to namespace all your exported functions and classes.

That way, if someone includes your library, they won't be polluting their namespace, and there is less likelyhood of name clashes.

Answer 4

If it can be done with a namespace, use a namespace.

A struct does much more than defining a scope. It defines a type.

Answer 5

In C++ a struct is exactly the same as a class, except structs are public by default. Classes are private. So whenever you want to group free functions together use a namespace. When you want to group data and functions, use a struct/class, and optionally a namespace around it all.
Notice that If you put your functions in a struct then you would have to have an instance of your struct when you want to call those functions, unless they are static.

Answer 6

If you don't want people to use the "using" feature of C++ with your class, which can be dangerous and is often ill advised in complex code, then go ahead and use struct with statics.

In other words: if your functions should always be referred to with "group::function", then you can box in your users by declaring as a struct.

In addition, and importantly, you can forward-declare structs in older versions of C++. You cannot do this with namespaces until C++ 11.

Consider:

std::string out zip::pack(const std::string &in)
std::string out zip::unpack(const std::string &in)

In this case, requiring users to specify zip:: makes sense. It's a short, specific and informative. And the names of the underlying functions are ambiguous without it. Use a struct with statics.

Consider:

std::string out CorpDataUtils::zipPack(const std::string &in)
std::string out CorpDataUtils::zipUnpack(const std::string &in)

These should certainly be in a namespace. The namespace name is long, and uninformative, probably more to do with the organization of whoever is maintaining it - which is fine... but really it should be a namespace... not a struct.

Answer 7

This is a counter example where using a struct instead of a namespace gives some unexpected benefits.

I wanted to generalise a solution to a 2D problem to K dimensions. The 2D solution was enclosed in a namespace.

Templates to the rescue. I started changing the implementation:

struct Point;

to

template< size_t DIMS >
struct Point;

I needed to template most classes, structs, and functions. That was tedious, repetitive, and error prone. And then I had this mischevios idea. I changed

  namespace KDimSpace {

to

  template< size_t DIMS >
  struct KDimSpace {

and that was pretty much it. I could rip off all template< size_t DIMS > junk inside. This is so much easier - the number of dimensions DIMS is declared only once and used consistently by all types and functions.

And then, there is one more thing - rather than hiding internals of the implementation behind ::detail (sub)namespace there is public: and private: !

There are two annoyances:

• functions have to be marked as static
• it is not possible to define operators (eg operator<< for std::ostream ) because operators cannot be marked as static (and then ADL might get in the way as well).

Bottom line - C++ could be a better language with fewer primitives not more. I would like namespaces to be as close to structs as classes are.