Я-то всегда полагал, что переменная a — это и есть ячейка памяти, которая содержит адрес первого элемента массива.
Это абсолютно не верно. Учитывая, сколько усилий было потрачено различным источниками на то, чтобы развеять это странное заблуждение, не ясно, как кто-то может в 2022 году "всегда полагать" что-то подобное.
Это какой-то странный пример несложной демагогии. Каким образом упомянутый мною единичный пример организованной бот-атаки может служить свидетельством того, что "в моей картине мира свободный выбор невозможен"?
Так о том и речь шла изначально. Хорошая доза "Этадругина" - и буквально на глазах унылая бот-атака превращается... атака превращается... превращается... в элегантный честным флэшмоб задолбавшихся граждан.
Я думаю, народ, что мы с вами присутствуем при первом контакте с параллельной вселенной!!1 Или, что менее прозаично, с очередной поисковой проблемой, вызванной флексией...
Ну зачем же так неуёмно фантазировать? Делаем поиск по странице в статье на VC и даже не успев набрать слова целиком попадаем на слова "Официальный Телеграм-канал Банка России. Давайте признаем: второй пост неплохо завирусился – вполне мог бы принадлежать перу нашего маэстро…"
Я кажется ясно объяснил в своем предыдущем комментарии, о чем идет речь. А словосочетание "Банк России" позволяет однозначно найти соответствующее место в прилинкованной статье. С чем именно вы испытываете затруднения?
Никто и не утверждал, что данные не хранят в union. Наоборот, основное назначение union - разделяемое использование памяти (т.к. экономия памяти) при хранении объемных данных. Именно для этого в подавляющем большинстве случаев и используется union. А хранение объемных данных обычно именно долгосрочно. Вы сами привели примеры такого использования.
Здесь же речь шла о совсем другом, побочном использовании union - использовании его для выполнения type-punning, то если для переинтерпретации памяти. (Переинтерпретация памяти, кстати, не является "кастом". Не ясно почему вы упомянули этот термин выше.)
Я вел речь именно об этом побочном использовании union. То есть никто не будет выбирать union для долгосрочного хранения именно из-за того, что где-то в какой-то момент кому-то может вдруг понадобится переинтерпретация.
Oh the irony! В прилинкованной (и имеющий эдакий легкий дурноватый запашок) статье того же автора на VC глумливо смакуются якобы "завирусившиеся" атаки ботов на посты Банка России в его Телеграм-канале. А здесь автор пылает праведным гневом после того, как подвергся атаке ботов сам...¯\_(ツ)_/¯
После прочтения всего этого не покидает ощущение, что мы наблюдаем борьбу одного "инфоцыгана" (термнология автора) с другим. А движет ли ими монетизация или "просто для души"... в современном интернет-мире это не принципиально.
А, понял... Вы имеете в виду, что, несмотря на выраженную внешнюю похожесть designated initializers в С и С++, их спецификации все таки существенно отличаются. Да, верно. Это формально соответствует моим критериям. Просто фича эта в С++ все еще производит впечатление "слишком новой"...
Это - следствие того, что в массовых аппаратных архитектурах начали активно появляться и/или выходить на передний план фичи, которые получают существенную пользу от эксплуатации оптимизационных возможностей, кроющихся в неопределенном поведении. Это и векторизация, и многопоточность, и многоядерность, и еще много чего.
Людям испокон веков говорили, что этот день настанет и ваше пренебрежительное отношение к UB вернется, чтобы укусить вас за задницу. Они игнорировали эти предупреждения. Теперь не надо жаловаться, что кому-то там "сломали код".
То же самое: restrict - очевидная и "бросающееся в глаза" возможность о С99, по каковой причине в мой список она не включена. Это именно то, о чем я говорю в начале: не составит труда построить примеры С99 кода на основе новых ключевых слов. Меня это не интересовало.
Это появилось еще в C99. Опять же - это примеры "бросающихся в глаза" свойств, специфичных именно для C99, поэтому в свой список я их не включал. Практически весь мой список (за редкими исключениями) построен на свойствах "классического" C89/90.
Ваш второй пример - это не "константный массив". Для "константного массива" не нужно никакого специального синтаксиса
void someFunction(const char someArray[]);
Приведенный же вами пример декларирует константность самого параметра-указателя, то есть эквивалентен void someFunction(char *const someArray);
Начиная с C23 поддержка variably modified types становится обязательной. Опциональной останется лишь возможность создавать автоматические объекты такого типа, то есть создавать VLA в стеке.
Это абсолютно не верно. Учитывая, сколько усилий было потрачено различным источниками на то, чтобы развеять это странное заблуждение, не ясно, как кто-то может в 2022 году "всегда полагать" что-то подобное.
И что именно этот код должен демонстрировать???
Использование VLA в таких случаях - спорный совет, но тем не менее: а что за компилятор скрывается за этим IAR?
Это какой-то странный пример несложной демагогии. Каким образом упомянутый мною единичный пример организованной бот-атаки может служить свидетельством того, что "в моей картине мира свободный выбор невозможен"?
Так о том и речь шла изначально. Хорошая доза "Этадругина" - и буквально на глазах унылая бот-атака превращается... атака превращается... превращается... в элегантный честным флэшмоб задолбавшихся граждан.
Толсто
Ну, то есть, в телеграм-канале Банка России - это другое...
Я думаю, народ, что мы с вами присутствуем при первом контакте с параллельной вселенной!!1 Или, что менее прозаично, с очередной поисковой проблемой, вызванной флексией...
Ну зачем же так неуёмно фантазировать? Делаем поиск по странице в статье на VC и даже не успев набрать слова целиком попадаем на слова "Официальный Телеграм-канал Банка России. Давайте признаем: второй пост неплохо завирусился – вполне мог бы принадлежать перу нашего маэстро…"
Я кажется ясно объяснил в своем предыдущем комментарии, о чем идет речь. А словосочетание "Банк России" позволяет однозначно найти соответствующее место в прилинкованной статье. С чем именно вы испытываете затруднения?
Вы о чем?
Никто и не утверждал, что данные не хранят в union. Наоборот, основное назначение union - разделяемое использование памяти (т.к. экономия памяти) при хранении объемных данных. Именно для этого в подавляющем большинстве случаев и используется union. А хранение объемных данных обычно именно долгосрочно. Вы сами привели примеры такого использования.
Здесь же речь шла о совсем другом, побочном использовании union - использовании его для выполнения type-punning, то если для переинтерпретации памяти. (Переинтерпретация памяти, кстати, не является "кастом". Не ясно почему вы упомянули этот термин выше.)
Я вел речь именно об этом побочном использовании union. То есть никто не будет выбирать union для долгосрочного хранения именно из-за того, что где-то в какой-то момент кому-то может вдруг понадобится переинтерпретация.
Oh the irony! В прилинкованной (и имеющий эдакий легкий дурноватый запашок) статье того же автора на VC глумливо смакуются якобы "завирусившиеся" атаки ботов на посты Банка России в его Телеграм-канале. А здесь автор пылает праведным гневом после того, как подвергся атаке ботов сам...¯\_(ツ)_/¯
После прочтения всего этого не покидает ощущение, что мы наблюдаем борьбу одного "инфоцыгана" (термнология автора) с другим. А движет ли ими монетизация или "просто для души"... в современном интернет-мире это не принципиально.
Не совсем ясно.
Правила алиасинга в С ничем принципиально не отличаются от правил алиасинга в С++. Это тем не менее не делает
restrictбесполезным в С.В C++ и вопроса бы такого не возникло, ибо там исходный вариант - корректен.
Определения функция в стиле K&R - хрестоматийная фича "классического" C. Это все является derecated с C89/90 и покидает язык окончательно в C23.
А, понял... Вы имеете в виду, что, несмотря на выраженную внешнюю похожесть designated initializers в С и С++, их спецификации все таки существенно отличаются. Да, верно. Это формально соответствует моим критериям. Просто фича эта в С++ все еще производит впечатление "слишком новой"...
Это - следствие того, что в массовых аппаратных архитектурах начали активно появляться и/или выходить на передний план фичи, которые получают существенную пользу от эксплуатации оптимизационных возможностей, кроющихся в неопределенном поведении. Это и векторизация, и многопоточность, и многоядерность, и еще много чего.
Людям испокон веков говорили, что этот день настанет и ваше пренебрежительное отношение к UB вернется, чтобы укусить вас за задницу. Они игнорировали эти предупреждения. Теперь не надо жаловаться, что кому-то там "сломали код".
То же самое:
restrict- очевидная и "бросающееся в глаза" возможность о С99, по каковой причине в мой список она не включена. Это именно то, о чем я говорю в начале: не составит труда построить примеры С99 кода на основе новых ключевых слов. Меня это не интересовало.Это появилось еще в C99. Опять же - это примеры "бросающихся в глаза" свойств, специфичных именно для C99, поэтому в свой список я их не включал. Практически весь мой список (за редкими исключениями) построен на свойствах "классического" C89/90.
Ваш второй пример - это не "константный массив". Для "константного массива" не нужно никакого специального синтаксиса
void someFunction(const char someArray[]);Приведенный же вами пример декларирует константность самого параметра-указателя, то есть эквивалентен
void someFunction(char *const someArray);Вы пытаетесь меня запутать. Я пока что утверждал следующее:
В С неявное преобразование между
enumиintработает в обе стороныВ С++ неявное преобразование между
enumиintработает только в одну сторону:enum -> intВ С++ неявное преобразование между
enum classиintвообще не работает ни в какую сторонуЧто здесь не верно? И где я утверждал что-то другое?
P.S. Наверное, так можно проинтерпретировать текст самой публикации, где я не уточнил, что преобразование в одну сторону в С++ есть... Поправил текст.
Начиная с C23 поддержка variably modified types становится обязательной. Опциональной останется лишь возможность создавать автоматические объекты такого типа, то есть создавать VLA в стеке.