Так и есть. И такая дырявая хрень лежит в основе C++, который пытается всеми правдами и неправдами (путём нафигачивания абстракций поверх этих дыр) доказать, что он хороший и годный язык.
Я, честно, не понимаю серьёзных инженеров переживающих по поводу несовершенств именно от мощи языка программирования, которому всё можно. Да, надо мощного специалиста, соотвественно. Ну и не делайте UB во всю свою инженерскую мощь! Вам надо подбросить идеек, как? Начнём с инициализации/деинициализации, чтобы не пропустить никогда, вот RAII. Вы до сих пор не прониклись идеей RAII, и относите свои проблемы языку?
А качество абстракций это вовсе другой вопрос. Ко мне вернулась библиотечка Qt, с которой был роман в далёком 2007-м :-p, нравятся абстракции, и программирование на их базе совсем не то, что ATL/MFC или whatever, или что я видел внутрях одной очень серьёзной корпорации. А ведь Qt по сути продукт коллективного моска.
Ты всё перепутал или не дочитал/не осмыслил текст. Тут речь не о мощи, как о проблеме, а о хрупкости, как о проблеме. В современном языке программирования её не должно быть. Вот, ассемблерная программа не сломается вдруг так часто, как сломается сишная/плюсовая от простой перекомпиляции другим компилятором или новой версией того же. В больших проектах это очень важно, т.к. в них выше вероятность, что код окажется в каких-то местах достаточно хрупким для «поломки» компилятором. Хуже того, вещественная арифметика слабо специфицирована, и в определённых задачах ты будешь то и дело упираться в то, что компилятор решил иначе оптимизировать арифметику, что значит, что у тебя результаты будут плавать вместе с плавающей точкой, если ты не примешь экстренных мер для упразднения компиляторных вольностей. Язык таким образом становится всё более нишевым, т.к. вхождение в него становится всё более сложным и долгим, по сравнению с другими языками, плюс в нём продолжают накручивать абстракции, делая сам язык ещё большим, ещё более сложным, и ещё
( ... )
Ну раз ты писал, что *абстракциями* де, закрывают дыры, то единственной абстракцией, которая для закрывания дыр, может быть RAII, и то, это, скорее pattern. Что ты скажешь про RAII? Мне интересно услышать.
Остальные абстракции не для закрывания дыр. Они для программирования сложных вещей проще.
Скота Майерса обожаю. Это он меня посветил в RAII паттерн. И не только.
Остальные абстракции дыры действительно не очень закрывают. Они по большей части просто сосуществуют с дырами, но иногда их и расширяют (C++ имеет свои собственные UB, дополняющие пришлые из C). И хоть они и помогают местами что-то проще написать, они не помогают это потом проще прочитать. Здесь кроется второе большое зло языка.
У тебя всё видение C++ в контексте стабильности и "помехоустойчивости". Конечно, что угодно можно испортить неуёмным рвением. Но таки on average абстракции и читать код помогают, надо употреблять ёмкие имена для них, и хорошо продумывать/разделять интерфейсную часть с имплементацией. Последнее есть бОльшая проблема, так как индивидуальное понимание что есть хорошо ну очень разное. Потому очень к месту иметь стандарт для кодирования как у гуглей, скажем.
В среднем по индустрии, как я понимаю, ООП скорее де факто мертво, чем живо.
Глядя в код некоторого Офиса, у меня такого впечатления не было. Там очень жёсткая дисциплина код-ревью. Проект гниёт оттуда, откуда мы думаем, вот потому у них "лепить с боку" не очень приветствуется. В Индустрии, если говорить о крупных компаниях с многолетними проектами ещё есть проблема платформенности/исторического наследия, когда меняется собственно видение продукта и его платформы, но надо делать так, чтобы новое сосуществовало со старым. *** Ах да, вот там ворнинги забивают! ***
А warnings в этом контексте вообще слегка за уши притянуты. Компилировал Android года три назад и Chromium сейчас. Но всегда интересовал какой-то модуль, а не статистика предупреждений, которые важны в контексте.
Зная, как пользователь, что некоторые баги в этом некотором офисе живут десятилетиями, а некоторые фичи портят документ случайным образом, зная, что там продублировали уже существующие элементы UI, и зная из первых уст, как некоторые баги были «исправлены», у меня не возникает иллюзий на счёт стройности того кода. Ещё я насмотрелся на ужосы в некоторой ОС, где важные куски были написаны абы как, и заведующие ими не могли ответить определённо на бинарный вопрос после недельного изучения собственного кода и собственной же документации, где в иных важных компонентах warning'и были или выключены вовсе или выставлены на средний уровень, т.е. многое находимое просто не находилось, и народ боялся их включать на полную и чистить код. И ведь у них там тоже есть guidelines! В warning'ах скрываются ошибки. Если код не компилируется чисто, то среди безобидных warning'ов пропускаются всамделишные ошибки, т.к. в эту простыню warning'ов просто никто не всматривается.
Ну, в общем, кроме прикладухи, но и движущие части прикладухи, почти всё сделано на C и C++, ужасных-ужасных языках. А тут proposal, как нам сделать из Си НеСи, а интертрепатор. Очень вовремя!
Первый пункт меня огорошил достаточно, я же спросил. Ты отнёс такое к интерпертаторам. Ешё продолжаю читать и вникать. Что не значит, что вовсе не читал. Просто не проникся.
Я там сказал, что мне трудно представить, что такое может сделать компилятор. Но таки может в некоторых ситуациях.
Весь текст по ссылке был явно не про интерпретатор, а про укрощение вредных вольностей компилятора. Как это можно было не понять - не знаю. Если только не читать.
A data race results in unspecified behavior. Informally, we expect that the result of a data race is the same as in C99: threads are compiled independently and then data races have a result that is dictated by the details of the underlying scheduler and memory system. Sequentially consistent behavior may not be assumed when data races occur
Это как дружественным компилятором отлавливать? Тут глубина мысли понятна, а как компилятор статически сделает заключение? Он будет анализировать все вовлечённые модули? Добавить в язык синхронизационный контекст какой-то, так выйдет, чего это они пишут, что просто сделать дружественным. Или специальный рантайм как-то помогает, или новые конструкции языка.
Или я ничего не понял тут, и они просто постулируют UB здесь?
Как я понимаю, они хотят ввести определение. В C99 ничего нет про races. Т.е. без определения даже и не понятно какое тут U: undefined или unspecified. Ну, т.е. пипец полный или в соотвествии с конкретной низлежащей реализацией. Хотят не полный, а в явном виде unspecified.
Reply
Reply
А качество абстракций это вовсе другой вопрос. Ко мне вернулась библиотечка Qt, с которой был роман в далёком 2007-м :-p, нравятся абстракции, и программирование на их базе совсем не то, что ATL/MFC или whatever, или что я видел внутрях одной очень серьёзной корпорации. А ведь Qt по сути продукт коллективного моска.
Reply
Reply
Остальные абстракции не для закрывания дыр. Они для программирования сложных вещей проще.
Скота Майерса обожаю. Это он меня посветил в RAII паттерн. И не только.
Reply
Остальные абстракции дыры действительно не очень закрывают. Они по большей части просто сосуществуют с дырами, но иногда их и расширяют (C++ имеет свои собственные UB, дополняющие пришлые из C). И хоть они и помогают местами что-то проще написать, они не помогают это потом проще прочитать. Здесь кроется второе большое зло языка.
Reply
Reply
Reply
Глядя в код некоторого Офиса, у меня такого впечатления не было. Там очень жёсткая дисциплина код-ревью. Проект гниёт оттуда, откуда мы думаем, вот потому у них "лепить с боку" не очень приветствуется. В Индустрии, если говорить о крупных компаниях с многолетними проектами ещё есть проблема платформенности/исторического наследия, когда меняется собственно видение продукта и его платформы, но надо делать так, чтобы новое сосуществовало со старым. *** Ах да, вот там ворнинги забивают! ***
А warnings в этом контексте вообще слегка за уши притянуты. Компилировал Android года три назад и Chromium сейчас. Но всегда интересовал какой-то модуль, а не статистика предупреждений, которые важны в контексте.
Reply
Reply
Reply
Reply
Ешё продолжаю читать и вникать. Что не значит, что вовсе не читал. Просто не проникся.
Reply
Весь текст по ссылке был явно не про интерпретатор, а про укрощение вредных вольностей компилятора. Как это можно было не понять - не знаю. Если только не читать.
Reply
Это как дружественным компилятором отлавливать? Тут глубина мысли понятна, а как компилятор статически сделает заключение? Он будет анализировать все вовлечённые модули? Добавить в язык синхронизационный контекст какой-то, так выйдет, чего это они пишут, что просто сделать дружественным. Или специальный рантайм как-то помогает, или новые конструкции языка.
Или я ничего не понял тут, и они просто постулируют UB здесь?
Reply
Reply
Leave a comment