Здравствуйте.

Вопрос по дизайну и правилам хорошего тона.

До недавних пор всё время придерживался политики "любой литерал в коде должен быть представлен в виде соответствующего макроса, добавленного в предкомпиляционный заголовочный файл или в какой-нибудь common.h". Делал я так даже в том случае, если контекст использования данной константы (по крайней мере, на текущий момент) сильно ограничен (например, она используется лишь внутри одной функции / класса / etc). С недавних пор решил поступать иначе — заводить константные объекты внутри этих самых модулей:

void foo()
{
    const int SOME_CONSTANT_VALUE = 0;
    // ...
}

class Foo
{
public:
    Foo() : SOME_CONSTANT_VALUE(0) {}

private:
    const int SOME_CONSTANT_VALUE;
};

Такой вариант мне тоже не очень нравится. Например, в классах, при наличии довольно большого кол-ва констант, будет(ут) довольно некрасивый(ые) конструктор(ы):

class Foo
{
public:
    Foo()
    : SOME_CONSTANT_VALUE(0)
    , ANOTHER_CONSTANT_VALUE(0.0)
    , YET_ANOTHER_CONSTANT_VALUE(0.0)
    , SOME_CONSTANT_VALUE_AGAIN(0.0) {}

private:
    const int SOME_CONSTANT_VALUE;
    const double ANOTHER_CONSTANT_VALUE;
    const double YET_ANOTHER_CONSTANT_VALUE;
    const double SOME_CONSTANT_VALUE_AGAIN;
};

Да, с delegating costructors из C++11 такое можно написать всего лишь в одном конструкторе, но особо положения дел это не меняет, на мой взгляд.

Более того, когда все константы вынесены в отдельный заголовочный файл, их проще находить и редактировать. При чтении же конкретного модуля, я думаю, не составит труда перейти на определение символа под курсором.

Да и смотрится это как-то, честно говоря, странно — вроде и член класса, но при этом константа. Не называть же объект как-нибудь _SOME_CONSTANT_VALUE, чтобы подчеркнуть и то, и другое?

Как Вы поступаете в подобных случаях?

Здравствуйте, FrozenHeart, Вы писали:

FH>Как Вы поступаете в подобных случаях?

использую enum внутри класса.
ЗАГЛАВНЫЕ_БУКВЫ применяю исключительно для макросов.

Здравствуйте, FrozenHeart, Вы писали:

FH>

FH>class Foo
FH>{
FH>public:
FH>    Foo() : SOME_CONSTANT_VALUE(0) {}

FH>private:
FH>    const int SOME_CONSTANT_VALUE;
FH>};
FH>

FH>Такой вариант мне тоже не очень нравится.
Ну так действительно делать не имеет большого смысла. Ведь если член имеет одно и то же значение для всех экземпляров класса, то незачем его хранить в каждом из них:

class Foo {
    static const int SOME_CONSTANT_VALUE = 0;
};

И на конструкторы это никак теперь не влияет.


FH>Более того, когда все константы вынесены в отдельный заголовочный файл, их проще находить и редактировать. При чтении же конкретного модуля, я думаю, не составит труда перейти на определение символа под курсором.
Ну есть константы на века, а есть константные параметры, через которые настраивается поведение программы, и которые-таки иногда меняются. Вполне допустимо, что первые определены максимально близко к месту использования, а вторые собраны где-то в отдельном файле в библиотеке. И так, и так приходится делать.

Здравствуйте, FrozenHeart, Вы писали:

FH>Как Вы поступаете в подобных случаях?
Зависит от логики. Иногда const, иногда enum, иногда лучше прямо в коде литерал (есть случаи когда литерал более понятен читающему, чем длинное_мнемоническое_имя_важной_константы).
Правило всегда одно, компилятору пофиг, а программу будут читать люди и она им должна быть понятна.

Здравствуйте, FrozenHeart, Вы писали:

'static const'

но для целочисленных все же предпочитаю enum.

Здравствуйте, niXman, Вы писали:

X>но для целочисленных все же предпочитаю enum.

enum вместо static const <type> — это грязный хэк, доставщхийся нам со времён компиляторов, не умеющих инициализировать константные переменные по месту объявления.

Здравствуйте, VladFein, Вы писали:

X>>но для целочисленных все же предпочитаю enum.

VF>enum вместо static const <type> — это грязный хэк, доставщхийся нам со времён компиляторов, не умеющих инициализировать константные переменные по месту объявления.

static const double?

Здравствуйте, VladFein, Вы писали:

VF>enum вместо static const <type> — это грязный хэк, доставщхийся нам со времён компиляторов, не умеющих инициализировать константные переменные по месту объявления.
как скажешь. даже спорить с тобой не стану.

Здравствуйте, night beast, Вы писали:

NB>Здравствуйте, VladFein, Вы писали:

X>>>но для целочисленных все же предпочитаю enum.

VF>>enum вместо static const <type> — это грязный хэк, доставщхийся нам со времён компиляторов, не умеющих инициализировать константные переменные по месту объявления.

NB>static const double?

enum { f = 3.14; } ???

Здравствуйте, niXman, Вы писали:

VF>>enum вместо static const <type> — это грязный хэк, доставщхийся нам со времён компиляторов, не умеющих инициализировать константные переменные по месту объявления.
X>как скажешь.
Я именно так и сказал.

X>даже спорить с тобой не стану.
А что так? Не уважаешь???

Здравствуйте, VladFein, Вы писали:

VF>enum { f = 3.14; } ???
1. и какой компилятор такое компилирует?
2. точку с запятой не там поставил.
3. не ведаешь что творишь.

Здравствуйте, niXman, Вы писали:

VF>>enum { f = 3.14; } ???
X>1. и какой компилятор такое компилирует?

Вырвано из контекста. Это был мой (саркастический) ответ на "static const double?"

NB>static const double?
enum { f = 3.14; } ???

Здравствуйте, VladFein, Вы писали:

X>>>>но для целочисленных все же предпочитаю enum.

VF>>>enum вместо static const <type> — это грязный хэк, доставщхийся нам со времён компиляторов, не умеющих инициализировать константные переменные по месту объявления.

NB>>static const double?

VF>enum { f = 3.14; } ???

да легко:
enum { f = 3140 };

static double f () { return 3.14; }

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, VladFein, Вы писали:

VF>>enum { f = 3.14; } ???
X>1. и какой компилятор такое компилирует?

Ты всегда всё воспринимаешь всерьёз, даже когда написано зелёным текстом?

1/24/2014 10:32 PM, VladFein пишет:

> А что так? Не уважаешь???
Для этого сначала налить надо, а потом уже и обсудить можно.

X>>но для целочисленных все же предпочитаю enum.

VF>enum вместо static const <type> — это грязный хэк, доставщхийся нам со времён компиляторов, не умеющих инициализировать константные переменные по месту объявления.

Те времена все еще с нами. Рекомендую ознакомиться.
http://www.rsdn.ru/forum/cpp/5350623

Автор: Abyx
Дата: 02.11.13

Здравствуйте, VladFein, Вы писали:

X>>но для целочисленных все же предпочитаю enum.

VF>enum вместо static const <type> — это грязный хэк, доставщхийся нам со времён компиляторов, не умеющих инициализировать константные переменные по месту объявления.

Есть одно но. Согласно п.9.4.2/4 стандарта (п.9.4.2/3 в ст. 2003 г.), если даже объявление статической целочисленной константы — члена класса имеет инициализатор:

class A
{
  static const int foo = 42;
};

все равно определение этого статического члена обязано быть сделано за пределами класса:

const int A::foo;

И в этом плане определение целочисленных констант при помощи enum имеет очевидное преимущество.

Здравствуйте, rg45, Вы писали:

X>>>но для целочисленных все же предпочитаю enum.

VF>>enum вместо static const <type> — это грязный хэк, доставщхийся нам со времён компиляторов, не умеющих инициализировать константные переменные по месту объявления.

R>Есть одно но. Согласно п.9.4.2/4 стандарта (п.9.4.2/3 в ст. 2003 г.), если даже объявление статической целочисленной константы — члена класса имеет инициализатор:
R>все равно определение этого статического члена обязано быть сделано за пределами класса:

мда. не думал что все настолько печально.

Здравствуйте, rg45, Вы писали:

R>И в этом плане определение целочисленных констант при помощи enum имеет очевидное преимущество.

что не мешает этому оставаться грязным хэком...