使用嵌套c++类和枚举的优缺点?

What are the pros and cons of using nested public C++ classes and enumerations? For example, suppose you have a class called printer, and this class also stores information on output trays, you could have:

使用嵌套公共c++类和枚举的优缺点是什么?例如，假设您有一个名为printer的类，这个类还存储关于输出托盘的信息，您可以:

class printer
{
public:
    std::string name_;

    enum TYPE
    {
        TYPE_LOCAL,
        TYPE_NETWORK,
    };

    class output_tray
    {
        ...
    };
    ...
};

printer prn;
printer::TYPE type;
printer::output_tray tray;

Alternatively:

另外:

class printer
{
public:
    std::string name_;
    ...
};

enum PRINTER_TYPE
{
    PRINTER_TYPE_LOCAL,
    PRINTER_TYPE_NETWORK,
};

class output_tray
{
    ...
};

printer prn;
PRINTER_TYPE type;
output_tray tray;

I can see the benefits of nesting private enums/classes, but when it comes to public ones, the office is split - it seems to be more of a style choice.

我可以看到嵌套私有枚举/类的好处，但是当涉及到公共枚举时，办公室是分开的——它似乎更像是一种风格选择。

So, which do you prefer and why?

那么，你更喜欢哪一个，为什么呢?

13 个解决方案

#1

Nested classes

There are several side effects to classes nested inside classes that I usually consider flaws (if not pure antipatterns).

嵌套在类内的类有几个副作用，我通常会考虑它们的缺陷(如果不是纯反模式的话)。

Let's imagine the following code :

让我们想象一下下面的代码:

class A
{
   public :
      class B { /* etc. */ } ;

   // etc.
} ;

Or even:

甚至:

class A
{
   public :
      class B ;

   // etc.
} ;

class A::B
{
   public :

   // etc.
} ;

So:

所以:

• Privilegied Access: A::B has privilegied access to all members of A (methods, variables, symbols, etc.), which weakens encapsulation
• 特权访问:A::B对一个(方法、变量、符号等)的所有成员进行特权访问，这削弱了封装。
• A's scope is candidate for symbol lookup: code from inside B will see all symbols from A as possible candidates for a symbol lookup, which can confuse the code
• A的作用域是符号查找的候选:B内部的代码将看到所有来自A的符号作为符号查找的可能候选，这可能会混淆代码
• forward-declaration: There is no way to forward-declare A::B without giving a full declaration of A
• 前向声明:A::B如果不给出A的完整声明，就没有办法进行前向声明
• Extensibility: It is impossible to add another class A::C unless you are owner of A
• 可扩展性:不可能添加另一个类A::C，除非您是A的所有者
• Code verbosity: putting classes into classes only makes headers larger. You can still separate this into multiple declarations, but there's no way to use namespace-like aliases, imports or usings.
• 代码冗长:将类放入类中只会使头更大。您仍然可以将其分为多个声明，但是没有办法使用名称空间类的别名、导入或使用。

As a conclusion, unless exceptions (e.g. the nested class is an intimate part of the nesting class... And even then...), I see no point in nested classes in normal code, as the flaws outweights by magnitudes the perceived advantages.

作为结论，除非有例外(例如，嵌套类是嵌套类的亲密部分……)而且，我认为在正常代码中嵌套类是没有意义的，因为它的缺陷会被感知到的优点远远超过。

Furthermore, it smells as a clumsy attempt to simulate namespacing without using C++ namespaces.

此外，它闻起来是一种笨拙的尝试，试图在不使用c++名称空间的情况下模拟命名空间。

On the pro-side, you isolate this code, and if private, make it unusable but from the "outside" class...

在支持方面，您隔离了这段代码，如果是私有的，使它不能使用，但是从“外部”类中……

Nested enums

Pros: Everything.

优点:一切。

Con: Nothing.

反对:没有。

The fact is enum items will pollute the global scope:

事实上，enum项目将污染全球范围:

// collision
enum Value { empty = 7, undefined, defined } ;
enum Glass { empty = 42, half, full } ;

// empty is from Value or Glass?

Ony by putting each enum in a different namespace/class will enable you to avoid this collision:

通过将每个enum放在不同的名称空间/类中，您可以避免这种冲突:

namespace Value { enum type { empty = 7, undefined, defined } ; }
namespace Glass { enum type { empty = 42, half, full } ; }

// Value::type e = Value::empty ;
// Glass::type f = Glass::empty ;

Note that C++0x defined the class enum:

注意，c++ 0x定义了类enum:

enum class Value { empty, undefined, defined } ;
enum class Glass { empty, half, full } ;

// Value e = Value::empty ;
// Glass f = Glass::empty ;

exactly for this kind of problems.

正是针对这类问题。

#2

One con that can become a big deal for large projects is that it is impossible to make a forward declaration for nested classes or enums.

对于大型项目来说，一个大问题是不可能为嵌套类或枚举做出正向声明。

#3

If you're never going to be using the dependent class for anything but working with the independent class's implementations, nested classes are fine, in my opinion.

如果除了使用独立类的实现之外，您永远不会使用依赖类，那么在我看来，嵌套类是可以的。

It's when you want to be using the "internal" class as an object in its own right that things can start getting a little manky and you have to start writing extractor/inserter routines. Not a pretty situation.

当您想要使用“内部”类作为对象时，事情就会变得有点麻烦，您必须开始编写提取器/插入器例程。不是一个漂亮的情况。

#4

It seems like you should be using namespaces instead of classes to group like things that are related to each other in this way. One con that I could see in doing nested classes is you end up with a really large source file that could be hard to grok when you are searching for a section.

似乎应该使用名称空间而不是类来分组，就像以这种方式相互关联的东西一样。我在做嵌套类时看到的一个问题是，当你搜索一个区段时，你会发现一个非常大的源文件，这是很难理解的。

#5

There are no pros and cons per se of using nested public C++ classes. There are only facts. Those facts are mandated by the C++ standard. Whether a fact about nested public C++ classes is a pro or a con depends on the particular problem that you are trying to solve. The example you have given does not allow a judgement about whether nested classes are appropriate or not.

使用嵌套公共c++类本身没有优劣之分。只有事实。这些事实是由c++标准规定的。关于嵌套公共c++类的事实是赞成还是反对，取决于您试图解决的特定问题。您给出的示例不允许判断嵌套类是否合适。

One fact about nested classes is, that they have privileged access to all members of the class that they belong to. This is a con, if the nested classes does not need such access. But if the nested class does not need such access, then it should not have been declared as a nested class. There are situations, when a class A wants to grant privileged access to certain other classes B. There are three solutions to this problem

嵌套类的一个事实是，它们具有对它们所属的类的所有成员的特权访问权。如果嵌套的类不需要这样的访问，这就是一个限制。但是如果嵌套类不需要这样的访问，那么它不应该被声明为嵌套类。在某些情况下，当a类想要授予对某些其他类的特权访问时，这个问题有三种解决方案。

1. Make B a friend of A
2. 结交朋友
3. Make B a nested class of A
4. 使B成为a的嵌套类。
5. Make the methods and attributes, that B needs, public members of A.
6. 使B需要的方法和属性成为A的公共成员。

In this situation, it's #3 that violates encapsulation, because A has control over his friends and over his nested classes, but not over classes that call his public methods or access his public attributes.

在这种情况下，违反封装的是#3，因为A可以控制他的朋友和嵌套类，但不能控制调用他的公共方法或访问他的公共属性的类。

Another fact about nested classes is, that it is impossible to add another class A::C as a nested class of A unless you are owner of A. However, this is perfectly reasonable, because nested classes have privileged access. If it were possible to add A::C as a nested class of A, then A::C could trick A into granting access to privileged information; and that yould violate encapsulation. It's basically the same as with the friend declaration: the friend declaration does not grant you any special privileges, that your friend is hiding from others; it allows your friends to access information that you are hiding from your non-friends. In C++, calling someone a friend is an altruistic act, not an egoistic one. The same holds for allowing a class to be a nested class.

嵌套类的另一个事实是，不可能将另一个类A::C作为A的嵌套类，除非您是A的所有者。如果可以将A::C作为A的嵌套类添加，则A::C可以欺骗A，使A获得特权信息;这就违反了封装。这基本上和朋友声明是一样的朋友声明不给你任何特权，你的朋友对其他人隐瞒;它允许你的朋友获取你对非朋友隐瞒的信息。在c++中，称某人为朋友是利他行为，而不是利己行为。允许类是嵌套类也是如此。

Som other facts about nested public classes:

关于嵌套公共类的其他事实:

• A's scope is candidate for symbol lookup of B: If you don't want this, make B a friend of A instead of a nested class. However, there are cases where you want exactly this kind of symbol lookup.
• A的作用域可以用于B的符号查找:如果您不想这样做，请让B成为A的朋友，而不是嵌套类。但是，在某些情况下，您需要的正是这种类型的符号查找。
• A::B cannot be forward-declared: A and A::B are tightly coupled. Being able to use A::B without knowing A would only hide this fact.
• A: B不能是正向的:A和A::B是紧密耦合的。能够使用A::B而不知道A只会掩盖这个事实。

To summarize this: if the tool does not fit your needs, don't blame the tool; blame yourself for using the tool; others might have different problems, for which the tool is perfect.

总结一下:如果工具不适合您的需求，不要责怪工具;责备自己使用工具;其他人可能有不同的问题，对于这些问题，工具是完美的。

#6

paercebal said everything I would say about nested enums.

paercebal说了所有我想说的关于嵌套的枚举。

WRT nested classes, my common and almost sole use case for them is when I have a class which is manipulating a specific type of resource, and I need a data class which represents something specific to that resource. In your case, output_tray might be a good example, but I don't generally use nested classes if the class is going to have any methods which are going to be called from outside the containing class, or is more than primarily a data class. I generally also don't nest data classes unless the contained class is not ever directly referenced outside the containing class.

WRT嵌套类，我常用的和唯一的用例是当我有一个类在操作特定类型的资源时，我需要一个数据类来表示特定于该资源的东西。在您的例子中，output_tray可能是一个很好的例子，但是如果这个类有任何方法可以从包含类外部调用，或者不仅仅是一个数据类，我通常不会使用嵌套类。我通常也不会嵌套数据类，除非所包含的类从未直接引用到包含类之外。

So, for example, if I had a printer_manipulator class, it might have a contained class for printer manipulation errors, but printer itself would be a non-contained class.

例如，如果我有一个printer_manipulation类，它可能有一个包含类来处理打印机操作错误，但是打印机本身是一个非包含类。

Hope this helps. :)

希望这个有帮助。:)

#7

Remember that you can always promote a nested class to a top-level one later, but you may not be able to do the opposite without breaking existing code. Therefore, my advice would be make it a nested class first, and if it starts to become a problem, make it a top-level class in the next version.

请记住，您可以在稍后将嵌套类提升为*类，但是您可能无法在不破坏现有代码的情况下执行相反的操作。因此，我的建议是首先将它设置为嵌套类，如果它开始成为问题，那么在下一个版本中将它设置为*类。

#8

For me a big con to having it outside is that it becomes part of the global namespace. If the enum or related class only really applies to the class that it's in, then it makes sense. So in the printer case, everything that includes the printer will know about having full access to the enum PRINTER_TYPE, where it doesn't really need to know about it. I can't say i've ever used an internal class, but for an enum, this seems more logical to keep it inside. As another poster has pointed out, it's also a good idea to to use namespaces to group similar items, since clogging the global namespace can really be a bad thing. I have previously worked on projects which are massive and just bringing up an auto complete list on the global namespace takes 20 minutes. In my opinion nested enums and namespaced classes/structs are probably the cleanest approach.

对我来说，把它放在外面的一个大问题是它成为全局命名空间的一部分。如果enum或相关类仅适用于它所在的类，那么它是有意义的。因此，在打印机的情况下，包括打印机在内的所有东西都将知道对enum PRINTER_TYPE的完全访问，而它实际上并不需要知道它。我不能说我曾经使用过内部类，但是对于enum来说，将它保存在内部似乎更合理。正如另一个海报所指出的，使用名称空间来分组类似的项目也是一个好主意，因为阻塞全局名称空间确实是一件坏事。我以前曾做过大量的项目，在全局名称空间上创建一个自动完整的列表需要20分钟。在我看来，嵌套的枚举和命名空间类/结构体可能是最干净的方法。

#9

I agree with the posts advocating for embedding your enum in a class but there are cases where it makes more sense to not do that (but please, at least put it in a namespace). If multiple classes are utilizing an enum defined within a different class, then those classes are directly dependent on that other concrete class (that owns the enum). That surely represents a design flaw since that class will be responsible for that enum as well as other responsibilities.

我同意提倡在类中嵌入enum的文章，但在某些情况下，不这样做更有意义(但请至少把它放在名称空间中)。如果多个类使用在不同类中定义的enum，那么这些类直接依赖于另一个具体类(它拥有enum)。这肯定代表了一个设计缺陷，因为该类将负责枚举以及其他职责。

So, yeah, embed the enum in a class if other code only uses that enum to interface directly with that concrete class. Otherwise, find a better place to keep the enum such as a namespace.

所以，如果其他代码只使用enum直接与那个具体类进行交互，那么将enum嵌入到类中。否则，找一个更好的地方保存enum，比如名称空间。

#10

If you put the enum into a class or a namespace, intellisense will be able to give you guidance when you're trying to remember the enum names. A small thing for sure, but sometimes the small things matter.

如果将enum放入类或名称空间中，intellisense将能够在您试图记住enum名称时为您提供指导。的确是一件小事，但有时小事也很重要。

#11

Visual Studio 2008 does not seem to be able to provide intellisense for nested classes, so I have switched to the PIMPL idiom in most cases where I used to have a nested class. I always put enums either in the class if it is used only by that class, or outside the class in the same namespace as the class when more than one class uses the enum.

Visual Studio 2008似乎不能为嵌套类提供智能感知，因此在大多数情况下，我已经切换到PIMPL习惯用法，在这里我曾经有一个嵌套类。我总是将枚举放在类中(如果只由该类使用的话)，或者放在类之外的类中(当多个类使用enum时)。

#12

I can see a con for nested classes, that one may better use generic programming.

我可以看到嵌套类的一个缺点，那就是可以更好地使用泛型编程。

If the little class is defined outside the big one, you can make the big class a class template and use any "little" class you may need in the future with the big class.

如果小类是在大类之外定义的，那么可以将大类作为类模板，并使用将来在大类中可能需要的任何“小”类。

Generic programming is a powerful tool, and, IMHO, we should keep it in mind when developing extensible programs. Strange, that no one has mentioned this point.

通用编程是一个强大的工具，在开发可扩展程序时，我们应该记住它。奇怪的是，没有人提到这一点。

#13

Only problem with nested classes that I bumped into yet was that C++ does not let us refer to the object of the enclosing class, in the nested class functions. We cannot say "Enclosing::this"

我遇到的嵌套类的唯一问题是，c++不允许我们在嵌套类函数中引用嵌套类的对象。我们不能说“封闭::“

(But maybe there's a way?)

(但也许有办法?)