Почему константная корректность специфична для C ++?

Корректность констант дает два заметных преимущества C ++, о которых я могу думать, одно из которых делает его довольно уникальным.

• Он позволяет распространять представления об изменяемых / неизменяемых данных, не требуя множества интерфейсов. Отдельные методы могут быть аннотированы относительно того, могут ли они выполняться на константных объектах, и компилятор обеспечивает это. Да, иногда это может быть проблемой, но если вы используете его последовательно и не используете const_cast, у вас есть проверенная компилятором безопасность в отношении изменяемых и неизменяемых данных.
• Если объект или элемент данных const, компилятор может поместить его в постоянную память. Это особенно важно для встроенных систем. C ++ поддерживает это; немногие другие языки делают. Это также означает, что в общем случае вы не можете безопасно отбросить const, хотя на практике вы можете сделать это в большинстве сред.

C ++ - не единственный язык с константной корректностью или чем-то в этом роде. OCaml и Standard ML имеют схожую концепцию с разной терминологией, почти все данные неизменяемы (const), и когда вы хотите, чтобы что-то было изменяемым, вы используете другой тип (тип ref) для этого. Так что это просто уникально для C ++ в пределах его соседних языков.

Наконец, обратное направление: были времена, когда я хотел const в Java. final иногда недостаточно далеко до создания просто неизменяемых данных (особенно неизменяемых представлений изменяемых данных) и не хотят создавать интерфейсы. Посмотрите на поддержку коллекции Unmodifiable в Java API и тот факт, что она проверяет только во время выполнения, разрешена ли модификация для примера того, почему const полезна (или, по крайней мере, структура интерфейса должна быть углублена, чтобы иметь List и MutableList), есть нет причин, по которым попытка изменить неизменяемую структуру не может быть ошибкой типа компиляции.

Я не думаю, что кто-то утверждает, что const-корректность «необходима». Но опять же, занятия на самом деле не нужны, не так ли? То же самое и с пространствами имен, исключениями ... вы понимаете.

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

const - это способ выразить что-то. Было бы полезно на любом языке, если бы вы считали важным выразить это. У них нет этой функции, потому что разработчики языка не сочли их полезными. Думаю, если бы эта функция была там, она была бы не менее полезной.

Я думаю об этом как о спецификациях на Java. Если они вам нравятся, вы, вероятно, захотите их на других языках. Но создатели других языков не думали, что это так важно.

Что ж, мне потребовалось 6 лет, чтобы по-настоящему понять, но теперь я наконец могу ответить на свой вопрос.

Причина, по которой C ++ имеет "константную корректность", а Java, C # и т. Д. - нет, заключается в том, что C ++ поддерживает только типы значений, а эти другие языки поддерживают только или, по крайней мере, по умолчанию ссылочные типы.

Давайте посмотрим, как C #, язык, по умолчанию использующий ссылочные типы, работает с неизменяемостью, когда задействованы типы значений. Допустим, у вас есть изменяемый тип значения и другой тип, у которого есть поле только для чтения этого типа:

struct Vector {
    public int X { get; private set; }
    public int Y { get; private set; }
    public void Add(int x, int y) {
        X += x;
        Y += y;
    }
}

class Foo {
    readonly Vector _v;
    public void Add(int x, int y) => _v.Add(x, y);
    public override string ToString() => $"{_v.X} {_v.Y}";
}

void Main()
{
    var f = new Foo();
    f.Add(3, 4);
    Console.WriteLine(f);
}

Что должен делать этот код?

1. не компилировать
2. напечатать "3, 4"
3. напечатать "0, 0"

Ответ №3. C # пытается учесть ваше ключевое слово «только для чтения», вызывая метод Add для выбрасываемой копии объекта. Это странно, да, но какие еще варианты есть? Если он вызывает метод исходного вектора, объект изменится, нарушив "доступность только для чтения" поля. Если он не компилируется, то члены типа значения, доступные только для чтения, довольно бесполезны, потому что вы не можете вызывать для них какие-либо методы из-за страха, что они могут изменить объект.

Если бы мы только могли обозначить, какие методы безопасно вызывать в экземплярах только для чтения ... Подождите, это именно то, что константные методы в C ++!

C # не беспокоится о методах const, потому что мы не так часто используем типы значений в C #; мы просто избегаем изменяемых типов значений (и объявляем их "злыми", см. 1, 2).

Кроме того, ссылочные типы не страдают от этой проблемы, потому что, когда вы помечаете переменную ссылочного типа как только для чтения, только для чтения является ссылка, а не сам объект. Это очень легко реализовать компилятору, он может пометить любое присвоение как ошибку компиляции, за исключением инициализации. Если все, что вы используете, - это ссылочные типы и все ваши поля и переменные доступны только для чтения, вы получите неизменность везде с небольшими синтаксическими затратами. F # работает именно так. Java избегает этой проблемы, просто не поддерживая определяемые пользователем типы значений.

В C ++ нет понятия «ссылочные типы», только «типы значений» (в C # -lingo); некоторые из этих типов значений могут быть указателями или ссылками, но, как и типы значений в C #, ни один из них не владеет своим хранилищем. Если бы C ++ обрабатывал "const" для своих типов так же, как C # рассматривал бы "только для чтения" для типов значений, это было бы очень запутанным, как демонстрирует приведенный выше пример, не говоря уже о неприятном взаимодействии с конструкторами копирования.

Таким образом, C ++ не создает одноразовую копию, потому что это создало бы бесконечную боль. Это также не запрещает вам вызывать какие-либо методы для членов, потому что, ну, тогда язык не был бы очень полезным. Но он все еще хочет иметь какое-то понятие «только для чтения» или «постоянство».

C ++ пытается найти золотую середину, заставляя вас отмечать, какие методы безопасно вызывать для членов const, а затем он доверяет вам, что вы были верны и точны в вашей маркировке, и вызывает методы непосредственно на исходных объектах. Это не идеально - это многословно, и вы можете нарушать константу сколько угодно - но, возможно, это лучше, чем все другие варианты.

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

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

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

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

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

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

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

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

Это концепция, по которой мне больше не хватает при переходе на другие языки. Рассмотрим сценарий, в котором у вас есть класс C, который, среди прочего, имеет атрибут a типа A, который должен быть видимым для внешнего кода (пользователи вашего класса должны иметь возможность запрашивать некоторую информацию о a). Если тип A имеет какую-либо операцию изменения, то, чтобы пользовательский код не менял ваше внутреннее состояние, вы должны создать копию a и вернуть ее. Программист класса должен знать, что необходимо выполнить копирование, и должен выполнить (возможно, дорогое) копирование. С другой стороны, если бы вы могли выразить постоянство в языке, вы могли бы просто вернуть постоянную ссылку на объект (фактически ссылку на постоянное представление объекта) и просто вернуть внутренний элемент. Это позволит пользовательскому коду вызывать любой метод объекта, который проверяется как неизменяемый, тем самым сохраняя инварианты вашего класса.

Проблема / преимущество, все зависит от точки зрения, постоянства в том, что он вирусный. Когда вы предлагаете постоянную ссылку на объект, могут быть вызваны только те методы, которые помечены как неизменяемые, и вы должны сообщить компилятору, какой из методов имеет это свойство. Когда вы объявляете константу метода, вы сообщаете компилятору, что пользовательский код, вызывающий этот метод, сохранит состояние объекта. Когда вы определяете (реализуете) метод с постоянной подписью, компилятор напомнит вам о вашем обещании и фактически потребует, чтобы вы не изменяли данные внутри себя.

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

В этом контексте никогда не следует использовать const_cast ‹>, поскольку результаты могут привести вас в область неопределенного поведения (как с языковой точки зрения: объект может находиться в памяти только для чтения, так и с точки зрения программы : возможно, вы нарушаете инварианты в других классах). Но это, конечно, вы уже знаете, если читаете C ++ FAQ lite.

В качестве побочного примечания, ключевое слово final в Java действительно не имеет ничего общего с ключевым словом const в C ++, когда вы имеете дело со ссылками (в ссылках или указателях C ++). Ключевое слово final изменяет локальную переменную, на которую оно ссылается, будь то базовый тип или ссылка, но не является модификатором упомянутого объекта. То есть вы можете вызывать методы изменения через последнюю ссылку и, таким образом, вносить изменения в состояние упомянутого объекта. В C ++ ссылки всегда постоянны (вы можете привязать их к объекту / переменной только во время построения), а ключевое слово const изменяет то, как пользовательский код может работать с указанным объектом. (В случае указателей вы можете использовать ключевое слово const как для данных, так и для указателя: X const * const объявляет константный указатель на константу X)

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

Вы также хотите использовать const в методах, чтобы воспользоваться преимуществами оптимизации возвращаемого значения. См. Пункт 20 «Более эффективный C ++ Скотта Мейерса».

Этот разговор и видео от < em> Herb Sutter объясняет новые коннотации const в отношении безопасности потоков.

Постоянство, возможно, не было тем, о чем вам приходилось слишком беспокоиться раньше, но с C ++ 11, если вы хотите писать поточно-ориентированный код, вам нужно понимать значение const и mutable

В C, Java и C # вы можете узнать, посмотрев на сайт вызова, может ли переданный объект быть изменен функцией:

• в Java вы знаете, что это определенно может быть.
• в C вы знаете, что это может быть, только если есть '&' или эквивалент.
• в C # вам также нужно сказать «ref» на сайте вызова.

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

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

Андерс Хейлсберг (архитектор C #): ... Если вы объявляете метод, который принимает неконстантный Bla, вы не можете передать ему const Bla. Итак, теперь вы застряли. Итак, вам постепенно понадобится константная версия всего, что не константно, и вы получите теневой мир.

Итак, еще раз: если вы начали использовать «const» для некоторых методов, вы обычно вынуждены были использовать это в большей части вашего кода. Но время, затрачиваемое на поддержание (ввод, перекомпиляция при отсутствии некоторой константы и т. Д.) Константной корректности в коде кажется больше, чем на исправление возможных (очень редких) проблем, вызванных тем, что константная корректность вообще не используется. Таким образом, отсутствие поддержки константной корректности в современных языках (таких как Java, C #, Go и т. Д.) Может привести к небольшому сокращению времени разработки при том же качестве кода.

Билет запроса на расширение для реализации корректности констант существовал в Java Community Process с 1999 года, но был закрыт в 2005 году из-за вышеупомянутого «загрязнения констант», а также по причинам совместимости: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4211070

Хотя в языке C # нет константной конструкции корректности, аналогичные функции, возможно, скоро появятся в «Microsoft Code Contracts» (библиотека + инструменты статического анализа) для .NET Framework с использованием атрибутов [Pure] и [Immutable]: Чистые функции в C #

На самом деле, это не совсем так.

В других языках, особенно в функциональных или гибридных языках, таких как Haskell, D, Rust и Scala, существует концепция изменчивости: переменные могут быть изменяемыми или неизменяемыми и обычно неизменяемыми по умолчанию.

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

C и C ++ делают нечто подобное с использованием const, за исключением того, что это гораздо менее надежная гарантия: неизменяемость не обеспечивается; функция, расположенная ниже по стеку вызовов, могла бы отбросить константу и изменить ваши данные, но это было бы преднамеренным нарушением контракта API. Таким образом, намерение или лучшая практика состоит в том, чтобы он работал так же, как неизменяемость в других языках.

С учетом всего сказанного, в C ++ 11 теперь есть собственно ключевое слово mutable, наряду с более ограниченным ключевым словом const.

Ключевое слово const в C ++ (применительно к параметрам и объявлениям типов) - это попытка удержать программистов от того, чтобы они не оттолкнули себя и не вырубили себе при этом всю ногу.

Основная идея состоит в том, чтобы пометить что-либо как «не может быть изменено». Тип const нельзя изменить (по умолчанию). Константный указатель не может указывать на новое место в памяти. Все просто, правда?

Что ж, вот где появляется корректность const. Вот некоторые из возможных комбинаций, в которых вы можете оказаться при использовании const:

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

Указатель на константную переменную Подразумевает, что указатель может быть изменен, но сами данные - нет.

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

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

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

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

Например, у вас есть функция:

void const_print(const char* str)
{
    cout << str << endl;
}

Другой способ

void print(char* str)
{
    cout << str << endl;
}

В основном:

int main(int argc, char **argv)
{
    const_print("Hello");
    print("Hello");        // syntax error
}

Это потому, что "hello" - это указатель const char, строка (в стиле C) помещается в постоянную память. Но в целом это полезно, когда программист знает, что значение не будет изменено, чтобы получить ошибку компилятора вместо ошибки сегментации. Как в нежелательных заданиях:

const int a;
int b;
if(a=b) {;} //for mistake

Поскольку левый операнд - это const int.