Проблемы обзора перечисления

Для Windows, CaptureStackBackTrace() также опция, которая требует, чтобы меньше кода подготовки конца пользователя, чем StackWalk64() сделало. (Кроме того, для подобного сценария я имел, CaptureStackBackTrace() закончил тем, что работал лучше (более надежно), чем StackWalk64().)

6
задан Anonymous 15 November 2009 в 17:56
поделиться

5 ответов

, если перечисление используется несколькими классами, я бы сказал, что это не совсем так. принадлежат определению одного класса, но в пространстве имен, в котором находятся эти классы.

то есть, если перечисление не передается через один класс конструктору другого, и в этом случае может иметь больше смысла создать экземпляр зависимого от перечисления класс отдельно и передать его в качестве параметра конструктору содержащего класса.

4
ответ дан 8 December 2019 в 03:01
поделиться

Я часто помещаю свои перечисления в пространство имен, чтобы предотвратить различные значения перечисления от загромождения глобального пространства имен. Я думаю, это то, что вы пытаетесь сделать, поместив их в класс. Но если они плохо «вписываются» в класс, пространство имен работает в значительной степени с той же целью:

namespace FooSettings
{
    enum FooSettings
    {
        foo,
        bar
    };
}
typedef enum FooSettings::FooSettings FooSettingsEnum;


int main()
{
    FooSettingsEnum x = FooSettings::foo;
};

У меня есть фрагмент редактора, который строит схему для нового перечисления с учетом только его имени, включая

typedef enum FooSettings::FooSettings FooSettingsEnum;

, в которой создается typedef, поэтому объявлять переменные с типом перечисления будет немного удобнее.

Я подозреваю, что Страуструп сделал бы имена значений перечисления привязанными к перечислению, если бы у него была возможность,

3
ответ дан 8 December 2019 в 03:01
поделиться

Вы должны поместить перечисление вне любого класса, если оно является общим, но вы все равно можете охватить перечисление. Поместите его в пространство имен, чтобы счетчики не «просачивались», загромождая пространство имен вашего проекта:

namespace Project { // you already have this, right? :)
  namespace COLOR { // naming styles differ, use what you like
    enum Color {
      red,
      green,
      blue
    };
  }
  using COLOR::Color; // now you can use the type 'normally'

  // examples:
  struct A {
    Color c;
    A() : c(COLOR::red) {}
  };
  void f(Color c) {
    using namespace COLOR;
    // inside this function, we no longer have to prefix COLOR::
    if (c == green) {
      go();
    }
    else if (c == red) {
      stop();
    }
  }
}
2
ответ дан 8 December 2019 в 03:01
поделиться

Вы можете попробовать переадресовать объявление перечисления следующим образом:

enum MyEnum;
-2
ответ дан 8 December 2019 в 03:01
поделиться

Я использую вариант того, что Майкл и Роджер делаю:

namespace Color
{
   enum Type
   {
      red,
      green,
      blue
   };
};

void paintHouse(Color::Type color) {...}

main()
{
   paintHouse(Color::red);
}

Я нахожу Цвет :: Тип , чтобы быть красивее и более самодоступным, чем Цвет: : Цвет или Цвет :: цвет . Если вы найдете Цвет :: Тип ТОО VLBOSE, вы можете использовать Цвет :: T .

Я не преобразую свои перечисленные значения (то есть I. Color_red ), поскольку пространство имен вокруг Enum эффективно становится префиксом.

Я перестал использовать конвенцию ALL_CAPS для моих выделенных констант, потому что они столкнулись с макросами в библиотеках C (например, NULL). Макросы не считаются определенными им именными пространствами.

8
ответ дан 8 December 2019 в 03:01
поделиться
Другие вопросы по тегам:

Похожие вопросы: