Как компилятор обрабатывает член класса static constexpr const char*

Привет!

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

1

Kastaneda, судя по сообщениям компилятора, const char* - не "интегральный" тип, и видимо в этом загвоздка - совмещать объявление статического члена класса и его инициализацию можно только для "интегральных" типов; в то время как при использовании constexpr инициализация необходима при объявлении.

1

Сообщение от Kastaneda Вопрос - как компилятора без линкера разруливает это дело, ведь constexpr value ему нужен на этапе компиляции? Если он это пережевывает, почему тогда constexpr необходим?

Если понадобится адрес переменной, то потребуется определение (без него будет ошибка линкера). До этих пор линкер вообще не задействуется - это compile-time константа.

1

Сообщение от DrOffset До этих пор линкер вообще не задействуется - это compile-time константа.

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

0

Сообщение от Kastaneda Но ведь эта константа содержит адрес строки, который становится известным на этапе линковки, как компилятор обходится без линкера?

1. Эта штука называется address constant expression.
2. А зачем ему линкер? Для таких объектов у компилятора адрес - это просто какая-то релокация. Он ее потом отправит в elf и все. А линкер дальше будет с ее использованием по соответствующему выражению адрес считать. Компилятору же нужно только знать, что эта релокация - константа.

3

Сообщение от Kastaneda как компилятор обходится без линкера?

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

1

Сообщение от ct0r Эта штука называется address constant expression

Во, спасибо, знаний вот этого термина мне не хватало.

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

Да, логично, похоже разобрались

0

Сообщение от Kastaneda Вопрос - как компилятора без линкера разруливает это дело, ведь constexpr value ему нужен на этапе компиляции? Если он это пережевывает, почему тогда constexpr необходим?

Концепция адресной константы была еще в языке С с самого начала стандартизованных времен. Про этом язык С никогда не поддерживал динамической инициализации для объектов со статическим storage duration. Т.е. при старте программы на C все объекты со статическим storage duration должны "родиться" уже проинициализированными, в том числе такие как

Понятно, что значение pi не может быть известным на стадии компиляции. Более того, это значение даже в те времена в Unix не обязательно было известно даже на стадии линковки, а могло оказаться известным только на стадии загрузки (например, для глобальных объектов, определенных в shared objects). То есть конкретное значение адресной константы в общем случае может быть даже не линкером, а только загрузчиком в момент начала выполнения.

По этой причине спецификация адресных констант в С была специально подогнана под возможности загрузчиков. А именно, в С адресные константы выступают как константы только в инициализаторах и только либо сами собой, либо с прибавлением к адресной константе (или вычитанием из нее) какого-то смещения, известного на стадии компиляции (что разрешает в т.ч. применение операторов [] и -> в комбинации с & для формирования новых адресных констант). Другими словами, адресные константы в С могут быть использованы как константы только для целей относительной адресации.

То есть в рамках спецификации, нельзя написать

ибо, понятое дело, это требует знания точного значения (size_t) pi на стадии компиляции.

Так вот спецификация constexpr в С++ совсем не далеко уходит от этих ограничений, пришедших в С++ из С. Фактически, все, чего вы добиваетесь указанием constexpr в этом объявлении указателя, это превращение в constexpr таких выражений, как PTR[5]. Для этого инициализатор PTR должен быть виден компилятору, т.е. присутствовать в объявлении. Ясно, что для определения значения PTR[5] в таком случае компилятору совсем не нужно знать конкретного значения PTR.

Любые же попытки "выковырять" из PTR его численное значение на стадии компиляции (или как-то еще завязаться на абсолютную точку в памяти, куда он указывает) обречены на провал, даже несмотря на то, что PTR объявлен как constexpr.

7

Если вернуться к изначальному вопросу. Почему без constexpr не компилируется - уже ответили: инициализатор должен быть не в теле класса, а там, где объявлено само тело статического поля. Т.е. где-то вне тела класса должно быть написано

Из объяснений TheCalligrapher я так понял, что для статической инициализации указателя constexpr ничего принципиально нового не вносит (во всяком случае на низком уровне). А почему наличие constexpr позволяет инициализатор писать в теле класса? На всякий случай: мне непонятна только языковая часть, как работает компилятор, линкер, загрузчик и прочее на низком уровне, мне хорошо известно

0

Сообщение от Evg А почему наличие constexpr позволяет инициализатор писать в теле класса?

Для всех static constexpr разрешается писать инициализатор прямо в теле класса. Это необходимо для того, чтобы реализовать вычисления на стадии компиляции. В вычислениях на стадии компиляции и заключается вся идея constexpr.

В данном случае инициализатор необходим для того, чтобы на стадии компиляции вычислять выражения вида PTR[5].

При этом определением указателя PTR такое объявление не становится, даже несмотря на наличие инициализатора. Если где-то в коде PTR окажется использованным как lvalue, то придется его еще где-то определить. Инициализатор в определении повторять не надо.

0

Я правильно понимаю ситуацию? Сначала (условно в C++98) разрешили писать инициализатор в теле класса ради того, чтобы static-поле класса можно было, грубо говоря, использовать в качестве размерности НЕавтоматического массива. Для указателей подобной необходимости не было, а потому не разрешали. Теперь (с C++11) из-за constexpr появилась необходимость использовать указатель (как rvalue) в других constexpr выражениях в НЕавтоматических местах, растущих от других constexpr'ов. Типа того?

0

Сообщение от Evg Я правильно понимаю ситуацию? Сначала (условно в C++98) разрешили писать инициализатор в теле класса ради того, чтобы static-поле класса можно было, грубо говоря, использовать в качестве размерности НЕавтоматического массива. Для указателей подобной необходимости не было, а потому не разрешали. Теперь (с C++11) из-за constexpr появилась необходимость использовать указатель (как rvalue) в других constexpr выражениях в НЕавтоматических местах, растущих от других constexpr'ов. Типа того?

Ну да. Типа того.

В С++98 (и С++03) возможность использования static const членов класса в качестве констант времени компиляции понимали (отсюда разрешение на указание инициализаторов для целых и enum типов), но это возможность все равно рассматривалась, как "вторичная". Например, правила ODR в С++98 формально требовали отдельного определения такого члена класса, если он использовался (used) в программе. При этом не придавалось никакого значения тому, как он использовался. Даже если static const использовался только как rvalue (напр. только для задания размера массива), все равно наличие определения безусловно требовалось спецификацией языка. Хотя понятно, что с точки зрения здравого смысла такое определение было никому не нужно. (Многие компиляторы натуральным образом не следили за соблюдением этого требования, если такая константа использовалась только как rvalue).

В С++11 возможность использования таких констант именно и только как констант времени компиляции уже вышла на первый план. Правила ODR были модифицированы и требуют отдельного определения static const членов класса только если они odr-используются (odr-used) в программе, т.е. если они где-то используются именно как lvalue. А если такая константа используется только как rvalue, то делать для нее отдельное определение больше не требуется.

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

3

Сообщение от TheCalligrapher Даже если static const использовался только как rvalue (напр. только для задания размера массива), все равно наличие определения безусловно требовалось спецификацией языка. Хотя понятно, что с точки зрения здравого смысла такое определение было никому не нужно. (Многие компиляторы натуральным образом не следили за соблюдением этого требования, если такая константа использовалась только как rvalue)

Тут проблема немного другого уровня. Компилятор в общем-то не в состоянии проконтролировать, что определение неиспользуемой как value переменной где-то присутствует. Т.е. когда переменная используется (например, на неё взяли адрес), а определения нигде нет, то оно сломается на линковке. А когда переменная нигде не используется (все использования были заменены на константы), то очень сложно предпринимать усилия для того, чтобы сломаться в том случае, если определение переменной ни в одном из модулей не присутствует. Только путём построения избыточного кода или каких-то читерских вещей

0

После этого

Сообщение от TheCalligrapher Фактически, все, чего вы добиваетесь указанием constexpr в этом объявлении указателя, это превращение в constexpr таких выражений, как PTR[5]. Для этого инициализатор PTR должен быть виден компилятору, т.е. присутствовать в объявлении. Ясно, что для определения значения PTR[5] в таком случае компилятору совсем не нужно знать конкретного значения PTR

окончательно все встало на свои места, спасибо.

0

Сообщение от TheCalligrapher Если где-то в коде PTR окажется использованным как lvalue, то придется его еще где-то определить. Инициализатор в определении повторять не надо.

Тут, кстати, стоит добавить, что в С++17 все сильно меняется.

В С++17 вводится понятие inline variable. И можно будет писать так

при этом вышеприведенное объявление переменной S::x является ее определением. Переменную можно использовать как lvalue, и при этом какого-то дополнительного определения для нее делать не надо (и нельзя).

Далее, constexpr константы в С++17 становятся частным случаем inline variable. При этом, для сохранения обратной совместимости, писать отдельное "определение" для такой константы разрешается, но является deprecated

5