Имеет ли смысл делать фундаментальный (не указатель) параметр константой?

Помните шаблон if(NULL == p)?

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

if(NULL == myPointer) { /* etc. */ }

вместо

if(myPointer == NULL) { /* etc. */ }

Обоснование состоит в том, что первая версия защитит кодировщик от опечаток кода, таких как замена == на = (потому что запрещено присваивать значение постоянному значению).

Следующее можно рассматривать как расширение этого ограниченного if(NULL == p) шаблона:

Почему параметры const-ing могут быть полезны для кодировщика

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

Например, такой код покажет, когда компилятор может мне помочь:

void bar_const(const int & param) ;
void bar_non_const(int & param) ;

void foo(const int param)
{
   const int value = getValue() ;

   if(param == 25) { /* Etc. */ } // Ok
   if(value == 25) { /* Etc. */ } // Ok

   if(param = 25) { /* Etc. */ } // COMPILE ERROR
   if(value = 25) { /* Etc. */ } // COMPILE ERROR

   bar_const(param) ;  // Ok
   bar_const(value) ;  // Ok

   bar_non_const(param) ;  // COMPILE ERROR
   bar_non_const(value) ;  // COMPILE ERROR

   // Here, I expect to continue to use "param" and "value" with
   // their original values, so having some random code or error
   // change it would be a runtime error...
}

В тех случаях, которые могут произойти либо из-за опечатки в коде, либо из-за ошибки в вызове функции, компилятор обнаружит, что это хорошо.

Почему это не важно для пользователя

Бывает, что:

void foo(const int param) ;

и:

void foo(int param) ;

иметь такую ​​же подпись.

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

Это объясняет, почему мои объявления функций пользователям опускают константу:

void bar(int param, const char * p) ;

чтобы объявление было как можно более ясным, в то время как мое определение функции добавляет его как можно больше:

void bar(const int param, const char * const p)
{
   // etc.
}

чтобы сделать мой код максимально надежным.

Почему в реальном мире это может сломаться

Однако меня укусил мой паттерн.

На каком-то неработающем компиляторе, который останется анонимным (имя которого начинается с Sol и заканчивается на aris CC), две подписи выше могут рассматриваться как разные (в зависимости от контекста), и, таким образом, ссылка времени выполнения возможно не сработает.

Поскольку проект был скомпилирован также на платформах Unix (Linux и Solaris), на этих платформах неопределенные символы оставались разрешенными при выполнении, что спровоцировало ошибку времени выполнения в середине выполнения процесса.

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

Но я все же считаю эту схему добавления константы в определение функции хорошей.

Примечание. У Sun Microsystems даже хватило смелости скрыть свое сломанное искажение с помощью шаблона это зло в любом случае, поэтому вы не должны использовать его. см. http://docs.oracle.com/cd/E19059-01/stud.9/817-6698/Ch1.Intro.html#71468

Последнее примечание

Следует отметить, что Бьярн Страуструп, похоже, был против того, чтобы рассматривать void foo(int) тот же прототип, что и void foo(const int):

Однако, на мой взгляд, не все принятые функции являются улучшением. Например, [...] правило, согласно которому void f (T) и void f (const T) обозначают одну и ту же функцию (предложенное Томом Пламом из соображений совместимости с C), [имеют] сомнительное отличие, поскольку за него проголосовали C ++ « через мой труп".

Источник: Бьярн Страуструп
Развитие языка в реальном мире и для него: C ++ 1991-2006, 5. Особенности языка: 1991–1998, стр. 21.
http://www.stroustrup.com/hopl-almost-final.pdf

Забавно учитывать, что Херб Саттер предлагает противоположную точку зрения:

Рекомендация. Избегайте константных параметров передачи по значению в объявлениях функций. По-прежнему сделайте параметр const в определении той же функции, если он не будет изменен.

Источник: Херб Саттер
Exceptional C ++, Item 43: Const-Correctness, p177-178.

Это обсуждалось много раз, и в большинстве случаев людям приходилось соглашаться, чтобы не соглашаться. Лично я согласен с тем, что это бессмысленно, и стандарт неявно соглашается - квалификатор const (или volatile) верхнего уровня не является частью сигнатуры функции. На мой взгляд, желание использовать подобный квалификатор верхнего уровня указывает (строго), что человек может на словах отделять интерфейс от реализации, но не действительно понимает разницу.

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

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

Если bar помечен const, как указано выше, то человек, читающий код, зная, что было передано, всегда знает точно, что содержит bar. Нет необходимости заранее просматривать какой-либо код, чтобы узнать, менялась ли полоса в какой-либо момент в процессе. Это упрощает рассуждения о коде и, таким образом, снижает вероятность появления ошибок.

Я сам голосую за "хорошую практику". Конечно, в наши дни я в значительной степени перешла на функциональные языки, так что ....

Обращаясь к комментарию ниже, рассмотрите этот исходный файл:

// test.c++

bool testSomething()
{
    return true;
}

int test1(int a)
{
    if (testSomething())
    {
        a += 5;
    }
    return a;
}

int test2(const int a)
{
    if (testSomething())
    {
        a += 5;
    }
    return a;
}

В test1 я не могу узнать, каким будет возвращаемое значение, не прочитав (потенциально значительного и / или запутанного) тела функции и без отслеживания (потенциально удаленного, значительного, запутанное и / или исходный код недоступен) тело функции testSomething. Кроме того, изменение a может быть результатом ужасной опечатки.

Та же самая опечатка в test2 приводит к следующему результату во время компиляции:

$ g++ test.c++
test.c++: In function ‘int test2(int)’:
test.c++:21: error: assignment of read-only parameter ‘a’

Если это была опечатка, меня поймали. Если это не опечатка, то лучше выбрать кодировку, IMO:

int test2(const int a)
{
    int b = a;
    if (testSomething())
    {
        b += 5;
    }
    return b;
}

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

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

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

Я также стараюсь поддерживать соответствие сигнатур функций, даже если в этом нет особого смысла. Отчасти потому, что он не причиняет никакого вреда, а отчасти потому, что Doxygen немного запутался, если подписи были разными.