Указатели на строку в С Опции

[zltigo]

Как по мне - malloc/free - это принципиально другой подход к хранению и обработке данных, чем статический массив.

Абсолютно такой-же. Все различие в том, что в одном случае указатель есть обязательно, а во втором его может и не быть в явном виде. Все. Ну и free() не сделаешь . В обшем один вариант частный случай другого и не более того. Общий вариант просто и БЕЗ ВСЯКИХ ПОБОЧНЫХ ЭФФЕКТОВ (кроме расхода памяти на MCB, если в хипе выделяется память) приводистся к частному. Более того, динамическое выделение памяти оно сплошь и рядом - все локальные пеерменные на то они и локальные, что на них выделяется память НЕ статически. И ничего страшного.

[GetSmart]

И реализация для обоих вариантов Array[index] и index[Array] исходя из определения получается идентичная с точностью до порядка слагаемых.

Пишите тогда уж "исходя из данного определения". Второй вариант навязан, бесполезен и вреден. Оснований таких его последствий как ухудшение читабельности и ослабления безопасности не обозначено. Вред должен искореняться.

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

Осмысленно, осмысленно. Есть такое понятие как читабельность. Которое обязано быть всегда в приоритете у разработчиков. И она ни с чем в данном вопросе не конфликтует.

Разумеется нет. Порядок "разборки" вообще никакого значения не имеет к языку. Важен порядок вычисления выражений, который идет в соответствии с приоритетом операций и формами записей.

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

Сообщение отредактировал GetSmart - Jan 25 2016, 22:21

[Сергей Борщ]

Пишите тогда уж "исходя из данного определения".
...
Есть такое понятие как читабельность. Которое обязано быть всегда в приоритете у разработчиков. И она ни с чем в данном вопросе не конфликтует.

Определение дано в стандарте языка. Не нравится - "обратитесь во всемирную в Лигу сексуальных реформ".

[GetSmart]

Определение дано в стандарте языка. Не нравится - "обратитесь во всемирную в Лигу сексуальных реформ".

С какой формулировкой обратиться?

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

Сообщение отредактировал GetSmart - Jan 26 2016, 00:33

[Сергей Борщ]

С какой формулировкой обратиться?

Вам виднее.

Версий стандартов много. Я спрашивал какого, вы не ответили.

Во всех трех (C89/90, C99 и C11) формулировка идентична. Выбирайте любой.

[GetSmart]

Вам виднее.

Напомнило контекст фразы "если ты не знаешь, я тебе не скажу".

Во всех трех (C89/90, C99 и C11) формулировка идентична. Выбирайте любой.

Остановлюсь на найденной мной. В преамбуле источника есть "fundamentals of C".

[zltigo]

Я написал компилятор разбирает выражения...

Как разбирать выражения компилятору - вдоль, поперек, слева....это его интимное дело НИКАК не регламентируемое стандартами.

[Сергей Борщ]

Напомнило контекст фразы "если ты не знаешь, я тебе не скажу".

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

Остановлюсь на найденной мной. В преамбуле источника есть "fundamentals of C".

-Слышал я вашего Карузо, полная фигня!
-Великий Карузо выступал в Одессе?
-Нет, мне Мойша напел.

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

А я откланиваюсь.

[GetSmart]

Как разбирать выражения компилятору - вдоль, поперек, слева....это его интимное дело НИКАК не регламентируемое стандартами.

Влияет на терминологию и определения. В определениях нет ни лева ни права, но используется "идёт за" и постфикс. Постфикс и постфиксное выражение тоже по-своему трактуется? Или строго правее основного в тексте? Где читал не увидел вообще определение постфиксного выражения. Мы с вами, те, которые стандартизаторы, и вообще большинство читают слева направо. В общеупотребляемой терминологии подобные умолчания подразумеваются. И в определениях их умалчивание считается вариантом нормы, если оно влияет. Удивляет вообще "их" терминология. Казнить нельзя помиловать в нагрузку к стандарту.

Вообще-то очевидно, что оно есть rvalue.

нет.

Вы не могли бы прояснить отличие от данной версии. Я признал, что к строке можно применить индекс и амперсанд. Хотя к обычным rvalue такое неприменимо. К строке это применимо, если считать что она rvalue с возможностью неявного преобразования , когда к ней применяется индекс, амперсанд и в некоторых других случаях. Можно назвать её rvalue-строка. Если за строкой без всяких операторов идёт ещё одна строка, то они состыковываются и образуют одно rvalue. Что для rvalue-строк пусть будет применимо. К rvalue склоняюсь потому, что это тоже тип "значение", пока оно в компиляторе обрабатывается в состоянии до неявного преобразования. А не объект с адресом. А уж если индексируется по rvalue-константе, то никакого lvalue там создавать не нужно. И в определении глобального lvalue она тоже не доходит до неявного преобразования (в котором компилятор для неё должен выделять место или найти аналогичное ранее созданное lvalue), а берётся её чистое значение (ака rvalue) и помещается в конкретно заданную область. Неявное преобразование rvalue-строки особенно тем, что есть два варианта. Можно сказать две стадии. Зависит от типа получателя или применённого оператора. Первая стадия: находится или создаётся lvalue в области памяти констант, а тип текущего выражения становится lvalue - char const. Применяя к строке амперсанд неявным будет этот вариант, т.о. вместе с амперсандом тип выражения будет rvalue - char const *. Передавая строку в качестве аргумента функции , в дополнение к первому будет вторая стадия: неявное взятие адреса данного lvalue - char const. После неё будет rvalue - char const *. Вторая стадия эквивалентна действию амперсанда. Cразу на этапе компиляции выражение *(&"abc") даст первый символ, а не исходное rvalue. Не знаю как стандарт применяет амперсанд к строке, если допускает. И как толкует предыдущее выражение. Выделение места в области памяти констант для содержимого строки будет не сразу. Компилируя выражение, если строка превращается в rvalue-char в описанных ранее случаях, то поиска/создания lvalue не происходит.

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

В итоге: содержимое строки (массив символов) по сути одинаковое и в процессе разбора компилятором, и в области памяти констант, если считать с добавочным нулём. Данное содержимое логично называть rvalue (полностью: rvalue-строка). В процессе неявных преобразований тип rvalue-строка превращается в другой, а обратного преобразования не существует. Конфликта нет. Но если бы было обратное, то зависило бы от реализации. \0' должен так же выдаваться компилятором, если во время компиляции из строки берётся элемент с номером/индексом равном длине строки. Если номер больше, то ошибка компиляции. Применимость sizeof - по желанию.

Сообщение отредактировал GetSmart - Jan 27 2016, 07:48

[sigmaN]

Честно прочитал все сообщения. Так и не понял почему тема до сих пор не исчерпана и товарищ GetSmart продолжает что-то там писать. Вроде бы и с наличием умных терминов, но как-то без особого смысла....

[smalcom]

Welcome to electronix ))

[Serg76]

Вроде бы и с наличием умных терминов, но как-то без особого смысла....

Я бы выступил с предложением о введении в обиход electronix нового термина GetSmartенизм, суть которого Вы раскрыли.

[GetSmart]

An operator is called a Postfix Operator when the operator follows the operand. Postfix Operators may operate on either one or two operators. There are five postfix operators in C:

1. Array subscripts
2. Function Call
3. Structure and Union Members
4. Postfix Increment and Decrement Operators
5. Compound Literals

Добавлю. Определение subscripts (по-русски индексации), зацитированное в этой ветке из стандарта, в сочетании с терминологией некорректна в обоих предложениях. Термин постфикс-оператор обязывает оператор следовать за операндом, к которому тот применим. Хоть вторая часть явно не указана, но она очевидна ещё из списка двухоперандных постфикс-операторов компилятора (не препроцессора). При иных требованиях к операндам оператор называется не постфикс-оператором, а оператором другого рода. Т.о. без вынесения оператора subscripts из списка постфикс-операторов получается некорректная ерунда. Если ерунда содержится в какой-то части стандарта, то наиболее адекватно её не учитывать. А если его вынести из постфикс-операторов, то явно нарушится общность с другими операторами обращения к члену/субэлементу. Которая есть в корректной части стандарта.

По поводу строк. Если по сути вещей в кавычках находится значение, и называя его значением aka rvalue упрощается логика без каких-либо противоречий, то это вполне законно.

Сообщение отредактировал GetSmart - Feb 5 2016, 20:55

[sigmaN]

Если ерунда содержится в какой-то части стандарта, то наиболее адекватно её не учитывать. А если его вынести из постфикс-операторов, то явно нарушится общность с другими операторами обращения к члену/субэлементу. Которая есть в корректной части стандарта.

Мне нравится как лихо стандарт(СТАНДАРТ) разделен на ерундовую часть которую надо игнорировать и корректную.

Как хорошо, что вы не писали компиляторы, которыми мы все пользуемся )))))

[krux]

GetSmart
пока ваш 'компилятор' не может собрать libstdc и boost - вас просто не существует. ни для кого в этом мире.