使用嵌套C ++类和枚举的优点和缺点？ [英] Pros and cons of using nested C++ classes and enumerations?

问题描述

使用嵌套的公共C ++类和枚举有什么利弊？例如，假设您有一个名为 printer 的类，并且此类还存储有关输出托盘的信息，您可以：

  class printer 
 {
 public：
 std :: string name_; 
 
枚举TYPE 
 {
 TYPE_LOCAL，
 TYPE_NETWORK，
}; 
 
 class output_tray 
 {
 ... 
}; 
 ... 
}; 
 
打印机prn; 
 printer :: TYPE type; 
 printer :: output_tray tray; 
  

或者：

 code> class printer 
 {
 public：
 std :: string name_; 
 ... 
}; 
 
枚举PRINTER_TYPE 
 {
 PRINTER_TYPE_LOCAL，
 PRINTER_TYPE_NETWORK，
}; 
 
 class output_tray 
 {
 ... 
}; 
 
打印机prn; 
 PRINTER_TYPE类型; 
 output_tray tray; 
  

我可以看到嵌套私有枚举/类的好处，但是当涉及到公共的

那么，你喜欢什么呢？为什么？

解决方案

嵌套类

类中嵌套的类有几个副作用，我通常认为缺陷（如果不是纯反模式）。

让我们想象下面的代码：

  class A 
 {
 public：
 class B {/ * etc. * /}; 
 
 //等
}; 
  

或甚至：

  class A 
 {
 public：
 class B; 
 
 //等
}; 
 
 class A :: B 
 {
 public：
 
 //等
}; 
  

因此：

• 特权访问： A :: B有权限访问A的所有成员（方法，变量，符号等），从而削弱封装。


• A的范围是符号查找的候选者：来自B内部的代码会将A中的所有符号视为符号查找的可能候选，这可能会混淆代码


• 前进声明：没有办法转发声明A :: B而不给出A的全部声明


• 扩展性：除非您是A的所有者，否则不可能添加另一个类A :: C。


• 代码详细程度：标题较大。您仍然可以将此分为多个声明，但没有办法使用命名空间的别名，导入或使用。

作为结论，除非异常（例如嵌套类是嵌套类的一个亲密的部分...甚至...），在正常的代码中嵌套类中没有意义，因为缺陷超过了所感知的优势。 p>

此外，它闻起来是一个笨拙的模拟命名空间而不使用C ++命名空间的尝试。

你隔离这个代码，如果是私有的，使它不可用，但从外部类...

嵌套枚举

优点：一切。

Con：没有。

事实是枚举项目会污染全局范围：

  // collision 
枚举值{empty = 7，undefined，defined}; 
 enum Glass {empty = 42，half，full}; 
 
 //空的是Value还是Glass？ 
  

通过将每个枚举放在不同的命名空间/类中，可以避免此冲突： p>

 命名空间值{enum type {empty = 7，undefined，defined}; } 
 namespace Glass {enum type {empty = 42，half，full}; } 
 
 // Value :: type e = Value :: empty; 
 // Glass :: type f = Glass :: empty;注意C ++ 0x定义了类enum：
 
 $ b 
 
 
 $ b 
 枚举类值{empty，undefined，defined}; 
 enum class Glass {empty，half，full}; 
 
 // Value e = Value :: empty; 
 // Glass f = Glass :: empty; 
  
正是这种问题。
 
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:
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?
解决方案
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'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
forward-declaration: There is no way to forward-declare A::B without giving a full declaration of A
Extensibility: It is impossible to add another class A::C unless you are owner of 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.

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:
// 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:
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:
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.

                        
这篇关于使用嵌套C ++类和枚举的优点和缺点？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！