Инициализация структуры Опции

[GetSmart]

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

Не удержался. Третий раз дополнил предыдущий пост.

Позже почитаю, после отпуска.

Сообщение отредактировал GetSmart - Aug 3 2018, 07:03

[aiwa]

Сложение с именем массива:
result = *(array+5)

Сложение с указателем (на тип элементов из которых состоит массив):
result = *(&array[0]+5)

В цитате было (буквально) сложение с именем массива.

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

Приведенные Вами два примера отличаются лишь небольшой деталью.
Во втором Вы сами используете указатель, а в первом тот же указатель получается "implicitly" - согласно стандарту: "by converting an array name to a pointer".

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

Ну да, про коммутативность это понятно - побочный эффект.
Равно как по той же причине в массиве размерности 5x5 доступ к "последнему" элементу a[4][4] вполне может быть реализован как a[15][0] или a[0][15].

[GetSmart]

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

Приведенные Вами два примера отличаются лишь небольшой деталью.
Во втором Вы сами используете указатель, а в первом тот же указатель получается "implicitly" - согласно стандарту: "by converting an array name to a pointer".

Определение дано на текстовом примере. После этого запрещать описание словами текстовых конструкций языка бессмысленно. Кроме того, в данном контексте <имя массива> более однозначно описывает <инструкцию> писателя кода. Если я напишу <массив>, то сразу подменю обсуждаемую <инструкцию> до многих вариантов текстового представления. Поэтому такие формулировки имеют право быть. Добавлять везде <в тексте> излишне, это неявно контекстно подразумевается. Скорее будет важно: до препроцессора или после, всякие области видимости, наложения имён переменных, макросов и прочего. По-умолчанию в таких формулировках разумно считать, что интерпретация текста по стандарту в том тексте выявит однозначно: имя массива, оператор сложения и целое число 5. И оператор сложения будет выполнен до всех иных операторов.

Равно как по той же причине в массиве размерности 5x5 доступ к "последнему" элементу a[4][4] вполне может быть реализован как a[15][0] или a[0][15].

Ерунда какая-то. 5*5=25

Сообщение отредактировал GetSmart - Aug 3 2018, 12:54

[aiwa]

...Если я напишу <массив>, то сразу подменю обсуждаемую <инструкцию> до многих вариантов текстового представления. Поэтому такие формулировки имеют право быть.

В оригинале сказано именно массив, что эквивалентно указателю на первый элемент: "if E1 is an array object (equivalently, a pointer to the initial element of an array object)"
Но если массив или имя массива смотрятся как синонимы, то "прибавление к имени массива" как-то не комильфо.

Ерунда какая-то. 5*5=25

Ну да, отвлекся и написал для массива 4x4, правильно было бы а[0][24] и a[24][0]. Но не важно, - главное, что коммутативность арифметики с указателем приводит к такому побочному эффекту.
Поэтому не стоит это ставить во главу угла.

Сообщение отредактировал aiwa - Aug 3 2018, 13:01

[GetSmart]

В оригинале сказано именно массив, что эквивалентно указателю на первый элемент: "if E1 is an array object (equivalently, a pointer to the initial element of an array object)"

<(equivalently, a pointer> в данном контексте переводится как: <(равно{значно} {допустимо}, если это указатель>
фигурными скобками выделил неявный смысл, который, при желании, можно не писать. В контексте этого абзаца <equivalently> не определяет, что везде в языке оба варианта равнозначны. Ещё, из этой цитаты не понять, какое действие вызывает оператор [], применимый к обычному указателю. Даже из всей главы <6.5.2.1 Array subscripting> непонятно, какое действие по стандарту выполняет применение [] к указателю на не массив (на не элемент массива). В её вступлении написали

One of the expressions shall have type "pointer to
object type", the other expression shall have integer type,
and the result has type "type"

Далее везде "если это массив или указатель на начальный элемент массива то ...".
PS но я мельком прочитал эти три абзаца. Прошу опровергнуть, если я неправ.

Upd
Учитывая вступительную цитату, с которой я только что ознакомился моё утверждение <В цитате было (буквально) сложение с именем массива. >
правильнее заменить на <В цитате вполне допускалось сложение с именем массива.>

Сообщение отредактировал GetSmart - Aug 3 2018, 14:33

[aiwa]

В контексте этого абзаца <equivalently> не определяет, что везде в языке оба варианта равнозначны.

Та там всего три абзаца, из которых следует вывод, что имя массива почти всегда (за исключением, например, sizeof правила для которого обговорены в отдельном пункте) преобразуется в указатель на первый элемент массива причем того же типа. С дальнейшими правилами действий для такого указателя.
Таким образом из выражений *((E2+5)+E1), ((E2)+5+(E1)) и подобных невозможно что-либо утверждать про размерности массива.

Даже из всей главы <6.5.2.1 Array subscripting> непонятно, какое действие по стандарту выполняет применение [] к указателю на не массив (на не элемент массива).

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




Сообщение отредактировал aiwa - Aug 3 2018, 14:20

[GetSmart]

В стандарте есть явные определения логики интерпретации применения [] к указателю на не массив и на не элемент массива?

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

Никаких <почти всегда> оттуда не следует. Тем более, что что-то там преобразуется. Смысл написанного: <допускается писать такую конструкцию с такими-то вариантами, которая будет истолкована так...>

Сообщение отредактировал GetSmart - Aug 3 2018, 15:13

[aiwa]

В стандарте есть явные определения логики интерпретации применения [] к указателю на не массив и на не элемент массива?

Нет. Оператор [] значится как postfix-operator и определен для "array subscripting". Это признак массива.

Никаких <почти всегда> оттуда не следует.

"Почти всегда" следует потому в случае оператора sizeof, согласно которому имя_массива преобразуется в тип "массив заданной размерности",
в остальных случаях имя_массива преобразуется в &имя_массива[0].

[GetSmart]

Ну да, отвлекся и написал для массива 4x4, правильно было бы а[0][24] и a[24][0]. Но не важно, - главное, что коммутативность арифметики с указателем приводит к такому побочному эффекту.

Это по шагам можете объяснить?
Мне понятны варианты когда а[0][24] идентичен a[1][19] и идентичен a[2][14] и т.д. Если не обращать внимание на варнинги компилятора. Но a[24][0] каким образом-то?

2. и 3. указатель на (E1+5)-й элемент массива E2.

index1[index2][array_name] и index1[index2][index3][array_name] тоже разрешены? Если да, исходя из каких формулировок?

Нет. Оператор [] значится как postfix-operator и определен для "array subscripting". Это признак массива.

То есть разрешение применения [] к любому указателю на непустой тип даёт именно первый абзац главы <6.5.2.1 Array subscripting> ? object type определён как любой, за исключением void? В стандарте есть суммарный раздел об авто-преобразованиях? Или надо шерстить весь стандарт чтобы откопать однозначность?

Видимо отсюда и растут ноги у названия "подписка". Страннейшего, для необкуренных мозгов. Обозвали бы "индексация" и уловка с авто-подменой была бы недоступна.

В посте 40 я ошибся, в цитате:
<И уже когда к этому аргументу будет приплюсовываться число 5, то оно, проще говоря, должно быть (наиболее вероятно по вышеобозначенной инфе) индексом следующей (второй) размерности.>
т.к. на следующую размерность не перейти, без применения оператора * в вариантах со сложением.

"Почти всегда" следует потому в случае оператора sizeof, согласно которому имя_массива преобразуется в тип "массив заданной размерности",
в остальных случаях имя_массива преобразуется в &имя_массива[0].

Ну бред же. Для компилятора имя массива - это lvalue (кратко - объект в памяти). К нему можно применить амперсанд. &имя_массива[0] - это rvalue, к нему (здесь будет второй раз) амперсанд не применим. И для (простейше определённого) многомерного массива array_name[0] есть тоже lvalue. А, согласно этой цитаты, выражение &(array_name[0]) давало бы ошибку. Т.к. выражение в скобках, являющееся массивом авто-преобразовывалось бы в указатель. Хотя, корректней писать в <rvalue-указатель>. Всё это потверждает, что и rvalue с типом указатель на массив и lvalue с типом массив существуют без всякого sizeof, в них определена характеристика размера (для размерных), компиляторы поступают вполне разумно её проверяя на этапе компиляции, а что мешает копировать массивы выражениями вроде a=b - непонятно.

В языке должна быть ясность очерёдности исполнения авто-преобразований и операторов. Например: авто-преобразования применяются компилятором в самый последний момент исполнения операторов. И не должны менять приоритеты операторов при определении очерёдности их исполнения. Хотя, с таким неполным стандартом, если по нему ясность поведения будет не определена, то, наверное, судить придётся по каким-то ещё документам, например от выдумщика языка. А то появится несогласующийся с ранее написанными правилами футбол между операторами, операндами и авто-преобразованиями. (в этой ветке я ранее писал аргументов, но терминологически точнее, видимо, операндов для операторов и аргументов/параметров для функций)

Пытаясь как-то оправдать логику выдумщика и потом стандарта, когда на начальном этапе массив (array object по терминологии главы 6.5.2.1) казался избыточным и работу с массивами НАДО БЫЛО организовывать через указатели и операторы +-, которым был непринципиален порядок разношёрстных операндов, мне самому любопытно, на какой развилке не туда свернули)))
Упд. Именно такая историческая цепь прослеживается при чтении стандарта, когда оператор [] определяется текстовым примером через ранее определённые выражения.

Сообщение отредактировал GetSmart - Aug 4 2018, 07:40

[aiwa]

index1[index2][array_name] и index1[index2][index3][array_name] тоже разрешены? Если да, исходя из каких формулировок?

Согласно 1-му пункту "подписки" это нелегально. Потому что в части выражения "index1[index2]..." один из этих индексов должен быть "pointer..."

Это по шагам можете объяснить?
Мне понятны варианты когда а[0][24] идентичен a[1][19] и идентичен a[2][14] и т.д. Если не обращать внимание на варнинги компилятора. Но a[24][0] каким образом-то?

Если по шагам, то этот пример я хотел привести намного раньше, когда Вы в ((E1)+(E2)+5) предлагали видеть в 5-ке индекс второй размерности.
Но я ошибочно начал тавтологию про типоразмеры. Но так как мне показалось, что мы толчем воду я его и привел с опозданием.

Вы правы, если продолжить ряд , то должны прийти к правильному решению похожему на a[24][-64].
Или сразу применить формулу, по которой добавляя число к первому индексу, мы должны отнимать это число, умноженное на 5 от второго. 5 и выступает в качестве типоразмера. Имхо, пример хорошо иллюстрирует рекурсивность правила для многомерных массивов.

То есть разрешение применения [] к любому указателю на непустой тип даёт именно первый абзац главы <6.5.2.1 Array subscripting> ? object type определён как юбой, за исключением void? В стандарте есть суммарный раздел об авто-преобразованиях? Или надо шерстить весь стандарт чтобы откопать однозначность?

Я не знаю стандарт достаточно хорошо. Помню в свое время всем отделом шерстили именно по указанной теме.
Но похоже, что действует принцип: "разрешено все, что не запрещено". Поэтому использование "подписки" для указателя вполне законно.

Только я не уверен, что термин в стандарте эквивалентен нашему пониманию "подписки".

Ну бред же. Для компилятора имя массива - это lvalue (кратко - объект в памяти). К нему можно применить амперсанд. &имя_массива[0] - это rvalue, к нему (здесь будет второй раз) амперсанд не применим. И для (простейше определённого) многомерного массива array_name[0] есть тоже lvalue.

Ну я условно, для краткости, чтобы не писать присутствующее в каждом посте "pointer to....".

Пытаясь как-то оправдать логику выдумщика и потом стандарта, когда на начальном этапе массив (array object по терминологии главы 6.5.2.1) казался избыточным и работу с массивами НАДО БЫЛО организовывать через указатели и операторы +-, которым был непринципиален порядок разношёрстных операндов, мне самому любопытно, на какой развилке не туда свернули)))

Но почему Вы считаете, что они свернули не туда? Они реализовали "ассемблерные возможности" на высоком уровне. И это есть хорошо.
И не дай бог они повернут туда: зачем нам третья java, или четвертый шарп?

Сообщение отредактировал aiwa - Aug 4 2018, 08:09

[XVR]

Пошла 4 страница трёпа вокруг массива/указателя... Ещё 6 страниц и можно ожидать переходы на личности и мерянье пиписьками
Пошёл за попкорном

[GetSmart]

Но почему Вы считаете, что они свернули не туда?

Как буд-то родился "кошмар на улице си" index[array]. Не прочитав всю кучу документов точно и не разберёшься.

Полноценный перевод этого мутного термина я не знаю. В каких-то словарях компьютерных терминов его кастрируют до <индексация>. Но в общеупотребительном смысле это слово более многогранное. Со смыслами <одобрить>, <согласиться>. Пока (если лучше версию не увижу), наверное буду считать в Си "признать массивом и индексировать". Но у буржуев есть какой-то схожий термин "superscripting" (superscription-надпись, в общеупотребительном аглицком), которе вместе (теоретически наверно) могут как-то обозначать вариации индексаций "вглубь" (для массивов) или наружу (для указателей). Но с такими тонкостями толкования я пока не пересекался.

Мутность такая же, как при переводе термина bitwise (complement), о котором когда-то спорили.

Сообщение отредактировал GetSmart - Aug 5 2018, 06:13

[aiwa]

Но у буржуев есть какой-то схожий термин "superscripting" (superscription-надпись, в общеупотребительном аглицком), которе вместе (теоретически наверно) могут как-то обозначать вариации индексаций "вглубь" (для массивов) или наружу (для указателей).

Так буквальный перевод subscript и означает индекс (нижний или верхний).

[Arlleex]

Действительно какая-то пьянка вокруг массива и указателя. Не вижу принципиальной разницы как получать доступ к элементам памяти - через [] или через *(). Если присутствует многомерность памяти, определяю указатель на тип строки такого массива и также адресую - либо индексно, либо *().
Кстати, при объявлении массива можно полностью избавиться от его идентификатора (в C99) и присвоить его адрес указателю.

[Herz]

Так буквальный перевод subscript и означает индекс (нижний или верхний).

Не совсем. Верхний индекс принято называть именно superscript.