В C ++ допустимо ли использование const после идентификатора типа? - PullRequest
22 голосов
/ 12 июня 2009

Моему коллеге 0 на 2 по вопросам, которые он вдохновил ( 1 , 2 ), поэтому я решил дать ему шанс наверстать упущенное.

Наше последнее разногласие связано со стилем вопроса о том, где поместить "const" в декларации.

Он считает, что он должен идти либо перед типом, либо после указателя. Причина в том, что это то, что обычно делают все остальные, и другие стили могут вводить в заблуждение. Таким образом, указатель на константу int и константный указатель на int будут соответственно:

const int *i;
      int * const i;

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

Таким образом, указатель на константу int и указатель на int будут соответственно:

int const * i;
int * const i;

В качестве дополнительного преимущества, выполнение таких действий облегчает понимание более глубоких уровней косвенности. Например, указатель на постоянный указатель на int будет ясно:

int * const * i;

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

В конечном итоге проблема заключается в том, что он считает, что помещать const после int настолько ужасно некрасиво и настолько вредно для читабельности, что его следует запретить в руководстве по стилю. Конечно, я думаю, что если что-нибудь будет в руководстве, предложим сделать это по-своему, но в любом случае нам не следует запрещать один подход.

Edit: Я получил много хороших ответов, но ни один из них не касался моего последнего абзаца («Основная проблема»). Многие люди настаивают на последовательности, но разве это так желательно в этом случае, что это хорошая идея, чтобы запретить другой способ сделать это, а не просто обескураживать это?

Ответы [ 15 ]

48 голосов
/ 12 июня 2009

Самое главное - согласованность . Если для этого нет руководств по кодированию, выберите одно и придерживайтесь его. Но, если ваша команда уже имеет стандарт де-факто, не меняйте его!

Тем не менее, я думаю, что наиболее распространенным является

const int* i;
int* const j;

потому что большинство людей пишут

const int n;

вместо

int const n;

Примечание: простой способ прочитать указатель const Необходимо прочитать объявление, начинающееся справа.

const int* i; // pointer to an int that is const
int* const j; // constant pointer to a (non-const) int
int const* aLessPopularWay; // pointer to a const int
13 голосов
/ 12 июня 2009

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

Если у вас есть тип указателя в typedef, то невозможно изменить константу типа на :

typedef int * PINT;
const PINT pi;

'pi' все еще имеет тип 'int * const', и это то же самое, независимо от того, где вы пишете 'const'.

11 голосов
/ 13 июня 2009

Я надеюсь, что это объяснение из часто задаваемых вопросов Б. Страуструпа по стилю и технике даст вам определенный ответ.

FAQ по стилю и технике Бьярна Страуструпа в C ++


лично я предпочитаю:

int const* pi;
int* const pi;

Поскольку const идентифицирует левый токен, который должен быть постоянным.

И вы определенно сохраняете постоянство при использовании чего-то такого:

int const* const pi;

Вместо непоследовательной записи:

const int* const pi;

А что будет, если у вас есть указатель на указатель и так далее:

int const* const* const pi;

Вместо:

const int* const* const pi;
8 голосов
/ 12 июня 2009

Я был на конференции, где Бьярн Страуструп давал презентацию, и он использовал что-то вроде const int * i; Кто-то спросил его, почему этот стиль, и он ответил (перефразируя): «людям нравится сначала видеть const, когда что-то постоянно».

7 голосов
/ 12 июня 2009

Люди обычно используют const int* blah, потому что он хорошо читает по-английски. Я бы не стал недооценивать полезность этого.

Я считаю, что вариант int* const blah достаточно редок, поэтому обычно нецелесообразно делать более общее определение в обратном направлении. В общем, я не фанат чего-либо, что даже слегка затеняет код в общем случае, хотя в исключительном случае это может дать некоторую номинальную выгоду.

См. Также "if (1 == a)". Некоторым людям действительно нравится писать код, который не читается как английский. Я не из тех людей.

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

6 голосов
/ 14 июля 2010

Если бы только переменные и указатели на них могли быть const или нет, это, вероятно, не имело бы большого значения. Но учтите:

class MyClass
{
    public:
        int foo() const;
};

Ни в коем случае нельзя писать const где-либо еще, кроме конечного функции, к которой оно относится.

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

Ключевое слово const всегда отслеживает независимо от того, на что оно ссылается.

Итак, я бы сказал 0: 3 для вашего коллеги здесь.

Относительно вашей "главной проблемы": ради руководства по стилю, не имеет значения , будет ли руководство "обескураживать" или "запрещать" то, против чего он выступает. Это социальная проблема, политика. Само руководство по стилю должно быть как можно более четким и коротким. Длинные руководства по стилю просто игнорируются всеми (кроме руководства по поиску виновных), поэтому просто пишите «делай» или «не делай» и заявляй, что ты делаешь с нарушениями руководства в другом месте (например, в политике компании) о том, как проводятся экспертные оценки).

5 голосов
/ 13 июня 2009

Хотя между const int и int const нет существенной разницы (и я видел оба используемых стиля), есть разница между const int * и int * const.

Во-первых, у вас есть указатель на const int. Вы можете изменить указатель, но вы не можете изменить значение, на которое он указывает. Во втором у вас есть константный указатель на int. Вы не можете изменить указатель (надеюсь, он будет инициализирован по вашему вкусу), но вы можете изменить значение указателя на int.

Правильное сравнение с const int * и int const *, которые оба являются указателями на const int.

Помните, что * не обязательно работает так, как вам нравится. Объявление int x, y; будет работать так, как вы ожидаете, но int* x, y; объявляет один указатель на int и один int.

4 голосов
/ 12 июня 2009

Помещение «const» после объявления типа имеет гораздо больше смысла, как только вы тренируете себя , чтобы читать объявления типа C ++ справа налево.

Я собираюсь привязать твоего корова-оркера к 0-на-3:)

3 голосов
/ 18 марта 2016

Позвольте мне поставить 2 ¢ в обсуждение.

В современном C ++ я бы порекомендовал придерживаться int const вместо const int, чтобы подчеркнуть разницу между const и constexpr. Это помогло бы программисту запомнить, что const int не всегда можно считать постоянной времени компиляции, потому что:

  • компилятор может (будет?) Выделять для него память,
  • эта память может быть даже не защищена от записи (сегмент стека),
  • такая константа не может служить все обязанности constexpr может .
3 голосов
/ 12 июня 2009

Главная проблема здесь в том, что он считает, что помещать const после int настолько ужасно некрасиво и так вредно для читабельности, что его следует запретить в руководстве по стилю

Действительно

Покажите мне программиста, который увязает, когда видит:

int foo() {
}

против

int foo()
{
}

... и я покажу вам программиста, который не уделяет достаточно внимания деталям.

Ни один профессиональный программист, достойный его соли, не будет иметь проблем с поверхностными различиями в стиле.

РЕДАКТИРОВАТЬ: Это правда, что const int * и int * const не означают совершенно одно и то же, но это не главное. Сотрудник OP отметил, что различия в стиле делают код трудным для понимания и сопровождения. С этим утверждением я не согласен.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...