Разные функции с одинаковым названием называют полиморфизмом только формально (чтобы усложнить понимание).
Полиформизмы же подтипа и параметрический по сути сводятся к одному, а неспособность многих языков их рассматривать таким образом — это больше слабость, чем повод для разделения.
Любые нейронкикомпьютеры, это просто инструмент. И меня уже начинают раздражать тезисы, которые утверждают, что благодаря какому-либо инструменту, вы станете востребованным профессионалом.
Изменился ли смысл? Перестало ли раздражать? Если да, то почему? Что будет, если думать на перспективу, а не делать вид, что всё будет так же как сейчас?
В первоисточнике — не слова о clang'е, и вряд ли есть хоть слово о платформах.
Если вы продолжите знакомиться с первоисточником, то вы возможно узнаете, что в нём всё-таки что-то сказано о платформах. В частности, что наличие или отсутствие trap value определяется реализацией(за некоторым исключением гарантий его отсутствия). Дальше, возможно, сможете это сложить с тем, как это относится к clang и наличию или отсутствию у него trap value для bool.
"If an indeterminate value is produced by an evaluation, the behavior is undefined".
В рассматриваемом коде нет получения indeterminate значения через evaluation
Не бывает условных эквивалентов первоисточника, и приведённое вами пережёвывание не исключение, тем более, что код С, а не С++, что бывает важно в ряде случаев.
Тем не менее, для данного случая и первоисточнике(черновике) указано не про unspecified value, как это мне запомнилось, а indeterminated value, то есть, unspecified or trap value. Только обращение к последнему и является неопределённым поведением. Однако clang для большинства платформ не определяет никакого trap value для целых, к каким относится и bool. Более того, само по себе обращение к неинициализированным переменным не детектируется при -fsanitize=undefined, что хотя бы и как-то, но говорит об отношении самих разработчиков компилятора к наличию trap value, а уж проверить его для bool было проще простого. Остаётся только unspecified value, которое не позволяет с ним вести себя как угодно.
С точки зрения определения языка здесь нет неопределённого поведения. В неинициализированной локальной переменной значение не специфицированно, что всего лишь означает, что в ней, пусть и неизвестное, но одно из легальных значений, что для bool это true или false. Если компилятор получил что-то ещё, да ещё и в своих же преобразованиях, то это полностью его проблема. В этом примере для правильного воплощения компилятора было допустимо выводить либо "true", либо "false" в любом варианте, но не вычислять длину строки как попало.
Возможно, Серёжа писал говнокод, а может и нет. Возможно, что остальные программисты писали правильный код, а может оказаться, что они тоже писали говнокод, просто по другому. Сомневаться приходится потому, что люди часто путают говнокод и то, что можно было бы назвать быстрокодом, и упускают из виду, что отборнейший говнокод как раз может быть очень тщательно спроектирован. Хорошим примером, в шутку доведённым до абсурда, является fizbuzz enterprise edition. Такие примеры, пусть и менее абсурдные встречаются в жизни довольно часто, и печально, что у многих складывается впечатление, что так и надо, и поэтому здесь "всё надо переписать", опять, потому что вот теперь всё точно будет масштабируемо без костылей.
Потому что у []что-то и []interface{} разные операции чтения и записи, а запись в приведённый []interface{}, если бы это приведение было возможно, приводила бы к записи элемента interface{} туда, где ожидается элемент что-то. Go это не Dart-2 с псевдо-статической типизацией, что и проявляется в таких нюансах
Например, Relogix™ Assembler-to-C translator
Затем, что статья в данном случае олицетворяет код на ООП, который опять не поняли и неправильно применили. Речь ведь не о коде из статьи.
Замените слово «статья» на «код» и окажется, что вы описали причину, почему ООП как общая парадигма для написания кода несостоятельна.
Разные функции с одинаковым названием называют полиморфизмом только формально (чтобы усложнить понимание).
Полиформизмы же подтипа и параметрический по сути сводятся к одному, а неспособность многих языков их рассматривать таким образом — это больше слабость, чем повод для разделения.
ООП не умерло, оно просто так пахнет. И всегда пахло. Просто, чтобы это начали замечать, понадобилось слишком много времени.
Интересно, сколько времени заняло создание статьи.
Давайте сделаем в тексте небольшую правку:
Изменился ли смысл? Перестало ли раздражать? Если да, то почему? Что будет, если думать на перспективу, а не делать вид, что всё будет так же как сейчас?
Если вы продолжите знакомиться с первоисточником, то вы возможно узнаете, что в нём всё-таки что-то сказано о платформах. В частности, что наличие или отсутствие trap value определяется реализацией(за некоторым исключением гарантий его отсутствия). Дальше, возможно, сможете это сложить с тем, как это относится к clang и наличию или отсутствию у него trap value для bool.
В рассматриваемом коде нет получения indeterminate значения через evaluation
Не бывает условных эквивалентов первоисточника, и приведённое вами пережёвывание не исключение, тем более, что код С, а не С++, что бывает важно в ряде случаев.
Тем не менее, для данного случая и первоисточнике(черновике) указано не про unspecified value, как это мне запомнилось, а indeterminated value, то есть, unspecified or trap value. Только обращение к последнему и является неопределённым поведением. Однако clang для большинства платформ не определяет никакого trap value для целых, к каким относится и bool. Более того, само по себе обращение к неинициализированным переменным не детектируется при -fsanitize=undefined, что хотя бы и как-то, но говорит об отношении самих разработчиков компилятора к наличию trap value, а уж проверить его для bool было проще простого. Остаётся только unspecified value, которое не позволяет с ним вести себя как угодно.
С точки зрения определения языка здесь нет неопределённого поведения. В неинициализированной локальной переменной значение не специфицированно, что всего лишь означает, что в ней, пусть и неизвестное, но одно из легальных значений, что для bool это true или false. Если компилятор получил что-то ещё, да ещё и в своих же преобразованиях, то это полностью его проблема. В этом примере для правильного воплощения компилятора было допустимо выводить либо "true", либо "false" в любом варианте, но не вычислять длину строки как попало.
По-хорошему бы
Возможно, Серёжа писал говнокод, а может и нет. Возможно, что остальные программисты писали правильный код, а может оказаться, что они тоже писали говнокод, просто по другому. Сомневаться приходится потому, что люди часто путают говнокод и то, что можно было бы назвать быстрокодом, и упускают из виду, что отборнейший говнокод как раз может быть очень тщательно спроектирован. Хорошим примером, в шутку доведённым до абсурда, является fizbuzz enterprise edition. Такие примеры, пусть и менее абсурдные встречаются в жизни довольно часто, и печально, что у многих складывается впечатление, что так и надо, и поэтому здесь "всё надо переписать", опять, потому что вот теперь всё точно будет масштабируемо без костылей.
Потому что у []что-то и []interface{} разные операции чтения и записи, а запись в приведённый []interface{}, если бы это приведение было возможно, приводила бы к записи элемента interface{} туда, где ожидается элемент что-то. Go это не Dart-2 с псевдо-статической типизацией, что и проявляется в таких нюансах
Крайне неудачный переводческий ляп - модальность. Ближе было бы режимность, если хотелось передать одним словом.