Comments 38
доведем задачу до абсурдаПо-моему у вас получилось. Почему 0x17? Из-за 0x0b?
Второй пример сильно попахивает неопределённым поведением и индексацией случайных адресов памяти. Или я неправ?
Я обдумывал идею добавить разборы, но они сделали бы статью существенно скучнее. В итоге решил оставить без пояснений, благо комментарии позволяют обсудить конкретные места.
Нет. (!true)["true"]
— это то же самое что "true"[0]
, т.е. символ 't'. Со второй частью аналогично.
x[y]
раскрывается в *(x + y)
.Только насчёт x + y не согласен, потому что здесь это явно раскрылось в y+x. Арифметика указателей разве коммутативна?
Коммутативность не имеет никакого отношения к "арифметике указателей". Коммутативен встроенный бинарный оператор +
и коммутативен абсолютно всегда, безусловно и во всех контекстах.
Простите, но там в начале разве должна быть O (буква) или все же 0 (цифра)?
int Ox01 = ~-~-~-~-~-~-~-~-~-' ';
P.S сори, промахнулся веткой :(
Во-первых, ваши решения написаны не на С, а на GCC, да и те платформеннозависимы. Такие задачи интереснее решать именно на стандартном С. Ваши решения в большинстве своем к С относятся мало или вообще никак.
Во-вторых, ideone в профессиональных кругах не считается уважаемым или убедительным ресурсом, особенно в вопросах С, поэтому заявления вида "для сомневающихся — ссылка на ideone" никаких сомнений не развеивают, а могут вызвать лишь facepalm.
Запросто!
На "во-первых" аргументы очевидны: большинство вариантов завязаны на свойство платфоременно-зависимого character set. Вот и все. К тому же фактически способов что-то сделать у вас от силы три. И один из них — применение *
к строковому литералу — раздут в огромное число вариантов. Зачем было делать искусственное и скучное раздувание этих способов в такое количество уныло повторяющихся вариантов — не ясно. Это же сразу бросается в глаза.
Найти остроумные решения, которые бы работали на настоящем стандартном С — вот это действительно интересная задача, потому что в ней заключается challenge. А ваши чисто косметические выверты на фактически готовеньком результате (т.е. на конкретных значениях character constants) — примитивная пустышка/профанация для студенток-первокурсниц.
На "во-вторых" аргументы тоже несложны: хорошо известно, что ideone занимается наглой пост-фильтрацией диагностических сообщений компилятора. Не видя стандартных диагностических сообщений компилятора рядовой пользователь не сможет судить о корректности кода. Ваш код грубо ошибочен, но тем не менее проглатывается ideone — вескость этого аргумента переоценить невозможно.
Например, для использования true
и false
обязательно требуется включение <stdbool.h>
. Для использования compl
и xor
обязательно требуется включение <iso646.h>
. У вас же ideone в режиме С (!) проглотил это все даже не поперхнувшись. Именно по таким причинам в темах по языку С не принято оскорблять присутствующих ссылками на потешные глюкала типа ideone. Возмите в привычку пользоваться общепризнанными стандартами типа coliru. Какой бы вы ресурс не использовали, контроль над командной строкой компилятора — обязателен.
P.S. Ой, только что обратил внимание! Вы вообще в С++ это все компилировали! Так зачем же вы нам тогда баки забиваете какими то сказками про "практику программирования на C"?
Я себе ограничений в «чистый си, где даже даже в ASCII нельзя быть уверенным» не ставил.
Произошло ровно то, что написано в статье — мой код оскорбил практики программирования на си.
На С++ все даже хуже, ибо в С++ символьная константа имеет тип char
, а не int
. И это значит, что в С++ все ваши символьные константы будет подвергаться integral promotions, которые, в зависимости от платформы, могут превратить ее в int
или в unsigned int
. Вариант с unsigned int
— целый ящик Пандоры самостоятельных проблем. (Хотя аналогичные проблемы с integral promotions присутствуют в этом коде и с точки зрения С).
int Ox07 = '.'>>!false;
int Ox17 = 010-001+010+010;
какая то даже не пятничная статья
Кстати, мы ищем Питон-разработчика, который умеет программировать понятнее чем я. Присоединяйтесь!404
видимо, URL'ы получаются не лучше кода на Python
Иногда ответ не «42»