веткой, мне кажется.
V> Это вообще тренд в последнее время, хаять все технологии зарекомендовавшие себя на протяжении 30++ лет и доказавшие свою жизнеспособность и гибкость,
TCP, конечно, не самая худшая разработка, но "гибкостью" он не обладает от слова "совсем".
Претензий к нему накопилось столько, что и без QUIC тянет на необходимость TCPv2.
V> менять их на кота в мешке, принимая безумное количество сырых стандартов и пытаясь выгадать себе конкурентное преимущество. V>Да, и конечно, ни в коем случае никакой обратной совместимости!
А какая тут совместимость может в принципе быть?
Трещит сова, не налазит. ((c) один местный завсегдатай)
Здравствуйте, LaptevVV, Вы писали:
LVV>За последний год, изучая защищённость широко используемых библиотек для обработки изображений ImageMagick и GraphicsMagic, я обнаружил более 400 уязвимостей этой категории. LVV>[/q] LVV>Квалифицированный мужик.
Скорее всего запустил C++ анализатор увидел количество ворнингов — вот и вписал цифру, учитывая его признание что програмировал на С++ последний раз в коледже.
Большинство этих проблем в С. На С++ с STL можно писать как на бейсике и не надо создавать 30 новых языков.
Здравствуйте, Pzz, Вы писали:
Pzz>Речь там о том, что большая часть ошибок в программе связана с некорректным доступом к памяти (переполнение буфера, выход за границу массива, использование уже освобожденной памяти и т.п.), а C++ не предоставляет автоматической защиты от такого рода ошибок. И что есть более другие языки программирования, например, любимый мозиловцами Rust, которые такую защиту предоставляют.
И в чем эта защита заключается? Что если программа обратится за пределы массива, то он выдаст пользователю сообщение об ошибке? И какая пользователю радость от этого? Программа-то все равно не будет работать.
Я отвечаю за свои слова, а не за то как вы их интерпретируете!
Здравствуйте, qwertyuiop, Вы писали:
Q>И в чем эта защита заключается? Что если программа обратится за пределы массива, то он выдаст пользователю сообщение об ошибке? И какая пользователю радость от этого? Программа-то все равно не будет работать.
Защита заключается в том, что программа детерминированно сдохнет, вместо того, чтобы недетерменированно делать неизвестно что
Здравствуйте, qwertyuiop, Вы писали:
Q>И в чем эта защита заключается? Что если программа обратится за пределы массива, то он выдаст пользователю сообщение об ошибке? И какая пользователю радость от этого? Программа-то все равно не будет работать.
А на Ц++ программа не вылетит (сразу — но будет вылетать каждый нечетный четверг в новолуние), а выдаст юзеру цифру. Глупый юзер поверит этой цифре, примет на ее основе решение и спустит все свои деньги.
Здравствуйте, Pzz, Вы писали:
Pzz>По-моему, это все мелочи. Реальная проблема заключается в том, что C++ — это ОЧЕНЬ сложный язык программирования. У человека в голове есть вполне конечное число извилин, и если 80% из них заняты борьбой с языком программирования, на все остальное остается только 20%.
Не совсем так. С++ начиная со стандарта 11 года поворачивается к разработчику всё же лицом, а не известно каким местом. Освоив некоторые техники работы с контейнерами, смартпойнтерами и прочими вещами, можно уже не задумываться об этом постоянно. Что не отменяет высокие минимальные требования к мозгам и просто адскую кривую обучения в сравнении с языками попроще (Java, Python).
Здравствуйте, AlexRK, Вы писали:
LVV>>Смысл в том, что надо бы создать более защищенные, чем С++, языки программирования. LVV>>И переписать на них все, что можно переписать. ARK>Ну, он прав абсолютно. Но, увы, этого никто делать не будет.
Ну создали Rust, который как бы может заменить C++. В итоге на Rust выходит ничуть не менее запутанная кодовая база, может даже более запутанная. И в чем тут выгода в переписывании с одного избыточно сложного инструмента на другой?
При этом, многим проектам хорошо бы помог сам факт переписывания. И не так важно, перепишут ли с C++98 на Rust, что потребует довольно серьезный финансовых вливаний, или на C++17, что окажется ощутимо дешевле и предсказуемее. Современный C++ в подавляющем количестве случаев и есть тот новый, безопасный язык с которым надо работать.
Здравствуйте, kaa.python, Вы писали:
KP>Ну создали Rust, который как бы может заменить C++. В итоге на Rust выходит ничуть не менее запутанная кодовая база, может даже более запутанная. И в чем тут выгода в переписывании с одного избыточно сложного инструмента на другой?
Экономической выгоды нет, сплошные убытки.
Для софта выгода может быть — в потенциально большей предсказуемости, хотя в количественном выражении посчитать ее я не берусь.
This top-down structure is ripe for parallelism; however, since styling is a complex process, it’s hard to get right. Mozilla made two previous attempts to parallelize its style system in C++, and both of them failed. But Rust’s fearless concurrency has made parallelism practical.
KP>При этом, многим проектам хорошо бы помог сам факт переписывания. И не так важно, перепишут ли с C++98 на Rust, что потребует довольно серьезный финансовых вливаний, или на C++17, что окажется ощутимо дешевле и предсказуемее.
Безусловно. Поэтому я и говорю, что никто ничего переписывать не будет. Инерция.
KP>Современный C++ в подавляющем количестве случаев и есть тот новый, безопасный язык с которым надо работать.
Надо работать? Вероятно, в большинстве случаев да. Безопасный? Категорически нет.
Здравствуйте, qwertyuiop, Вы писали:
Pzz>>Речь там о том, что большая часть ошибок в программе связана с некорректным доступом к памяти (переполнение буфера, выход за границу массива, использование уже освобожденной памяти и т.п.), а C++ не предоставляет автоматической защиты от такого рода ошибок. И что есть более другие языки программирования, например, любимый мозиловцами Rust, которые такую защиту предоставляют.
Q>И в чем эта защита заключается? Что если программа обратится за пределы массива, то он выдаст пользователю сообщение об ошибке? И какая пользователю радость от этого? Программа-то все равно не будет работать.
Ты троллишь или серьёзно не понимаешь?
Если программа открыто вылетит, это лучше, чем если она незаметно для себя и для пользователя испортит данные или даст неверный ответ.
К тому же, открытый вылет оставляет хотя бы адрес сбоя (а при минимальных усилиях и traceback), по которому легче найти место ошибки, чем по невнятным "глючит, цифры путает".
Здравствуйте, kaa.python, Вы писали:
LVV>>>Смысл в том, что надо бы создать более защищенные, чем С++, языки программирования. LVV>>>И переписать на них все, что можно переписать. ARK>>Ну, он прав абсолютно. Но, увы, этого никто делать не будет. KP>Ну создали Rust, который как бы может заменить C++. В итоге на Rust выходит ничуть не менее запутанная кодовая база, может даже более запутанная.
С чего вывод про запутанность?
KP> И в чем тут выгода в переписывании с одного избыточно сложного инструмента на другой?
Если инструмент ловит большинство ошибок на компиляции и помогает их ловить в рантайме, то он лучше именно этим.
KP>При этом, многим проектам хорошо бы помог сам факт переписывания. И не так важно, перепишут ли с C++98 на Rust, что потребует довольно серьезный финансовых вливаний, или на C++17, что окажется ощутимо дешевле и предсказуемее. Современный C++ в подавляющем количестве случаев и есть тот новый, безопасный язык с которым надо работать.
Только при условии жесточайшего контроля за _всей_ кодовой базой.
Достаточно одного места, где слишком вольно обращаются с указателями, чтобы всё посыпалось.
И анализ, чтобы отловить такие места, сильно сложнее, чем для Rust.
Здравствуйте, AlexRK, Вы писали:
ARK>Экономической выгоды нет, сплошные убытки. ARK>Для софта выгода может быть — в потенциально большей предсказуемости, хотя в количественном выражении посчитать ее я не берусь.
Современный C++ дает достаточно предсказуемости при использовании в связке с современными инструментами. В качестве примера можно взять GSL, clang-tidy, санитайзеры и конечно же тесты. Основное отличие C++ от Rust в данном случае будет в том, что инструменты в C++ отдельны от компилятора и это ведет к высоким рискам их игнорирования. К примеру у нас сейчас многокомпонентный проект на C++14 и Go. Так как C++ часть довольно плотно покрыта инструментами по контролю, нет ни дедлоков, ни ликов, ни двойного освобождения памятью ни каких других около-C++ страшилок. То есть качество вполне сопоставимо с качеством достижимым в Go.
ARK>Вот что излагает заинтересованная сторона (можно верить, можно нет): https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-In-Firefox-Quantum.html ARK>
This top-down structure is ripe for parallelism; however, since styling is a complex process, it’s hard to get right. Mozilla made two previous attempts to parallelize its style system in C++, and both of them failed. But Rust’s fearless concurrency has made parallelism practical.
Полагаю что в случае с предыдущими попытками они не делали кардинальной замены системы, а просто пытались подставить правильные костыли. Полная переработка той же командой что смогла осилить Rust (осилить который ничуть не проще чем C++) привела бы к такому же результату.
ARK>Надо работать? Вероятно, в большинстве случаев да. Безопасный? Категорически нет.
Безопасен при использовании современного инструментария. Разница лишь в том, встроен инструментарий или идет сбоку.
Здравствуйте, netch80, Вы писали:
N>С чего вывод про запутанность?
Много раз пытался на нем писать. Если заглянуть в образцово показательную библиотеку типа tokio, то просто волосы везде шевелятся от перспективы поддерживать такой код.
N>Если инструмент ловит большинство ошибок на компиляции и помогает их ловить в рантайме, то он лучше именно этим.
В современном C++ достаточно развитый инструментарий для обеспечения достаточной защиты от типичных страшилок. При этом от перечисленных тобой же проблем
ни C++ ни Rust не защищают
N>Только при условии жесточайшего контроля за _всей_ кодовой базой. N>Достаточно одного места, где слишком вольно обращаются с указателями, чтобы всё посыпалось. N>И анализ, чтобы отловить такие места, сильно сложнее, чем для Rust.
Это очень легко решается при помощи санитайзеров и тестов.
Здравствуйте, kaa.python, Вы писали:
KP>Современный C++ дает достаточно предсказуемости при использовании в связке с современными инструментами. В качестве примера можно взять GSL, clang-tidy, санитайзеры и конечно же тесты. Основное отличие C++ от Rust в данном случае будет в том, что инструменты в C++ отдельны от компилятора и это ведет к высоким рискам их игнорирования. К примеру у нас сейчас многокомпонентный проект на C++14 и Go. Так как C++ часть довольно плотно покрыта инструментами по контролю, нет ни дедлоков, ни ликов, ни двойного освобождения памятью ни каких других около-C++ страшилок. То есть качество вполне сопоставимо с качеством достижимым в Go.
Согласен. Разница как раз в "насильственном насаждении" безопасности растом — в долгосрочной перспективе это хорошо. Можно провести аналогию (лживую, как и другие аналогии) со статической и динамической проверкой типов — хорошее тестовое покрытие динамически типизированного кода вполне ставит его на уровень статического по безопасности. Но когда конпелятор следит — оно всё же надёжнее как-то.
Ну и вообще С++ уже чрезмерно, безобразно огромен и сложен. И новый мусор всё прибывает и прибывает. "requires requires", "noexcept(noexcept)", "export import", метаклассы, и так далее. Рано или поздно вся эта гора коллапсирует под собственным весом в чорную дыру (глубокое легаси).
Здравствуйте, kaa.python, Вы писали:
KP>Много раз пытался на нем писать. Если заглянуть в образцово показательную библиотеку типа tokio, то просто волосы везде шевелятся от перспективы поддерживать такой код.
Я не писал на расте, но вроде бы в этом коде чего-то сильно непонятного нет. Вполне разборчиво и однородно. Думаю, что можно на расте наговнокодить куда сильнее.
Про QUIC, это я просто так, к иллюстрации современных трендов, а вообще то конечно о С++ и Rust.
Ну просто уже все было: IP/Sec, IP6, SPDY и т.д. лет уже 20 говорят что все не работает, нужно менять, а воз и ныне там. Просто это все о дальновидности всех этих решений. Сначала всех силком садят на HTTPS, кого надо и кого не надо, а потом говорят что мол, у нас Hand-Shake лишний и тормозит и вот новый стандарт все решит... Ладно, поживем увидим
По поводу Rust. Основная идея мне нравится:
— константные ссылки
— семантика перемещения по умолчанию
— автоматический подсчет ссылок
— все статически проверяется компилятором
Но остается главный вопрос, что делать с тоннами кода который есть на С++ и еще будут написаны, если нет никакого интеропа между?
С++ потихоньку заменяет и дополняет С, т.к. между ними есть почти полная совместимость и последние стандарты стремятся, как могут, друг к другу. А что для этого делается в Rust ?
КД>... было само собой разумеющимся, что иногда в программе будут происходить аварийные остановки.
КД>Это вот наверное хуже всего, когда в неокрепшие мозги закладывают такие допущения. КД>Их потом нереально выковырять обратно. КД>И это касается не только программирования.
+100500
Что значит эти самые "аварийные остановки" Гремлины? Барабашка?
ИМХО это значит только одно: разработчик (или вся команда) не выполнил до конца свою задачу
Есть проблемы — аварийные остановки — смотри лог-файлы и разбирайся в причинах...
Если нужно, то подключай других участников проекта (тех же QA) к локализации проблемы!
Здравствуйте, AlexGin, Вы писали:
AG>ИМХО это значит только одно: разработчик (или вся команда) не выполнил до конца свою задачу
Это значит:
а) Заказчика с его хотелками большими, чем возможно, не послали нахер.
б) Менеджера с его хотелками большими, чем возможно, не послали нахер.
в) Заказчика с его сроками меньшими, чем возможно, не послали нахер.
г) Менеджера с его сроками меньшими, чем возможно, не послали нахер.
д) Вместо использования полноценной СУБД с транзакциями, написанной PhD по computer science, взяли key-value хранилище и стали реализовывать на нём транзакции и прочее силами фронтенд-разработчиков, перешедших в бэкенд на NodeJS. Получилось херово.
е) Вместо использования языков, подходящих для разработки, писали на том, что знают разработчики, получилось херово.
ё) Вместо проверки и доказательства корректности написанного автоматическими средствами, используется вера в разработчика "мамой клянусь, работает".
ж) Вместо того, чтобы использовать средства верификации кода, используется метод пристального прищуренного взгляда и "мамой клянусь, работает".
з) Писали быстрее, чем могут.
Заказчик должен платить деньги и идти нахер. Менеджер должен платить деньги и идти нахер. Выгодополучатели с херовых проектов должны вместо выгоды получать хер на всё рыло, т.е. обычную зарплату, которую они платят разработчикам. Сложные части проектов должны писаться либо людьми с полноценными знаниями — теми, кто SICP прорешал, либо браться в готовом виде, желательно за деньги. Если готовое не удовлетворяет заказчика — заказчик идёт нахер. Почему-то в случае разного рода электротехники заказчиков удовлетворяет готовое и стандартное, а пожелания вида "сделайте мне трансформатор из дерева" посылаются нахер.
Здравствуйте, Pzz, Вы писали:
Pzz>Защита заключается в том, что программа детерминированно сдохнет, вместо того, чтобы недетерменированно делать неизвестно что
Цена вопроса?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Разница как раз в "насильственном насаждении" безопасности растом — в долгосрочной перспективе это хорошо. Можно провести аналогию (лживую, как и другие аналогии) со статической и динамической проверкой типов — хорошее тестовое покрытие динамически типизированного кода вполне ставит его на уровень статического по безопасности. Но когда конпелятор следит — оно всё же надёжнее как-то.
Гремлины? Барабашка? 
