Путаница с инициализацией массива в C

int a [5] = {выражение} не является присвоением [0]?

Выражение a[2]=1 оценивается как 1.

Очень глубокий вопрос. Интересно, знает ли ответ интервьюер. Я не. Действительно, якобы значение выражения a[2] = 1 равно 1, но я не уверен, разрешено ли вам принимать результат назначенного выражения инициализатора в качестве значения первого элемента. Тот факт, что вы добавили тег «адвокат», означает, что я думаю, что нам нужен ответ со ссылкой на стандарт.

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

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

Не могли бы мы закрыть это как дубликат дополнительного вопроса?

@Bathsheba Я бы сделал наоборот, поскольку ответ здесь теперь отвечает на оба вопроса.

@KamiKaze: Я попросил модов объединить их; Хотя нет гарантии, что они это сделают. Мне кажется, что второй вопрос немного более каноничен, если вы понимаете, что я имею в виду. Но посмотрим, что думают начальство!

@Bathsheba будет лучшим. Тем не менее, я бы отдал должное за вопрос OP, поскольку он придумал эту тему. Но не мне решать, что я считаю «правильным».

@Bathsheba Назначенные инициализаторы должны начинаться с [ или .. a[2] = 1 - нормальное выражение, без обозначения.

Возможно ли это в Ruby? просто любопытно !

Может быть связано с Странные значения при инициализации массива с использованием назначенных инициализаторов

Я думаю, что a [0] = 1 зависит от порядка байтов в архитектуре ЦП ....

Я запомню эту конструкцию, если она мне когда-нибудь понадобится для код игры в гольф!

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

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

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

@melpomene Существует экспрессия {...}, которая инициализирует a[2] в 0, и субэкспрессию a[2]=1, которая инициализирует a[2] в 1.

@melpomene Хорошо, ты можешь быть здесь. Но я бы все же сказал, что есть еще 2 конкурирующих побочных эффекта, так что абзац остается в силе.

@melpomene нужно упорядочить две вещи: первый инициализатор и установка других элементов на 0

@ M.M Именно поэтому цитата из 6.7.9 / 23 неприменима: она охватывает только последовательность между выражениями инициализатора, а не между выражением инициализатора и инициализацией подобъектов (к чему сводится этот вопрос).

Вместо undefined я бы сказал, что это неопределенные, что оставляет вещи открытыми для интерпретации реализациями.

Я не думаю, что что-либо из того, что было до вашего последнего горизонтального правила, имеет отношение к вопросу; единственная проблема - когда происходит инициализация нуля (что стандарт, похоже, не говорит). Тот же вопрос будет поднят int a[5] = { a[2] = a[3] };.

"мы попадаем в кроличью нору" LOL! Никогда не слышал об этом для UB или неуказанного материала.

Я думаю, что 6.7.8.19 можно читать двумя способами, оба из которых дают «действительные» результаты, но оба являются нежелательными прочтениями. 1) Мы считаем, что a[2] = 1 инициализирует a[2] (хотя он явно не является «инициализатором» для a[2]), потому что он «устанавливает начальное значение» (как указано в скобках в 5.1.2), что делает результат с a[2] == 1 четко определенным ( потому что он был "явно инициализирован" и поэтому не должен быть установлен в 0). Это нежелательно, потому что это незаметно для инициализации без инициализатора, минуя все осторожные слова о том, что порядок инициализаторов не указан ...

... или 2) мы считаем, что a[2] = 1 не инициализируется узкой интерпретацией «инициализировать», когда назначение не «инициализируется», но тогда a[2] должен быть установлен в 0 согласно 6.7.8.19. Это нежелательно, потому что это противоречит наиболее очевидной реализации инициализации (инициализация всего блока до 0, затем инициализаторы процесса), создает чрезмерную нагрузку на компилятор и в любом случае делает все это бесполезным. Я согласен с тем, что, судя по нынешней формулировке, все это, вероятно, следует считать неопределенным, поскольку стандарт недостаточно ясен.

Выше, для «порядка инициализаторов», конечно, прочтите «порядок побочных эффектов инициализаторов». Указан порядок инициализаторов.

Мне кажется, что ключевой вопрос - это порядок неявной инициализации по отношению к инициализации элементов, для которых есть явные инициализаторы. Я не использую 6.7.8 / 19, чтобы указать это, поскольку "порядок списка инициализаторов" не имеет смысла для элементов, у которых нет соответствующего инициализатора. Наблюдаемое поведение следует из неявной инициализации, выполняемой до оценки явных инициализаторов. Я считаю, что это очень разумная - действительно, вероятная - реализация, но я согласен с тем, что стандарт не определяет такой порядок.

@Someprogrammerdude Я не думаю, что он может быть неопределенным ("поведение, при котором настоящий международный стандарт предоставляет две или более возможности и не налагает дополнительных требований, которое выбирается в любом случае"), потому что стандарт на самом деле не предоставляет никаких возможностей для выбора. Здесь просто не говорится о том, что происходит, что, как мне кажется, подпадает под "Неопределенное поведение [...] указывается в этом международном стандарте [...] отсутствием какого-либо явного определения поведения.".

@ BЈовић Это отсылка к Алисе в стране чудес: merriam-webster.com/dictionary/rabbit%20hole

@ BЈовић Это также очень хорошее описание не только для неопределенного поведения, но и для определенного поведения, для объяснения которого нужен поток, подобный этому.

@ M.M OP задал два вопроса: "почему [0] печатает 1 вместо 0? Это неопределенное поведение?" Первая часть моего ответа отвечает на оба: вся конструкция не определена, но значение 1 для a[0] имеет смысл, потому что = возвращает присвоенное значение. Остальная часть моего ответа подробно объясняет, почему я считаю, что поведение не определено.

Могли бы вы тогда сказать, что поведение программы все равно не было бы определено, если бы инициализатором был { a[0] = 1 }?

@JohnBollinger Я думаю, что int a[5] = { a[0] = 1 } определил поведение и должен установить a[0] на 1.

Хм. Я, конечно, исследую вашу логику. Я думаю, что готов согласиться с тем, что оригинал демонстрирует UB, но на данный момент я не готов признать, что предложенная мною альтернатива также не делает этого. Он также имеет два разных побочных эффекта для одного и того же объекта (в данном случае a[0]), относительный порядок которых не определен. То, что они оба производят одинаковый эффект на этот объект, не имеет значения. Рассмотрим, например, оператор a[0] = a[0] = 1;. Думаю понятно, что это УБ выставляет по стандарту.

@JohnBollinger Разница в том, что вы не можете фактически инициализировать подобъект a[0] до оценки его инициализатора, а оценка любого инициализатора включает точку последовательности (потому что это «полное выражение»). Поэтому я считаю, что изменение подобъекта, который мы инициализируем, - это честная игра.

Это вопрос [языкового юриста], но это не тот ответ, который работает со стандартом, что делает его неактуальным. Кроме того, есть еще 2 более подробных ответа, и ваш ответ, похоже, ничего не добавляет.

Я сомневаюсь, что концепция, которую я опубликовал, неверна? Не могли бы вы пояснить мне это?

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

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

ОП спросил "Это неопределенное поведение?". Ваш ответ не говорит.

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

Это вопрос [языкового юриста], но это не тот ответ, который работает со стандартом, что делает его неактуальным. Кроме того, есть еще 2 более подробных ответа, и ваш ответ, похоже, ничего не добавляет.

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

@melpomene - Так это на самом деле произвольно в C? Хорошо, я еще раз отредактирую. Результат должен быть таким же, хотя шаги могут и не быть. Также я помню темные времена, когда меня заставляли писать на C в курсе ... как я не скучаю по тем дням.

Результатом «не должно быть» ничего конкретного, потому что поведение не определено. См. Мой ответ для обоснования.

@melpomene - даже если он не определен в стандартах, на практике компилятор может обрабатывать его последовательно. Я цитирую вас: «Поскольку стандарт C четко не определяет, что здесь происходит, я считаю, что поведение не определено (по пропуску)». - Учитывая, что это можно проверить, нет необходимости в домыслах. И нет никаких оснований утверждать, что ваши домыслы, основанные на недостатке информации (как вы сказали - «по бездействию»), являются веским доказательством. Есть теория и есть практика. Вы привели аргументы в пользу того, почему теоретически это не (хорошо) определено - хорошо. Но никто из нас не проверял это.

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

@melpomene - вы тестируете код из моего примера достаточное количество раз и смотрите, согласуются ли результаты. Вносите вариации там, где, по вашему мнению, возникают несоответствия. Если это непоследовательно, вы можете сказать, что это не окончательно и действительно несколько произвольно. Это было бы твердым доказательством. Иначе что? Отсутствие документации и предположений, основанных на указанной недостающей документации. Что ж, тогда скажите людям, которые работают над компилятором, исправить их документацию. Докажите, что я ошибаюсь, и я с радостью уступлю и удалю или отредактирую свой ответ.

"Вы тестируете код из моего примера достаточное количество раз и смотрите, согласуются ли результаты." Это не так. Кажется, вы не понимаете, что такое неопределенное поведение. Все в C по умолчанию имеет неопределенное поведение; просто некоторые части имеют поведение, определенное стандартом. Чтобы доказать, что что-то определило поведение, вы должны процитировать стандарт и показать, где он определяет, что должно происходить. В отсутствие такого определения поведение не определено.

Утверждение в пункте (1) - это огромный шаг вперед по сравнению с ключевым вопросом здесь: происходит ли неявная инициализация элемента a [2] значением 0 до того, как будет применен побочный эффект выражения инициализатора a[2] = 1? Наблюдаемый результат такой, как если бы он был, но стандарт, похоже, не указывает, что это должно быть так. Что - центр спора, и этот ответ полностью игнорирует его.

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

TL; DR: с помощью тщательных тестов вы можете установить (в любой желаемой степени), как какой-либо конкретный компилятор обрабатывает этот код, но это ничего не скажет вам о том, что стандартное говорит должно происходить с этим кодом, и в этом заключается вопрос . Достаточно ясно, как «очевидный» или «разумный» компилятор может обработать этот код, но language-lawyer не в этом. Если бы C был определен в соответствии с тем, как работает один конкретный эталонный компилятор (некоторые языки действительно работают таким образом), это было бы другое дело.

@Jeroen Mostert - Вопрос был такой: «Я не понимаю, почему [0] выводит 1 вместо 0? Это неопределенное поведение?» - Я ответил на первую часть и расширил ее другим примером, оставшись лаконичным. Есть система голосования, я вижу, вы оба проголосовали против, радуйтесь и идите дальше. Подправил то, что нужно, но все. Черт, это не естествознание, это просто о некоторых людях, которые недостаточно хорошо выполняют свою работу (не то чтобы я хотел их критиковать), и что их поведение остается неопределенным. Это все. После исправления (если вообще когда-либо) этот диалог устаревает.

Существует только одно выражение списка инициализации, поэтому §23 не имеет значения.

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

@KamiKaze: конечно, значение 1 попало туда случайно.

похоже, что эта языковая тема юриста запрашивает ссылки из типовых проектов. Вот почему вас голосуют против (я этого не делал, как вы видите, меня проголосовали против по той же причине). Я думаю, что то, что вы написали, совершенно нормально, но похоже, что все эти языковые юристы здесь либо из комитета, либо что-то в этом роде. Таким образом, они вообще не просят о помощи, они пытаются проверить, охватывает ли черновик дело или нет, и большинство ребят здесь срабатывают, если вы отвечаете, как будто помогаете им. Думаю, я удалю свой ответ :) Если бы правила этой темы были четко изложены, это было бы полезно