Как я понял, у Rust'а нет никаких явных преимуществ перед C++ 17?
Если я неправ, то какие это преимущества? Контроль выхода за границы массива, счетчик ссылок (или как он там называется) — все это на этапе компиляции. У C++ 17 такого вообще нет?
Здравствуйте, _VW_, Вы писали:
_VW>Как я понял, у Rust'а нет никаких явных преимуществ перед C++ 17? _VW>Если я неправ, то какие это преимущества? Контроль выхода за границы массива, счетчик ссылок (или как он там называется) — все это на этапе компиляции. У C++ 17 такого вообще нет?
Здравствуйте, _VW_, Вы писали:
_VW>Как я понял, у Rust'а нет никаких явных преимуществ перед C++ 17? _VW>Если я неправ, то какие это преимущества? Контроль выхода за границы массива, счетчик ссылок (или как он там называется) — все это на этапе компиляции. У C++ 17 такого вообще нет?
У Rust'а:
Продвинутая система модулей;
Гарантии безопасной работы с памятью, большей частью на этапе компиляции;
Гарантии корректной работы с памятью в многопоточных приложениях, тоже большей частью на этапе компиляции;
Паттерн-матчинг;
Алгебраические типы данных;
И при все этом приятный синтаксис (за исключением, пожалуй, генериков).
C++ имеет похожие возможности в некоторых областях, но при этом не дает никаких гарантий.
Здравствуйте, Васильич, Вы писали:
В>Здравствуйте, _VW_, Вы писали:
_VW>>Как я понял, у Rust'а нет никаких явных преимуществ перед C++ 17? _VW>>Если я неправ, то какие это преимущества? Контроль выхода за границы массива, счетчик ссылок (или как он там называется) — все это на этапе компиляции. У C++ 17 такого вообще нет?
В>У Rust'а: В>Продвинутая система модулей; В>Гарантии безопасной работы с памятью, большей частью на этапе компиляции; В>Гарантии корректной работы с памятью в многопоточных приложениях, тоже большей частью на этапе компиляции; В>Паттерн-матчинг; В>Алгебраические типы данных; В>И при все этом приятный синтаксис (за исключением, пожалуй, генериков).
У C++ — удобные проверенные средства разработки и развитое сообщество.
Здравствуйте, T4r4sB, Вы писали:
TB>Здравствуйте, Васильич, Вы писали:
В>>У Rust'а: В>>Продвинутая система модулей; В>>Гарантии безопасной работы с памятью, большей частью на этапе компиляции; В>>Гарантии корректной работы с памятью в многопоточных приложениях, тоже большей частью на этапе компиляции; В>>Паттерн-матчинг; В>>Алгебраические типы данных; В>>И при все этом приятный синтаксис (за исключением, пожалуй, генериков).
TB>У C++ — удобные проверенные средства разработки и развитое сообщество.
Да, это правда. Хотя это больше не достоинство C++ как такового, а скорее его возраста.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, _VW_, Вы писали:
_VW>>Как я понял, у Rust'а нет никаких явных преимуществ перед C++ 17?
ARK>Каким образом вы это поняли?
Здравствуйте, _VW_, Вы писали:
_VW>Как я понял, у Rust'а нет никаких явных преимуществ перед C++ 17?
Есть и плюсы и минусы. В целом, для небольшой и сильной команды он предпочтительнее. Для большой и/или слабой команды лучше взять C++, а еще лучше Java или C#
_VW>Если я неправ, то какие это преимущества? Контроль выхода за границы массива, счетчик ссылок (или как он там называется) — все это на этапе компиляции. У C++ 17 такого вообще нет?
Основные плюшки:
простой, на много проще C++;
довольно хорошо продуманная модульность с управлением зависимостями из коробки (cargo);
очень хорошая поддержка разработки многопоточных приложений;
быстрый код в общем случае не уступающий C/C++;
гарантии корректной работы с памятью.
Почему бы я его не взял для большой/слабой команды:
Он сложнее Java/Python и его реально нужно учить. Концепция отличается от привычных C/C++/Java/Python;
Благодаря unsafe в нем крайне легко говнокодить в C/C++ стиле;
Нет нормально работающей IDE;
Язык заставляет довольно серьезно подходить к архитектуре. Исправление постфактум обойдутся основательно дороже чем в C/C++ и скорей всего (это теория) приведут к появлению кучи говнокода по средствам unsafe.
Здравствуйте, kaa.python, Вы писали:
KP>Основные плюшки: KP>
KP> простой, на много проще C++; KP> довольно хорошо продуманная модульность с управлением зависимостями из коробки (cargo); KP> очень хорошая поддержка разработки многопоточных приложений; KP> быстрый код в общем случае не уступающий C/C++; KP> гарантии корректной работы с памятью. KP>
KP>Почему бы я его не взял для большой/слабой команды:
KP>
KP> Он сложнее Java/Python и его реально нужно учить. Концепция отличается от привычных C/C++/Java/Python; KP> Благодаря unsafe в нем крайне легко говнокодить в C/C++ стиле; KP>
Это, кстати, одна из проблематичных областей для новичков. Исходники стандартной библиотеки просто кишат unsafe'ами, что может заставить новичков думать, что по другому просто нельзя, хотя понятно, что там они используются исключительно в целях оптимизации. Это усложняется тем, что стандартная библиотека и исходники компилятора являются пока что одним из основных мест, куда люди смотрят в процессе обучения.
С другой стороны, Rust пока притягивает в основном сильных программистов в силу своей сложности, которые пишут адекватный код, используя хорошие практики. К моменту "опопсения" языка будет хорошая база и для остальных.
KP>
KP> Нет нормально работающей IDE; KP> Язык заставляет довольно серьезно подходить к архитектуре. Исправление постфактум обойдутся основательно дороже чем в C/C++ и скорей всего (это теория) приведут к появлению кучи говнокода по средствам unsafe. KP>
Я бы, кстати, сказал, что с точки зрения архитектуры Rust ближе к C#/Java, чем к C++.
Это очень показательный пример, когда человек, привыкший к необдуманному кодингу, сталкивается с растом. Тут важно запомнить одно: сильнейшая сторона Rust'а в его строгости, он всегда начинает бить по рукам, когда программист теряет нить и начинает писать код от балды.
В примере выше код неконсистентен в типах, поэтому автору приходится прибегать к частому преобразованию типов. Вместо того, чтобы задуматься, почему у него r, g, b имеют тип u8 в структуре, но int в заголовке функции, он обвиняет Rust в излишнем кастинге. Это, кстати, сишная привычка по дефолту ставить int везде.
One of the reasons was that Rust couldn't deal with out-of-memory exceptions.
ARK>>ОК, это понять можно.
_VW>Во, это я хотел узнать. Что, как, почему и чем это грозит?
Чувак хочет обрабатывать нехватку памяти, а Rust ему не дает — все аллокации производятся неявно и в случае нехватки памяти делается аборт всего процесса. Хотя, как я понимаю, это больше ограничение существующих библиотек. Можно ведь и самому написать выделитель с проверкой результата. Но потом под него придется все остальное переписывать.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, _VW_, Вы писали:
ARK>>>
One of the reasons was that Rust couldn't deal with out-of-memory exceptions.
ARK>>>ОК, это понять можно.
_VW>>Во, это я хотел узнать. Что, как, почему и чем это грозит?
ARK>Чувак хочет обрабатывать нехватку памяти, а Rust ему не дает — все аллокации производятся неявно и в случае нехватки памяти делается аборт всего процесса. Хотя, как я понимаю, это больше ограничение существующих библиотек. Можно ведь и самому написать выделитель с проверкой результата. Но потом под него придется все остальное переписывать.
Здравствуйте, _VW_, Вы писали:
ARK>>Чувак хочет обрабатывать нехватку памяти, а Rust ему не дает — все аллокации производятся неявно и в случае нехватки памяти делается аборт всего процесса. Хотя, как я понимаю, это больше ограничение существующих библиотек. Можно ведь и самому написать выделитель с проверкой результата. Но потом под него придется все остальное переписывать.
_VW>то есть, это ограничение руста?
Это ограничение существующей экосистемы руста, но не самого руста, как языка программирования.
Здравствуйте, Zenden, Вы писали:
В>>И при все этом приятный синтаксис (за исключением, пожалуй, генериков).
Z>Лолшто? этот вырвиглазный синтаксис вы называете приятным? Наверно вам и objective-c приятен
Синтаксис вполне нормален, очень близок к C/C++. У вас, возможно, просто другие персональные предпочтения.
Здравствуйте, AlexRK, Вы писали:
_VW>>то есть, это ограничение руста?
ARK>Это ограничение существующей экосистемы руста, но не самого руста, как языка программирования.
насколько это серьезное ограничение эко-системы? также, вроде бы как собирались сделать, чтобы возращался Result<> из функции выделения памяти, вместо аварийного завершения, если памяти нет.
В>У Rust'а: В>Продвинутая система модулей;
В С++ тоже скоро будет.
В>Гарантии безопасной работы с памятью, большей частью на этапе компиляции;
Это не совсем так. Помимо семантики владения, которую можно проверить (иногда) на этапе компиляции, есть еще и остальные операции с памятью, которые проверяются в рантайме (bounds checking) и которые имеют свою стоимость. Первое (ownership) в С++ вполне себе можно проверять во время компиляции, shared_ptr/unique_ptr в помощь. Операции с памятью тоже никто не заставляет выполнять без проверки выхода за границы (vector.at вместо []).
В>Гарантии корректной работы с памятью в многопоточных приложениях, тоже большей частью на этапе компиляции;
Баги в многопоточных программах data-race-ами не ограничиваются. Есть еще просто race-ы, от которых он не защищает. Головой, в конечном итоге, придется думать самостоятельно.
В>C++ имеет похожие возможности в некоторых областях, но при этом не дает никаких гарантий.
Что значит "не дает гарантий"? Какие гарантии дает язык? У С++ есть стандарт, поэтому я могу точно сказать как должен вести себя тот или иной фрагмент кода. Стандарт определяет некоторые вещи как UB (undefined behaviour), такие как разыменование нулевого указателя. Но это, КМК, вполне логично. Можно конечно попытаться скрыть от программиста неопределенное поведение максимально, но это, во первых, ограничит возможности оптимизатора, во вторых — язык станет слишком высокоуровневым, как Java или C#. В Java ведь тоже memory safety есть, только за счет GC.
Здравствуйте, _VW_, Вы писали:
_VW>Здравствуйте, AlexRK, Вы писали:
_VW>>>то есть, это ограничение руста?
ARK>>Это ограничение существующей экосистемы руста, но не самого руста, как языка программирования.
_VW>насколько это серьезное ограничение эко-системы? также, вроде бы как собирались сделать, чтобы возращался Result<> из функции выделения памяти, вместо аварийного завершения, если памяти нет.
Судя по ответу Стива Клабника здесь, в ближайшее время ничего менять не собираются:
"Yes, in general, the standard library assumes that you can't really handle OOM. Using libcore and custom allocators, you could implement whatever behavior you'd like, but you'd still need to re-implement this kind of thing on top of it."
С другой стороны, сейчас ведется работа над "placement box" (ознакомиться можно здесь), что приведет к появлению поддержки сторонних аллокаторов. Но, опять же, никаких потенциальных возвратов ошибок вроде как не предвидится, плюс нельзя будет использовать свой аллокатор для существующих коллекций, как я понял.
Так что, в ближайшие год-два точно, единственный способ обрабатывать ситуации нехватки памяти можно будет только реализуя собственные менеджеры памяти и переписывая требуемые структуры данных для них.
From my experience, I found it awfully difficult to understand how to work with borrowing and lifetimes.
ARK>А это — нет. Возможность попроще говнокодить (и потенциально допускать ошибки) ставится выше создания гарантированно корректного кода. ARK>Это не говорит о том, что у Rust нет преимуществ.
По опыту — С++ код, активно использующий семантику перемещения и уникальные указатели бывает иногда довольно сложно понять. Обычно в приложении есть два с половиной объекта, время жизни которых имеет значение, остальное же может быть отдано на откуп GC или еще какому-нибудь механизму. Rust же, наоборот, делает шаг назад от языков с автоматическим управлением временем жизни объектов, но при этом не дает никаких особенных преимуществ по сравнению с С++, с которым он на одном уровне по когнитивной нагрузке, но только без тулинга/библиотек/книг/статей/конференций/программистов.
В>"Yes, in general, the standard library assumes that you can't really handle OOM. Using libcore and custom allocators, you could implement whatever behavior you'd like, but you'd still need to re-implement this kind of thing on top of it."
Да уж, булшит про невозможность обработки OOM на уровне рантайма это сильно. Далеко не всегда ООМ нельзя обработать. Часто это возможно и даже требуется делать.
Здравствуйте, Васильич, Вы писали:
В>Так что, в ближайшие год-два точно, единственный способ обрабатывать ситуации нехватки памяти можно будет только реализуя собственные менеджеры памяти и переписывая требуемые структуры данных для них.
насколько это серьезное ограничение эко-системы? чем плохо отсуствие возможности отловить ошибку OOM?
Здравствуйте, Васильич, Вы писали:
В>Исходники стандартной библиотеки просто кишат unsafe'ами
То есть это утверждение предыдущего оратора
KP>>* быстрый код в общем случае не уступающий C/C++;
не соответствует действительности, сравнимой производительности без unsafe не получится?
Здравствуйте, _VW_, Вы писали:
_VW>насколько это серьезное ограничение эко-системы? также, вроде бы как собирались сделать, чтобы возращался Result<> из функции выделения памяти, вместо аварийного завершения, если памяти нет.
Ну, я не супер-знаток растовой экосистемы, но полагаю, что преодоление данного ограничения будет означать переписывание неприемлемо большого количества кода.
From my experience, I found it awfully difficult to understand how to work with borrowing and lifetimes.
ARK>>А это — нет. Возможность попроще говнокодить (и потенциально допускать ошибки) ставится выше создания гарантированно корректного кода. ARK>>Это не говорит о том, что у Rust нет преимуществ.
EL>По опыту — С++ код, активно использующий семантику перемещения и уникальные указатели бывает иногда довольно сложно понять.
Возможно, причина заключается не в том, что "код активно использует семантику перемещения и уникальные указатели", а в том, что это "С++ код, активно использующий семантику перемещения и уникальные указатели". С++ не проектировался с учетом семантики перемещения и не _требует_ ее. Но это только моя гипотеза.
EL>Обычно в приложении есть два с половиной объекта, время жизни которых имеет значение, остальное же может быть отдано на откуп GC или еще какому-нибудь механизму. Rust же, наоборот, делает шаг назад от языков с автоматическим управлением временем жизни объектов, но при этом не дает никаких особенных преимуществ по сравнению с С++, с которым он на одном уровне по когнитивной нагрузке, но только без тулинга/библиотек/книг/статей/конференций/программистов.
Про тулинг/библиотеки/книги/статьи/конференции — это без вопросов, тут С++ на световые годы впереди. Насчет всего остального не уверен.
Здравствуйте, ELazin, Вы писали:
KP>>быстрый код в общем случае не уступающий C/C++; KP>>гарантии корректной работы с памятью.
EL>одно исключает другое
В случае раста есть некоторые накладные расходы на проверки, но в общем случае это утверждение неверно. Статически можно проверять все, даже выход за границы массивов, но сейчас это мейнстримом не является.
Здравствуйте, ELazin, Вы писали:
EL>одно исключает другое
Не противоречит при условии обеспечения гарантий на этапе компиляции. Надо признать, гарантии безопасной работы с памятью не везде и не всегда, можно и в рантайме в панику вылететь при попытке захватить ссылку на объект, но в общем случае ситуация с безопасной работой с памятью ощутимо лучше чем в C++.
Здравствуйте, _VW_, Вы писали:
_VW>Как я понял, у Rust'а нет никаких явных преимуществ перед C++ 17?
Ансельм Кентерберийский еще в 1078 году сформулировал онтологический аргумент явного преимущества Раста перед С++17: Раст уже существует, уже реален, а С++17 еще нет.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, _VW_, Вы писали:
_VW>>насколько это серьезное ограничение эко-системы? также, вроде бы как собирались сделать, чтобы возращался Result<> из функции выделения памяти, вместо аварийного завершения, если памяти нет.
ARK>Ну, я не супер-знаток растовой экосистемы, но полагаю, что преодоление данного ограничения будет означать переписывание неприемлемо большого количества кода.о
я не про это. а про то, как часто его может нужно будет преодолевать.
Здравствуйте, _VW_, Вы писали:
ARK>>Ну, я не супер-знаток растовой экосистемы, но полагаю, что преодоление данного ограничения будет означать переписывание неприемлемо большого количества кода.о
_VW>я не про это. а про то, как часто его может нужно будет преодолевать.
А... получается, этот вопрос к расту вообще не относится. Как часто вообще надо обрабатывать OOM? Фиг знает. В системах с ограниченными ресурсами это, скорее всего, общее место. Но я в этом не копенгаген.
Здравствуйте, Васильич, Вы писали:
> Гарантии безопасной работы с памятью, большей частью на этапе компиляции;
В>C++ имеет похожие возможности в некоторых областях, но при этом не дает никаких гарантий.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, _VW_, Вы писали:
_VW>>Как я понял, у Rust'а нет никаких явных преимуществ перед C++ 17?
KP>Есть и плюсы и минусы. В целом, для небольшой и сильной команды он предпочтительнее. Для большой и/или слабой команды лучше взять C++, а еще лучше Java или C#
Здравствуйте, _VW_, Вы писали:
_VW>насколько это серьезное ограничение эко-системы? также, вроде бы как собирались сделать, чтобы возращался Result<> из функции выделения памяти, вместо аварийного завершения, если памяти нет.
Здравствуйте, kaa.python, Вы писали:
KP>Основные плюшки: KP>
...
быстрый код в общем случае не уступающий C/C++;
На данный момент это миф. Хотя возможно когда-нибудь в будущем это станет реальностью, т.к. никаких фундаментальных препятствий Rust не имеет (в отличие от того же Java/C#). Однако для этого требуется ещё не один год активной работы над компилятором.
KP>Почему бы я его не взял для большой/слабой команды: KP>
...
Нет нормально работающей IDE;
Да, это существенная проблема. Но на мой взгляд есть ещё и гораздо более серьёзная: непонятно какие собственно бонусы принесёт язык (ну кроме небольшого синтаксического сахара), в случае перехода на него с C++ (а в особенности если взглянуть на будущий стандарт).
ARK>В случае раста есть некоторые накладные расходы на проверки, но в общем случае это утверждение неверно. Статически можно проверять все, даже выход за границы массивов, но сейчас это мейнстримом не является.
KP>Не противоречит при условии обеспечения гарантий на этапе компиляции. Надо признать, гарантии безопасной работы с памятью не везде и не всегда, можно и в рантайме в панику вылететь при попытке захватить ссылку на объект, но в общем случае ситуация с безопасной работой с памятью ощутимо лучше чем в C++.
Ощутимо лучше чем? В современном С++ не принято использовать голые указатели и Си-стиль. Помимо этого для С++ есть соответствующий тулинг (ASan). Ну и свойство memory safety, оно не composable, если у тебя есть unsafe код, который портит память, то уронить приложение можно и в safe блоке. Memory safe приложение должно состоять только из safe кода, что в случае раста явно не выполняется, так что все эти гарантии — ничего не стоят.
Здравствуйте, ELazin, Вы писали:
EL>Ощутимо лучше чем? В современном С++ не принято использовать голые указатели и Си-стиль. Помимо этого для С++ есть соответствующий тулинг (ASan). Ну и свойство memory safety, оно не composable, если у тебя есть unsafe код, который портит память, то уронить приложение можно и в safe блоке. Memory safe приложение должно состоять только из safe кода, что в случае раста явно не выполняется, так что все эти гарантии — ничего не стоят.
"Не принято" и "запрещено везде, кроме unsafe блоков" — таки разные вещи.
Наличие явно выделенных небольших unsafe блоков лучше, чем один громадный unsafe блок в С++. Ну и есть подозрение, что типичное приложение не будет нуждаться в unsafe.
EL>Ощутимо лучше чем? В современном С++ не принято использовать голые указатели и Си-стиль. Помимо этого для С++ есть соответствующий тулинг (ASan). Ну и свойство memory safety, оно не composable, если у тебя есть unsafe код, который портит память, то уронить приложение можно и в safe блоке. Memory safe приложение должно состоять только из safe кода, что в случае раста явно не выполняется, так что все эти гарантии — ничего не стоят.
Очень даже стоят. Помню как не вылезал из дебаггера, когда пробовал работать с DirectX 9 в С++. Несмотря на все умные указатели, темплейты и прочие оверлоадинги.
Сегодня полдня перетряхивал структуру рендеринга в программе на Rust для DirectX 12. Вечером исправил все ошибки компиляции. Запустил — работает. Поправил минорный баг (забыл установить дескриптор шейдерного ресурса) — работает правильно.
Не смотря на unsafe, в Rust легко построить стабильное основание для последущей разработки. В отличии от.
R>Очень даже стоят. Помню как не вылезал из дебаггера, когда пробовал работать с DirectX 9 в С++. Несмотря на все умные указатели, темплейты и прочие оверлоадинги.
Вижу жалобы на жизнь. Язык программирования С++ тут не причем, КМК,
R>Сегодня полдня перетряхивал структуру рендеринга в программе на Rust для DirectX 12. Вечером исправил все ошибки компиляции. Запустил — работает. Поправил минорный баг (забыл установить дескриптор шейдерного ресурса) — работает правильно.
Вижу wishful thinking.
R>Не смотря на unsafe, в Rust легко построить стабильное основание для последущей разработки. В отличии от.
Еще один, считающий, что все это от языка программирования сильно зависит.
Здравствуйте, ELazin, Вы писали:
EL>Вижу жалобы на жизнь. Язык программирования С++ тут не причем, КМК,
EL>Вижу wishful thinking.
Вижу стандартого диагноста по фотографии.
R>>Не смотря на unsafe, в Rust легко построить стабильное основание для последущей разработки. В отличии от. EL>Еще один, считающий, что все это от языка программирования сильно зависит.
Да пожалуйста. Пишите на ассемблере, вайтспейсе или брэйнфаке. Удачи.
R>Вижу стандартого диагноста по фотографии.
"Помню как не вылезал из дебаггера" — вот на это предлагается ответить что-нибудь нормальное? Я вполне себе конструктивно пытался дискутировать на тему memory safety и тулинга, но в ответ получил "я не вылезал из дебаггера, значит все что ты пишешь — фигня", но только немного другими словами. Ес-но я подумал что человек, который "не вылезал из дебагера" не может в программирование и что ему не дай, Rust, TCL, Python — получатся жалобы на то, как плох язык программирования Х.
Здравствуйте, ELazin, Вы писали:
EL>"Помню как не вылезал из дебаггера" — вот на это предлагается ответить что-нибудь нормальное? Я вполне себе конструктивно пытался дискутировать на тему memory safety и тулинга, но в ответ получил "я не вылезал из дебаггера, значит все что ты пишешь — фигня", но только немного другими словами. Ес-но я подумал что человек, который "не вылезал из дебагера" не может в программирование и что ему не дай, Rust, TCL, Python — получатся жалобы на то, как плох язык программирования Х.
-Ножами жонглировать трудно и опасно!
-Не опасно и легко, надо просто правильно это делать.
-Трудно и опасно, я пробовал и весь поранился.
-Ты просто не можешь в жонглирование и жалуешься на жизнь.
Здравствуйте, ELazin, Вы писали:
R>>Вижу стандартого диагноста по фотографии. EL>"Помню как не вылезал из дебаггера" — вот на это предлагается ответить что-нибудь нормальное? Я вполне себе конструктивно пытался дискутировать на тему memory safety и тулинга, но в ответ получил "я не вылезал из дебаггера, значит все что ты пишешь — фигня", но только немного другими словами. Ес-но я подумал что человек, который "не вылезал из дебагера" не может в программирование и что ему не дай, Rust, TCL, Python — получатся жалобы на то, как плох язык программирования Х.
Ладно.
1) Статические анализаторы в комплекте с С++ не идут. В стандарте не написано: "Вы должны использовать статический анализатор, чтобы не использовать одну из многих любезно предоставленных нами возможностей выстрелить себе в ногу".
2) Крупные компании прекрасно понимают, что идеальных программистов, помнящих и мгновенно замечающих все неопределенные и неспецифицированные поведения, и с первого взгляда выполняющих двухфазное разрешение имён, с учетом всего исходника проекта, не существует. Поэтому пытаются ужать всю мощь и свободу С++ до приемлемых рамок: https://google.github.io/styleguide/cppguide.html
3) Но это не особо помогает: https://bugs.chromium.org/p/nativeclient/issues/detail?id=245 см. Type 3 Functions, всё равно напоролись на неспецифицированное поведение.
4) Не помню чьё высказвание "Наговнокодить можно на любом языке", которое Вы, вероятно, поддерживаете, совершенно бесполезно для сравнения языков. Вопрос в том насколько легко язык позволяет сделать ошибку обычному программисту. Напомню, что даже Бьярн Страуструп в своей книге по С++ напоролся на неспецифицированное поведение. http://stackoverflow.com/questions/27158812/does-this-code-from-the-c-programming-language-4th-edition-section-36-3-6-ha
5) 5 простых спобов выстрелить себе в ногу с использованием shared_ptr: http://habrahabr.ru/post/191018/
6) Даже комитет по C++ понимает наличие проблем. Планируют введение статического анализа времени жизни переменных, в частности для предотвращения работы с инвалидированными итераторами.
Итого: С++ медленно ползёт в сторону Rust, таща за собой сорокалетние напластования фич, кучу неопределенных и неспецифицированных поведений в невинно выглядящих конструкциях, тонны legacy-кода.
А то что я писал про свою программку на Rust это не wishful thinking, а простое следствие того, что статический анализатор встроен в Rust.
Если выразить инварианты программы на уровне типов, то успешность компиляции будет гарантировать успешность работы. Я, конечно, до такого уровня не дошёл (собственно в Rust'е это полностью и не получится. Например, там нельзя реализовать session types), но по крайней мере могу быть достаточно уверен, что ошибка не вызвана buffer overrun в какой-нибудь отдалённой части программы или кривой библиотеке.
EDIT: Вот ещё интересная вещь: https://www.youtube.com/watch?v=AKtHxKJRwp4 79 минут обзора ошибок, встречающихся в реальных проектах на C++. Реакция "какой идиот это писал?" абсолютно неконструктивна. Реакция "какого хрена язык позволяет это писать?" может привести к улучшению языка.
Здравствуйте, AlexRK, Вы писали:
KP>>>быстрый код в общем случае не уступающий C/C++; KP>>>гарантии корректной работы с памятью. EL>>одно исключает другое ARK>В случае раста есть некоторые накладные расходы на проверки, но в общем случае это утверждение неверно.
Подозреваю что как раз в общем случае оно и верно.
ARK>Статически можно проверять все, даже выход за границы массивов
Каким образом? Если у нас язык полный по Тьюрингу, то в статике такая задача неразрешима.
P.S. Вообще, полнота по Тьюрингу нужна далеко не везде — в большинстве случаев это неоправданная роскошь, эдакий unsafe.
Тем не менее, Rust же позиционируется как язык полный по Тьюрингу, да?
Здравствуйте, red75, Вы писали:
R>Если выразить инварианты программы на уровне типов,
Выражай их и в C++ — самая развитая система типов среди mainstream языков
R>то успешность компиляции будет гарантировать успешность работы.
Все инварианты, пред/пост-условия в типах не выразишь.
R>но по крайней мере могу быть достаточно уверен, что ошибка не вызвана buffer overrun в какой-нибудь отдалённой части программы или кривой библиотеке.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, red75, Вы писали:
R>>Ладно. _>...
_>Всё в общем то верно написано. Но как раз потому что "С++ медленно ползёт в сторону Rust" и возникает вопрос в востребованности Rust'a в будущем...
C++ может ползти куда угодно, только груз обратной совместимости будет всегда. У Rust такого груза нет и текущая концепция строилась по ходу его развития, изначально язык был другим и то, что мы видим сейчас – это результат эволюции без необходимости обеспечения обратной совместимости. Именно возможность строить язык не думаю об обратной совместимости дает возможность получить куда как более продвинутый язык по сравнению с решением, которое обязанно обеспечить обратную совместимость с 30-ю годами работы.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
KP>>Не противоречит при условии обеспечения гарантий на этапе компиляции. EP>Выполнение которго неразрешимо в общем случае.
В общем случае – да. В то же время, Rust дает тебе возможность получить такую гарантию в условных 90% случаев, в отличие от C++, который не дает такой гарантии никогда. Думаю, выбор довольно очевиден
Здравствуйте, kaa.python, Вы писали:
KP>C++ может ползти куда угодно, только груз обратной совместимости будет всегда.
Да, груз огромный. Помимо непосредственно языкового груза, есть ещё груз идиоматически устаревших книг, преподавателей и прогаммистов, застрявших где-то в конце 90-х. Да и к тому же за счёт возраста мифология богатая
KP>У Rust такого груза нет и текущая концепция строилась по ходу его развития, изначально язык был другим и то, что мы видим сейчас – это результат эволюции без необходимости обеспечения обратной совместимости. Именно возможность строить язык не думаю об обратной совместимости дает возможность получить куда как более продвинутый язык по сравнению с решением, которое обязанно обеспечить обратную совместимость с 30-ю годами работы.
Это здорово, но когда устаканится-то? Ведь пока он будет бурно развиваться "без необходимости обратной совместимости", его жеж и не будут массово использовать.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Это здорово, но когда устаканится-то? Ведь пока он будет бурно развиваться "без необходимости обратной совместимости", его жеж и не будут массово использовать.
Уже устаканилось, на версии 1.0 (текущая версия 1.5). Было обещание от авторов что все API, помеченное как "стабильное" не будет претерпевать "ломающих изменений". Текущее стабильно API достаточно для написания user-mode приложений. Если захочется попытаться запихнуть Rust в ядро или начать управлять памятью самостоятельно, то можно натолкнуться на "не стабильное" API, но это уже задачи для людей, которые однозначно понимают что они делают. Ну а до версии 1.0, года так 3, концепции языка менялись очень активно.
Здравствуйте, kaa.python, Вы писали:
KP>В общем случае – да. В то же время, Rust дает тебе возможность получить такую гарантию в условных 90% случаев,
Что насчёт проверки границ? Крайне распространённый случай.
KP>в отличие от C++, который не дает такой гарантии никогда.
Гарантия есть при выполнении ряда условий, которые вполне авто-верифицируемые.
Но да, без явной границы safe/unsafe в самом языке.
KP>Думаю, выбор довольно очевиден
При прочих сферических равных (которых естественно нет) — да, лучше инструмент с явным safe/unsafe контролем.
Для безопасного языка я бы ещё предпочёл явное включение полноты по Тьюрингу для отдельных частей.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, red75, Вы писали:
R>>Если выразить инварианты программы на уровне типов,
EP>Выражай их и в C++ — самая развитая система типов среди mainstream языков
Algebraic data types нет. Я где-то тут приводил темплейтно/макросный ужас, который нужен для более-вменяемого discriminated union.
Здравствуйте, red75, Вы писали:
EP>>Выражай их и в C++ — самая развитая система типов среди mainstream языков R>Algebraic data types нет.
Как это нет если есть?
R>Я где-то тут приводил темплейтно/макросный ужас, который нужен для более-вменяемого discriminated union.
Готовый Boost.Variant есть уже больше 13 лет — бери и используй. Если хочется реализовать свой, то на C++14 он реализуется на порядки проще чем на C++98.
Здравствуйте, ELazin, Вы писали:
EL>По опыту — С++ код, активно использующий семантику перемещения и уникальные указатели бывает иногда довольно сложно понять.
R>>Я где-то тут приводил темплейтно/макросный ужас, который нужен для более-вменяемого discriminated union.
EP>Готовый Boost.Variant есть уже больше 13 лет — бери и используй. Если хочется реализовать свой, то на C++14 он реализуется на порядки проще чем на C++98.
Отсутствие прямой поддержки языком сложно компенсировать. Нормальный pattern-matching c case totality check библиотекой не сделаешь. А так можно, конечно, и гланды ректально вырезать.
Здравствуйте, kaa.python, Вы писали:
_>>Всё в общем то верно написано. Но как раз потому что "С++ медленно ползёт в сторону Rust" и возникает вопрос в востребованности Rust'a в будущем... KP>C++ может ползти куда угодно, только груз обратной совместимости будет всегда. У Rust такого груза нет и текущая концепция строилась по ходу его развития, изначально язык был другим и то, что мы видим сейчас – это результат эволюции без необходимости обеспечения обратной совместимости. Именно возможность строить язык не думаю об обратной совместимости дает возможность получить куда как более продвинутый язык по сравнению с решением, которое обязанно обеспечить обратную совместимость с 30-ю годами работы.
Все правильно. Только вот ты перечислил исключительно отрицательные стороны большой истории языка. А есть и положительные: огромное число уже готовых программистов, инструментов, библиотек. Так вот, если народ будет полностью уверен, что пути C++ и Rust где-то в будущем пересекутся (в том смысле что C++ заберёт к себе все ключевые вкусности Rust'a), то у них не будет вообще никакого стимула слезать с текущих перечисленных выше вкусностей C++. Т.е. как C++11 по сути поставил крест (причём это произошло ещё до выхода самого стандарта, на этапе обсуждения и тестовых релизов в компиляторах) на выход D в мейнстрим (а одно время было ощущение, что ведущие спецы по C++ утомились попытками выжать невозможное из устаревшего языка и готовы перейти на D, где есть всё что надо), так и C++17 может поставить крест (опять же прямо сейчас, а не после 17-го года) на выход Rust'а в мейнстрим. Ведь думаю ни для кого не секрет, что такие языки как D, Rust, Nim и т.п., имеют шанс на выход в мейнстрим исключительно путём перехвата аудитории C/C++? И если C++ не будет давать им такого шанса (быстрым развитием в нужном направление), то...
Здравствуйте, alex_public, Вы писали:
_>Все правильно. Только вот ты перечислил исключительно отрицательные стороны большой истории языка. А есть и положительные: огромное число уже готовых программистов, инструментов, библиотек. Так вот, если народ будет полностью уверен, что пути C++ и Rust где-то в будущем пересекутся (в том смысле что C++ заберёт к себе все ключевые вкусности Rust'a), то у них не будет вообще никакого стимула слезать с текущих перечисленных выше вкусностей C++. Т.е. как C++11 по сути поставил крест (причём это произошло ещё до выхода самого стандарта, на этапе обсуждения и тестовых релизов в компиляторах) на выход D в мейнстрим (а одно время было ощущение, что ведущие спецы по C++ утомились попытками выжать невозможное из устаревшего языка и готовы перейти на D, где есть всё что надо), так и C++17 может поставить крест (опять же прямо сейчас, а не после 17-го года) на выход Rust'а в мейнстрим. Ведь думаю ни для кого не секрет, что такие языки как D, Rust, Nim и т.п., имеют шанс на выход в мейнстрим исключительно путём перехвата аудитории C/C++? И если C++ не будет давать им такого шанса (быстрым развитием в нужном направление), то...
Отчасти согласен, хотя есть с чем не согласиться. У C++ много готовых программистов, хотя уровень их, в общем случае, оставляет желать лучшего. C++11 вернул надежду в то, что язык будет полезен, хотя C++17 уже начинает пугать своей монструозностью и перегруженностью. Не забывай о том, что Rust дает много плюшек и одна, ключевая на мой взгляд – простота языка. C++17 – это ж просто монстр какой-то сверхперегруженный, и что еще хуже, ты не можешь пользоваться только им, знать C++03 (а иногда и C++98) так же необходимо.
Тот же Go довольно успешно отобрал изрядный кусок рынка у C++, тоже делает и Rust, который в отличие от Go может подвинуть не только C++, но и C благодаря тому, что может работать вообще без рантайма. Мало кто любит писать на слишком уж перегруженных языках и уметь ориентироваться в как минимум 3-х стандартах (по 1200+ страниц каждый). Так что C++17, как мне кажется, это скорее не убийца D/Rust/Nim (хотя что убивать и так дохлый D и почти никому не известный Nim?), а гвоздь в гроб C++ – нельзя делать таких монстров, задалбывает их учить
Здравствуйте, red75, Вы писали:
R>>>Я где-то тут приводил темплейтно/макросный ужас, который нужен для более-вменяемого discriminated union. EP>>Готовый Boost.Variant есть уже больше 13 лет — бери и используй. Если хочется реализовать свой, то на C++14 он реализуется на порядки проще чем на C++98. R>Отсутствие прямой поддержки языком сложно компенсировать. Нормальный pattern-matching c case totality check библиотекой не сделаешь.
Это выделение есть только в определённых случаях. При этом даже если бы Variant был встроен в язык — то этот tradeoff всё равно пришлось бы так или иначе совершать
R>Небольшая библиотечка, которая работает начиная с gcc 4.7, то есть 4 года, позволяющая более-менее комфортно извлекать значения из variant https://github.com/exclipy/inline_variant_visitor
Ну да, с появлением лямбд inline-обход спокойно реализуется, например
vector<variant<int, double>> ys;
for(auto x : xs)
ys.push_back
(
MATCH(x)
CASE(x IS widget) { println("x IS widget"); return 1; }
CASE(x IS gadget) { println("x IS gadget"); return 0.1; }
);
R>то есть 4 года
То есть пока Rust пешком под стол ходил, в реальных проектах C++ можно было не только использовать Variant, но и комфортно его обходить, с гарантией обратной совместимости. При этом в mainstream языках помимо C++ ничего подобного нет и по сей день.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Что насчёт проверки границ? Крайне распространённый случай.
Само собой есть. Выглядит как-то так:
fn main() {
let v = vec![1, 2, 3];
let t = v[3];
}
thread '<main>' panicked at 'index out of bounds: the len is 3 but the index is 3', ../src/libcollections/vec.rs:1137
С одной стороны, никакого непредвиденного поведения с отложенным падением, с другой, на этапе компиляции такие ошибки не отслеживаются (можно ли такое отследить во время компиляции отдельный вопрос). Само собой, можно повторить типичный C/C++ выход за границы с непредсказуемым падением воспользовавшись unsafe.
Здравствуйте, kaa.python, Вы писали:
KP>Само собой, можно повторить типичный C/C++ выход за границы с непредсказуемым падением воспользовавшись unsafe.
, либо мы платим тормозами за корректность, либо заворачиваемся в unsafe даже в таких типичных местах как массивы.
Тот, кому важны микросекунды – C++ тоже не возьмет по причине слишком больших накладных расходов в виде обработки исключений, подсчете ссылок и т.д. Посмотри на тесты скорости: в 50% случаев Rust обгоняет C++, в 30% обгоняет C и это без unsafe. Именно поэтому я и говорю о том, что Rust вобщем-то не уступает C++ и лишь слегка проигрывает C в скорости работы сгенерированного кода. Но при этом, он дает ряд гарантий о которых в C никто даже не мечтает, а в C++ изредка задумываются и рождают очередного монстра.
Здравствуйте, kaa.python, Вы писали:
KP>Тот, кому важны микросекунды – C++ тоже не возьмет
И что же он возьмёт?
KP>по причине слишком больших накладных расходов в виде обработки исключений,
На x64 практически zero-overhead exceptions на happy-path. Там где это играет значимую роль — их можно не использовать или даже отключить.
KP>подсчете ссылок и т.д.
Подсчёт ссылок требуется крайне редко — там где требуется разделяемое владение и точка удаления зависит от внешних условий. В Rust кстати, как я вижу, в этих же местах будет тот же самый подсчёт ссылок
KP>Посмотри на тесты скорости: в 50% случаев Rust обгоняет C++,
Подозрительные тесты, например нет -DNDEBUG. В общем нужно проверять.
KP>в 30% обгоняет C и это без unsafe.
C в среднем тот ещё тормоз, на него не надо ровняться. Отсутствие шаблонов закономерно ведёт к избыточному стиранию типов и аллокациям, каноничный пример — GLib.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, red75, Вы писали:
R>>>>Я где-то тут приводил темплейтно/макросный ужас, который нужен для более-вменяемого discriminated union. EP>>>Готовый Boost.Variant есть уже больше 13 лет — бери и используй. Если хочется реализовать свой, то на C++14 он реализуется на порядки проще чем на C++98. R>>Отсутствие прямой поддержки языком сложно компенсировать. Нормальный pattern-matching c case totality check библиотекой не сделаешь.
EP>Сделаешь. Pattern-matching по типам (то что нужно для Variant) есть в C++ начиная с C++98, totality check автоматом вытекает из свойств перегрузки. EP>Лямбды для inplace-ности появились в C++11, да
Под нормальным паттерн-матчингом я имел в виду в том числе и destructuring. Вот, только что написал:
for (idx, vref) in chunk.iter_mut().enumerate() {
...
};
Это получение индексов и ссылок на мутабельные элементы массива без проверок границ массива. (idx, vref) деструктурирует tuple, возвращаемый enumerate().
Какое-то подобие деструктурирования tuple в C++ есть: std::tie() lvalue с использованием временных переменых, но более сложные случаи, вроде нижеприведенного, уже не обработаешь.
match maybe_point {
Some(x,y) => {...},
None => {...},
}
EDIT: Вставлю полный код. Параллельная обработка массива в несколько потоков:
crossbeam::scope(|scope| {
let chunk_len = (cubes.len()/thread_cnt as usize)+1;
for (ch_idx, chunk) in cubes[..].chunks_mut(chunk_len).enumerate() {
let start = ch_idx*chunk_len;
scope.spawn(move || {
for (idx, c) in chunk.iter_mut().enumerate() {
let cube = &self.cubes[start+idx];
*c = CubeState {
pos: cube.pos + cube.spd * dt,
rot: Basis3::from_axis_angle(cube.rot_axe, Angle::from(deg(cube.rot_spd * dt))).concat(&cube.rot),
.. *cube
};
};
});
};
});
EDIT2: Можно вообще без проверок границ массива в self.cubes[start+idx] обойтись:
crossbeam::scope(|scope| {
let chunk_len = (cubes.len()/thread_cnt as usize)+1;
for (chunk, chunk_src) in cubes[..].chunks_mut(chunk_len).zip(self.cubes[..].chunks(chunk_len)) {
scope.spawn(move || {
for (c, cube) in chunk.iter_mut().zip(chunk_src) {
*c = CubeState {
pos: cube.pos + cube.spd * dt,
rot: Basis3::from_axis_angle(cube.rot_axe, Angle::from(deg(cube.rot_spd * dt))).concat(&cube.rot),
.. *cube
};
};
});
};
});
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>И что же он возьмёт?
Си?
EP>На x64 практически zero-overhead exceptions на happy-path. Там где это играет значимую роль — их можно не использовать или даже отключить.
Ну начинается, отключить один из основополагающих механизмов языка...
EP>Подсчёт ссылок требуется крайне редко — там где требуется разделяемое владение и точка удаления зависит от внешних условий. В Rust кстати, как я вижу, в этих же местах будет тот же самый подсчёт ссылок
std::shared_ptr?
EP>Подозрительные тесты, например нет -DNDEBUG. В общем нужно проверять.
Хорошие тесты, уже лет 10 как единственный сравнительно объективный способ узнать скорость выполнения кода на том или ином языке.
EP>C в среднем тот ещё тормоз, на него не надо ровняться. Отсутствие шаблонов закономерно ведёт к избыточному стиранию типов и аллокациям, каноничный пример — GLib.
Я могу сказать только одно. Можно и дальше "молиться" на C++ и надеяться что "вот уж со следующим стандартом жизнь наладится", а можно просто посмотреть по сторонам. C++ слишком тяжел, сложен и обладает очень громоздким наследием. Его не просто так теснят все кому не попадя, начиная от JMV-языков, заканчивая Go. Если есть два варианта решения одной и той же задачи с одним и тем же уровнем эффективности, никто, кроме как из "религиозных" соображений, не возьмет более сложный инструмент.
Здравствуйте, kaa.python, Вы писали:
EP>>И что же он возьмёт? KP>Си?
Зачем?
EP>>C в среднем тот ещё тормоз, на него не надо ровняться. Отсутствие шаблонов закономерно ведёт к избыточному стиранию типов и аллокациям, каноничный пример — GLib. KP>Я могу сказать только одно. Можно и дальше "молиться" на C++ и надеяться что "вот уж со следующим стандартом жизнь наладится",
Так было до C++11 — так как был огромный промежуток между стандартами. Move semantic, variadic templates, auto, замыкания — всё это действительно ждали а-ля "жизнь наладится".
В C++11 было несколько белых пятен, которых не хватало для целостности, типа полиморфных лямбд, auto return type и т.д. C++14 закрыл эти дыры.
В C++17 ничего прорывного не планируется, разве что concept lite. И сейчас нет никакого ощущения а-ля "вот уж со следующим стандартом жизнь наладится"
KP>а можно просто посмотреть по сторонам. C++ слишком тяжел, сложен и обладает очень громоздким наследием. Его не просто так теснят все кому не попадя, начиная от JMV-языков, заканчивая Go. Если есть два варианта решения одной и той же задачи с одним и тем же уровнем эффективности, никто, кроме как из "религиозных" соображений, не возьмет более сложный инструмент.
Согласен, C++ слишком тяжёл и обладает громоздким наследием. Можно оставаться в рамках удобного и современного subset, но действительно, скорей всего рано или поздно придётся столкнутся со старым кодом, или просто старым стилем, и для его понимания и модификации придётся освоить всю эту тяжесть.
Но полностью заменить C++ сможет язык у которого точно такие же design guidelines, те же самые принципы. Если же guidelines отличаются, то максимум что получиться — это откусить какую-то часть рынка, точно также как в своё время откусили Java и C#.
Я был бы только рад если бы была полноценная современная замена C++ без всей этой тяжести и громоздкого наследия, но увы её на данный момент нет. Насколько я вижу — ближе всех подошёл D, но даже сами авторы заявляют что D следует другим принципам.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Согласен, C++ слишком тяжёл и обладает громоздким наследием. Можно оставаться в рамках удобного и современного subset, но действительно, скорей всего рано или поздно придётся столкнутся со старым кодом, или просто старым стилем, и для его понимания и модификации придётся освоить всю эту тяжесть.
Нельзя оставаться в рамках современного подмножества. Новички в C++ идут крайне не охотно (и правильно делают), те кто выучил его давно очень часто не учат никакого нового подмножества. При этом язык разрешает творить что угодно, и очень часто, это что угодно выглядит как жутчавшее УГ. Проблема C++ в том, что для его корректного использования нужна очень продвинутая команда, т.к. компилятор по рукам дает крайне редко.
EP>Но полностью заменить C++ сможет язык у которого точно такие же design guidelines, те же самые принципы. Если же guidelines отличаются, то максимум что получиться — это откусить какую-то часть рынка, точно также как в своё время откусили Java и C#.
Да никто его полностью не заменит, нужно же кучу копролита мамонта поддерживать, дорабатывать, развивать.
Здравствуйте, uncommon, Вы писали:
EP>>В C++17 ничего прорывного не планируется, разве что concept lite. U>Да ну? Прямо из Бьярновского отчёта: U>
U>Summary of the features (discussed in this meeting) that I consider most significant:
U>Concepts
U>Modules
U>Parallelism TS
U>Ranges TS
U>Concurrency TS
U>Contracts
U>Coroutines
U>Order of evaluation
U>Uniform function call syntax
U>variant, array_view, and string_view
U>Structured bindings (simpler handling of multiple return values)
U>[fallthrough]]
U>Как ни крути, штук 5 больших прорывных фич будет.
Модули под большим вопросом, то есть их может и не быть в C++17. Из более менее прорывного — концепции, их давно ждут.
Что здесь ещё принципиально прорывного? Что ждут вот так чтобы прям "жизнь наладилась"?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Подозреваю что как раз в общем случае оно и верно. EP>Каким образом? Если у нас язык полный по Тьюрингу, то в статике такая задача неразрешима.
Да, в _самом_ общем случае, конечно, неверно.
Я имел в виду, что можно свести все множество корректных программ к подмножеству, правильность которого можно доказать статически. (Конечно, наверняка некоторая часть корректных программ по каким-то причинам — время доказательства, например — не может быть сведена к этому подмножеству, и придется вводить "небезопасные недоказанные блоки".)
Rust на данный момент такой цели перед собой не ставит, у него задачи менее амбициозные и более приближенные к реальности.
DM>-Ножами жонглировать трудно и опасно! DM>-Не опасно и легко, надо просто правильно это делать. DM>-Трудно и опасно, я пробовал и весь поранился. DM>-Ты просто не можешь в жонглирование и жалуешься на жизнь.
Скорее так:
— Пить алкоголь опасно.
— Не опасно если меру знать.
— Нет, каждый раз, когда я пробую алкоголь, оказываюсь в вытрезвителе и однажды лишился бумажника.
— ??!!%$#
R>1) Статические анализаторы в комплекте с С++ не идут. В стандарте не написано: "Вы должны использовать статический анализатор, чтобы не использовать одну из многих любезно предоставленных нами возможностей выстрелить себе в ногу".
По крайней мере они там есть. В ногу можно выстрелить везде. В том же Rust строки — мутабельные. Язык, появившийся в 2015-м году имеет мутабельные строки в своей стандартной библиотеке. Жизнь людей ничему не учит.
R>2) Крупные компании прекрасно понимают, что идеальных программистов, помнящих и мгновенно замечающих все неопределенные и неспецифицированные поведения, и с первого взгляда выполняющих
двухфазное разрешение имён, с учетом всего исходника проекта, не существует. Поэтому пытаются ужать всю мощь и свободу С++ до приемлемых рамок: https://google.github.io/styleguide/cppguide.html
Это ты еще не видел style guide блумберга. Style guide нужен не для того, чтобы ограничить мощь до приемлемых рамок а для того, чтобы унифицировать код. Чтобы сделать чтение и переиспользование кода более простыми процессами. Для java тоже пишут style guides, даже для питона пишут. Это не аргумент.
R>3) Но это не особо помогает: https://bugs.chromium.org/p/nativeclient/issues/detail?id=245 см. Type 3 Functions, всё равно напоролись на неспецифицированное поведение.
Т.е. в С++ проекте, который содержит десятки миллионов LOC, который пилится огромным количеством людей, нашли баг. Удивительно Баг, кстати, не очень то С++ специфичен.
R>4) Не помню чьё высказвание "Наговнокодить можно на любом языке", которое Вы, вероятно, поддерживаете, совершенно бесполезно для сравнения языков. Вопрос в том насколько легко язык позволяет сделать ошибку обычному программисту. Напомню, что даже Бьярн Страуструп в своей книге по С++ напоролся на неспецифицированное поведение. http://stackoverflow.com/questions/27158812/does-this-code-from-the-c-programming-language-4th-edition-section-36-3-6-ha
Есть две категории языков программирования. Первая категория — языки, которые пытаются сделать так, чтобы программисту было сложно допустить ошибку. Вторая категория — языки на которых максимально просто писать, но которые при этом оставляют возможность выстрелить себе в ногу (хорошие примеры — python, C). С++ это скорее компромисс, его свойства зависят от стиля. На С++ можно нарулить такой интерфейс, который просто не позволит использовать себя неправильно, проверяя корректность в compile time. Но можно писать в стиле Си с классами, тут кто как хочет, так и прелюбодействует.
R>5) 5 простых спобов выстрелить себе в ногу с использованием shared_ptr: http://habrahabr.ru/post/191018/
Бредовая статья.
R>6) Даже комитет по C++ понимает наличие проблем. Планируют введение статического анализа времени жизни переменных, в частности для предотвращения работы с инвалидированными итераторами.
Если это делают в Rust, то это хорошо, если же подобное появляется в С++, то плохо. Ясно-понятно.
R>Итого: С++ медленно ползёт в сторону Rust, таща за собой сорокалетние напластования фич, кучу неопределенных и неспецифицированных поведений в невинно выглядящих конструкциях, тонны legacy-кода.
Да не ползет он никуда.
R>Tooling, конечно, у с++ лучше. Даже gbd уже года 3 показывает правильные значения переменных http://stackoverflow.com/questions/10315430/gdb-prints-wrong-values
Ну gdb он какбы универсален (не только для С++), к тому же мне он показывает правильные значения переменных последние лет эдак 7.
R>А то что я писал про свою программку на Rust это не wishful thinking, а простое следствие того, что статический анализатор встроен в Rust.
Это не статический анализатор.
R>Если выразить инварианты программы на уровне типов, то успешность компиляции будет гарантировать успешность работы. Я, конечно, до такого уровня не дошёл (собственно в Rust'е это полностью и не получится. Например, там нельзя реализовать session types), но по крайней мере могу быть достаточно уверен, что ошибка не вызвана buffer overrun в какой-нибудь отдалённой части программы или кривой библиотеке.
Расскажи нам, пожалуйста, как можно buffer overrun типами запретить. Более или менее сложный код требует проверок в рантайме, хотя бы старый добрый assert. Проверки в CT в С++ нужны в основном в обобщенном коде.
Основная проблема С++ на данный момент — отсутствие системы модулей. Вот это вот все, о чем ты говоришь, это не проблема вообще, люди десятилетиями делают проекты на С++ и даже на С. Есть вещи, которые в С++ делаются намного проще чем в "более мощных" языках программирования. Если мне нужно сделать огромную разреженную таблицу в памяти я буду работать с памятью напрямую (calloc, copy on write, арифметика указателей и все такое) а не возиться с временами жизни в Rust. А если я возьму для этого Rust, мне все равно придется писать unsafe код, только у меня не будет calloc и арифметики указателей и всего такого.
KP>В общем случае – да. В то же время, Rust дает тебе возможность получить такую гарантию в условных 90% случаев, в отличие от C++, который не дает такой гарантии никогда. Думаю, выбор довольно очевиден
Я правильно понял, что если Rust дает такие гарантии, то С++ автоматически перестает давать вообще любые гарантии корректности? Мне кажется что lifetime analysis в Rust очень специфичен. Он позволяет например взять внутренний буфер строки и перелопатить его и не бояться что этот буфер переживет строку. Но этот (и аналогичные ему) кейсы, они же странные. Любой С++ программист это все в голове умеет анализировать. Это все просто.
Здравствуйте, ELazin, Вы писали:
R>>EDIT: Вставлю полный код. Параллельная обработка массива в несколько потоков:
EL>О да! Параллельный код, который вручную создает потоки и вручную делит массив на thread_cnt частей. So solid, so 2016
Я параллельное программирование в контексте С++ вообще не упоминал. Понятно почему? Потому что там с этим полная Ж с большой буквы. Ваша позиция понятна: "Настоящий программист напишет что угодно на чём угодно. И я знаю этого программиста". Особо спорить не о чем.
Здравствуйте, red75, Вы писали:
R>Отсутствие прямой поддержки языком сложно компенсировать. Нормальный pattern-matching c case totality check библиотекой не сделаешь. А так можно, конечно, и гланды ректально вырезать.
Важен же не только синтаксический сахар, но и итоговое быстродействие. К примеру вот у таких https://github.com/solodon4/Mach7 решений сразу видно что с быстродействием...
Здравствуйте, kaa.python, Вы писали:
KP>Не забывай о том, что Rust дает много плюшек и одна, ключевая на мой взгляд – простота языка.
Очень сомнительно. Одни модели памяти уже автоматом делают его мягко говоря не простым. Вот тот же Go — действительно простой. Но у него совсем другая целевая аудитория.
KP>C++17 – это ж просто монстр какой-то сверхперегруженный, и что еще хуже, ты не можешь пользоваться только им, знать C++03 (а иногда и C++98) так же необходимо.
Пока что это всё "пугалки" (ну а для кого-го надежды ), посмотрим что там будет в итоге.
KP>Тот же Go довольно успешно отобрал изрядный кусок рынка у C++, тоже делает и Rust, который в отличие от Go может подвинуть не только C++, но и C благодаря тому, что может работать вообще без рантайма.
Не, Go вообще из другой области. Он скорее где-то между Python/Ruby с одной стороны и Java/C# с другой, отъедая у обоих этих лагерей понемногу. Причём только в одной специфической области веб-бэкенда. В этой области C++ конечно же тоже присутствует но только в особых случаях, требующих повышенного быстродействия (типа поисковиков google, yandex и т.п.), а это Go уже не может. Так что даже в своей родной области Go не может подвинуть C++. Куда уж тут говорить про такие родные области C++ как системный код и т.п.
KP>Так что C++17, как мне кажется, это скорее не убийца D/Rust/Nim (хотя что убивать и так дохлый D и почти никому не известный Nim?), а гвоздь в гроб C++ – нельзя делать таких монстров, задалбывает их учить
Не, это как раз D/Rust/Nim изначально создавались как убийцы C/C++, но что-то они похоже какие-то неудачники пока... )
Здравствуйте, ELazin, Вы писали:
KP>>В общем случае – да. В то же время, Rust дает тебе возможность получить такую гарантию в условных 90% случаев, в отличие от C++, который не дает такой гарантии никогда. Думаю, выбор довольно очевиден EL>Я правильно понял, что если Rust дает такие гарантии, то С++ автоматически перестает давать вообще любые гарантии корректности? Мне кажется что lifetime analysis в Rust очень специфичен. Он позволяет например взять внутренний буфер строки и перелопатить его и не бояться что этот буфер переживет строку. Но этот (и аналогичные ему) кейсы, они же странные. Любой С++ программист это все в голове умеет анализировать. Это все просто.
Человек, насколько профессионален он бы не был, неспособен контролировать абсолютно все аспекты создаваемого кода, поэтому там всегда будут баги. В статье про Dangling pointer приведены вполне реальные примеры, плюс указано, что все современные статические анализаторы занимаются поиском подобных багов, что как-то не вяжется с утверждением, что "Любой С++ программист это все в голове умеет анализировать", согласитесь? Ну и в компанию можно добавить знаменитое Null References: The Billion Dollar Mistake и прочие.
В любом языке можно написать библиотеки, более-менее гарантирующие безопасную работу с памятью, но никто не может заставить программистов использовать их и только их, в этом вся проблема. Заслуга Rust'а в том, что он первый из неакадемических языков, кто попытался разделить ответственности: программист пишет алгоритм, компилятор проверяет, что код работает корректно в обозначенных областях. Это минимизация вклада человеческого фактора в корректность кода и за этим будущее, так как тенденция показывает, что код все более и более усложняется со временем.
Современный C++ слишком монструозен и сложен, что сильно удорожает как подготовку нормальных специалистов, так и сам процесс написания.
Здравствуйте, kaa.python, Вы писали:
KP>Я могу сказать только одно. Можно и дальше "молиться" на C++ и надеяться что "вот уж со следующим стандартом жизнь наладится", а можно просто посмотреть по сторонам. C++ слишком тяжел, сложен и обладает очень громоздким наследием. Его не просто так теснят все кому не попадя, начиная от JMV-языков, заканчивая Go. Если есть два варианта решения одной и той же задачи с одним и тем же уровнем эффективности, никто, кроме как из "религиозных" соображений, не возьмет более сложный инструмент.
Кстати, очень характерно взглянуть на этой же страничке на цифры для D, Rust и Swift (как пример того, как выглядит новый язык, который всё же взлетел).
Здравствуйте, ELazin, Вы писали:
R>>1) Статические анализаторы в комплекте с С++ не идут. В стандарте не написано: "Вы должны использовать статический анализатор, чтобы не использовать одну из многих любезно предоставленных нами возможностей выстрелить себе в ногу". EL>По крайней мере они там есть. В ногу можно выстрелить везде. В том же Rust строки — мутабельные. Язык, появившийся в 2015-м году имеет мутабельные строки в своей стандартной библиотеке. Жизнь людей ничему не учит.
В Rust'е базовый строковой тип — str, он содержит иммутабельные строки. String же представляет строковый мутабельный буфер. С этой позиции Rust ничем не отличается от других мейнстримных языков.
Здравствуйте, kaa.python, Вы писали:
KP>Да никто его полностью не заменит, нужно же кучу копролита мамонта поддерживать, дорабатывать, развивать.
"Копролит мамонта" говоришь? )Ну вот смотри. Допустим я хочу начать сейчас новый проект в области IoT (одно из самых модных сейчас направлений). И соответственно мне там придётся работать с процессорами Cortex-M0. Вопрос: какой язык мне выбрать для этого нового проекта? )
В>В Rust'е базовый строковой тип — str, он содержит иммутабельные строки. String же представляет строковый мутабельный буфер. С этой позиции Rust ничем не отличается от других мейнстримных языков.
Базовый строковый тип &str в расте это примерно то же самое, что и const char* на статическую строку в С++ (было бы странно, если бы живущая в сегменте данных строка была изменяемой). Поскольку все строки в приложении не могут быть статическими, я все же склоняюсь к тому, чтобы считать базовым строковым типом String. А изменяемый строковый тип, это то от чего современное программирование постепенно уходит. В большинстве современных ЯП строки неизменяемы (python, java, c#, go и тд).
Здравствуйте, kaa.python, Вы писали:
EP>>Подозрительные тесты, например нет -DNDEBUG. В общем нужно проверять. KP>Хорошие тесты, уже лет 10 как единственный сравнительно объективный способ узнать скорость выполнения кода на том или ином языке.
Здравствуйте, red75, Вы писали:
EL>>О да! Параллельный код, который вручную создает потоки и вручную делит массив на thread_cnt частей. So solid, so 2016 R>Я параллельное программирование в контексте С++ вообще не упоминал. Понятно почему? Потому что там с этим полная Ж с большой буквы. Ваша позиция понятна: "Настоящий программист напишет что угодно на чём угодно. И я знаю этого программиста". Особо спорить не о чем.
В>В любом языке можно написать библиотеки, более-менее гарантирующие безопасную работу с памятью, но никто не может заставить программистов использовать их и только их, в этом вся проблема. Заслуга Rust'а в том, что он первый из неакадемических языков, кто попытался разделить ответственности: программист пишет алгоритм, компилятор проверяет, что код работает корректно в обозначенных областях. Это минимизация вклада человеческого фактора в корректность кода и за этим будущее, так как тенденция показывает, что код все более и более усложняется со временем.
Ну вот опять забыли java/C# и кучу других языков с GC. До Rust-а конечно же об этих проблемах никто не думал и не решал их, ага. Самый проверенный временем подход к решению проблемы memory safety это языки с GC (memory safety through garbage collection). При этом компилятор Java, например, умеет вставлять код, который проверяет выход за границы массивов, но оптимизатор hotspot умеет этот код убирать, если он избыточен. И при этом, в отличии от Rust, в Java в принципе невозможно испортить память или уронить приложение по segfault (если нет нативного кода). При этом там стандартная библиотека не напичкана unsafe блоками, в отличии от. И все это очень здорово минимизирует возможный негативный вклад человеческого фактора. Опять же туллинг, книжки, программисты настоящие есть. Вы уж определитесь, если нужно писать низкоуровневый быстрый код, для всяких узких задач, то тут Rust-у явно не место. Он слишком высокоуровневый, как тут уже писали, на нем даже нельзя OOM обработать. А там где раст будет хорошо работать, java и C# будут работать еще лучше. Даже Go будет работать лучше, потому что там нет лишней когнитивной нагрузки, связанной с lifetimes, при этом ногу себе отстрелить сложно.
В>Современный C++ слишком монструозен и сложен, что сильно удорожает как подготовку нормальных специалистов, так и сам процесс написания.
Практика показывает, что дорого и сложно — пытаться писать идеальные системы, которые by design не могут содержать ошибок (как тут кое-кто хотел типами инварианты доказывать). Реальный код слишком быстро меняется а бюджет времени на разработку не так велик.
Здравствуйте, ELazin, Вы писали:
В>>В Rust'е базовый строковой тип — str, он содержит иммутабельные строки. String же представляет строковый мутабельный буфер. С этой позиции Rust ничем не отличается от других мейнстримных языков.
EL>Базовый строковый тип &str в расте это примерно то же самое, что и const char* на статическую строку в С++ (было бы странно, если бы живущая в сегменте данных строка была изменяемой). Поскольку все строки в приложении не могут быть статическими, я все же склоняюсь к тому, чтобы считать базовым строковым типом String. А изменяемый строковый тип, это то от чего современное программирование постепенно уходит. В большинстве современных ЯП строки неизменяемы (python, java, c#, go и тд).
Нет, это не так. &str указывает на валидную неизменяюмую последовательность UTF-8 символов безотносительно того, где она находится. Это может быть статическая строка, это может быть содержимое другого буфера.
Статичность данных задается только через лайфтаймы и не имеет никакого отношения к типам (&'static str будет указывать на статическую строку).
Небольшой пример:
// Так как мы не знаем какой длины будет строка, то используем String, который будет динамически выделять память по мере необходимостиlet mut input = String::new();
io::stdin().read_line(&mut input); // Читаем данныеlet s = &input; // s имеет тип &str и указывает на прочитанную строку, хранящуюся в input. Rust гарантирует, что никто больше не сможет изменить input, пока "аренда" строки через s не закончитсяlet static_str = "abcde"; // А здесь static_str имеет тип &'static str и указывает на статическую строку.
Здравствуйте, ELazin, Вы писали:
В>>В любом языке можно написать библиотеки, более-менее гарантирующие безопасную работу с памятью, но никто не может заставить программистов использовать их и только их, в этом вся проблема. Заслуга Rust'а в том, что он первый из неакадемических языков, кто попытался разделить ответственности: программист пишет алгоритм, компилятор проверяет, что код работает корректно в обозначенных областях. Это минимизация вклада человеческого фактора в корректность кода и за этим будущее, так как тенденция показывает, что код все более и более усложняется со временем.
EL>Ну вот опять забыли java/C# и кучу других языков с GC. До Rust-а конечно же об этих проблемах никто не думал и не решал их, ага. Самый проверенный временем подход к решению проблемы memory safety это языки с GC (memory safety through garbage collection). При этом компилятор Java, например, умеет вставлять код, который проверяет выход за границы массивов, но оптимизатор hotspot умеет этот код убирать, если он избыточен. И при этом, в отличии от Rust, в Java в принципе невозможно испортить память или уронить приложение по segfault (если нет нативного кода). При этом там стандартная библиотека не напичкана unsafe блоками, в отличии от. И все это очень здорово минимизирует возможный негативный вклад человеческого фактора. Опять же туллинг, книжки, программисты настоящие есть. Вы уж определитесь, если нужно писать низкоуровневый быстрый код, для всяких узких задач, то тут Rust-у явно не место. Он слишком высокоуровневый, как тут уже писали, на нем даже нельзя OOM обработать. А там где раст будет хорошо работать, java и C# будут работать еще лучше. Даже Go будет работать лучше, потому что там нет лишней когнитивной нагрузки, связанной с lifetimes, при этом ногу себе отстрелить сложно.
Эти утверждение в большей части или некорректны, или не подтверждаются практикой. Проблема Java/C# в том, что безопасное программирование в них дается за счет значительного увеличения накладных расходов, а именно расходов на сборку мусора, подход же Rust'а заключается в том, чтобы дать нужные гарантии по возможности за счет компайлтайма, а не рантайма, что очень хорошо скажется на скорости выполнения и размере требуемой памяти. Я персонально могу гарантировать, что аналогичная программа на Rust работает практически всегда "лучше", чем аналогичные на java/C#, так как наблюдаю это на практике.
Rust весьма хорош и для написания быстрого низкоуровневого кода. Отсутствие обработки OOM не делает его высокоуровневым, так как это ограничение его библиотеки (не путаем язык и библиотеку). Сам язык позволяет, при необходимости, обрабатывать OOM. Rust умеет убирать проверки на выход за границы массивов, там где они не нужны. Rust слишком молод, и пока не имеет хорошего инструментария, что компенсируется в будущем.
В>>Современный C++ слишком монструозен и сложен, что сильно удорожает как подготовку нормальных специалистов, так и сам процесс написания. EL>Практика показывает, что дорого и сложно — пытаться писать идеальные системы, которые by design не могут содержать ошибок (как тут кое-кто хотел типами инварианты доказывать). Реальный код слишком быстро меняется а бюджет времени на разработку не так велик.
Это никак не связано с Rust'ом, писать на нем достаточно комфортно и быстро, при условии знания языка. У меня есть проекты игрушечных ОС, написанных на C++ и Rust'е: по моим персональным ощущениям скорость написания кода на Rust'е была весьма выше, в то же время процент багов заметно ниже. Очень положительное впечатление оставила продуманность libcore: при отсутствии стандартной библиотеки практически весь необходимый функционал (a-la printf, форматирование произвольных структур, stack unwinding, etc) реализуется за считанные часы. Сам код по качеству сравним с аналогичным сишным. Собственно это и послужило стартом моего интереса к языку. Я рекомендую вам тоже попытаться поработать с ним, что даст вам возможно новые впечатления. Пока, судя по замечаниям о языке в других сообщениях, вы спорите о предмете который не знаете.
Никто как бы и не говорит, что C++ плох, мы говорим о том, что в наше время развития информационных технологий надо искать новые методы облегчения труда программистов. Мы прошли через эру Java и C#: облегчение — да, но за счет ресурсов, что не везде применимо. Следующий этап — Rust и гарантии безопасности во время компиляции. Что будет дальше, приживется ли Rust, появится ли другой язык — я не знаю, но я рад, что вещи движутся в нужном и правильном направлении.
Здравствуйте, alex_public, Вы писали:
_>http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html — что-то как-то странно они его теснят. )))
_>Кстати, очень характерно взглянуть на этой же страничке на цифры для D, Rust и Swift (как пример того, как выглядит новый язык, который всё же взлетел).
А чего цифры?
D 1.015
Objective-C 1.074
Swift 1.363
JavaScript 2.565
Со взлетелостью Objective-C никто спорить не станет, я думаю, а судя по этим цифрам D тогда тоже неплохо взлетел. Вот Расту там в 5 раз меньше дали рейтинг, и по-моему это очень странные цифры, очень странные. Судя по бурлениям интернетов в последние год-два и статистике всяких гитхабов, Раст должен опережать Ди, а не отставать так сильно. Кароч, я б не стал с серьезным лицом на этот рейтинг ссылаться.
Здравствуйте, D. Mon, Вы писали:
_>>http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html — что-то как-то странно они его теснят. ))) _>>Кстати, очень характерно взглянуть на этой же страничке на цифры для D, Rust и Swift (как пример того, как выглядит новый язык, который всё же взлетел). DM>А чего цифры? DM>
DM>Со взлетелостью Objective-C никто спорить не станет, я думаю, а судя по этим цифрам D тогда тоже неплохо взлетел. Вот Расту там в 5 раз меньше дали рейтинг, и по-моему это очень странные цифры, очень странные. Судя по бурлениям интернетов в последние год-два и статистике всяких гитхабов, Раст должен опережать Ди, а не отставать так сильно. Кароч, я б не стал с серьезным лицом на этот рейтинг ссылаться.
Нуу D действительно постепенно пытается выбраться из зоны маргинальных языков. Однако надо учесть, что это уже лет 10 происходит и результат трудно назвать реальным успехом. Swift же явно смог всего за год (и думаю в будущем его процент будет заметно выше). Что касается Objective-C то тут обратная ситуация. Даже до выхода Swift'a это был откровенно унылый язык, который держался на плаву только из-за его особой поддержке на одной из платформ, переживающей краткий пик популярности (я про айфоны). Теперь же, после появления даже на этой уже не самой популярной платформе другого главного языка, Objective-C является однозначным трупом (http://www.tiobe.com/index.php/content/paperinfo/tpci/Objective_C.html тут это отлично видно).
Что касается Rust, то почему ты думаешь, что цифры не верны? Да, обсуждали (и надеялись) многие, и я в том числе. Только вот какой процент из них начал использовать данный язык в реальных проектах? Подозреваю что у Rust'а ситуация в точности такая же, как и у D в первые годы его появления. И соответственно прогнозы могут быть такие же неутешительные — невыход из маргинальной зоны в ближайшее десятилетие.
Здравствуйте, LaPerouse, Вы писали:
В>>Паттерн-матчинг; В>>Алгебраические типы данных;
LP>Эти два пункта скорее минус, чем плюс, так как провоцируют написание г-нокода.
Но есть ли нормальная замена union-типам? Все делать на классах?
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, LaPerouse, Вы писали:
В>>>Паттерн-матчинг; В>>>Алгебраические типы данных;
LP>>Эти два пункта скорее минус, чем плюс, так как провоцируют написание г-нокода.
ARK>Но есть ли нормальная замена union-типам? Все делать на классах?
А им требуется замена? По мне, это в чистом виде антипаттерн, к которому следует относится с большой осторожностью. Потеря абстракции и завязка на реализацию в обмен на сомнительное удобство обращения к переменным. Добавил одно поле — и надо править еще N классов и модулей, где этот тип используется, такого ада даже в языке С двадцать лет назад в эпоху расцвета процедурного программирования не было.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
ARK>>Но есть ли нормальная замена union-типам? Все делать на классах?
LP>А им требуется замена? По мне, это в чистом виде антипаттерн, к которому следует относится с большой осторожностью.
Ну, например, возврат из функции — ошибки либо нормального результата.
LP>Добавил одно поле — и надо править еще N классов и модулей, где этот тип используется, такого ада даже в языке С двадцать лет назад в эпоху расцвета процедурного программирования не было.
Это как раз преимущество — не забудешь, где еще не исправил. Юнионы — закрытые иерархии, а классы — наоборот открытые.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, LaPerouse, Вы писали:
ARK>>>Но есть ли нормальная замена union-типам? Все делать на классах?
LP>>А им требуется замена? По мне, это в чистом виде антипаттерн, к которому следует относится с большой осторожностью. ARK>Ну, например, возврат из функции — ошибки либо нормального результата.
Возвращать код ошибки — это прошлый век. Для ошибок есть исключения.
LP>>Добавил одно поле — и надо править еще N классов и модулей, где этот тип используется, такого ада даже в языке С двадцать лет назад в эпоху расцвета процедурного программирования не было. ARK>Это как раз преимущество — не забудешь, где еще не исправил.
foo (Foo val1 val2) = val1 + val2
Добавляем в Foo третье поле val3. Конкретно в функции foo это поле НЕ используется. Но мы должны ее изменить
foo (Foo val1 val2 val3) = val1 + val2
И таких функций по всему коду — море, в разных модулях и классах.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Васильич, Вы писали:
В>И при все этом приятный синтаксис (за исключением, пожалуй, генериков).
Как по мне, дженерики ещё нормальные, а вот макросы выглядят как-то неприятно. Ну и лайфтаймы, разумеется, усложняют код.
Здравствуйте, AlexRK, Вы писали:
ARK>Чувак хочет обрабатывать нехватку памяти, а Rust ему не дает — все аллокации производятся неявно и в случае нехватки памяти делается аборт всего процесса. Хотя, как я понимаю, это больше ограничение существующих библиотек. Можно ведь и самому написать выделитель с проверкой результата. Но потом под него придется все остальное переписывать.
Аллокаторами они занимаются, вроде. По крайней мере, это есть в планах на текущий год. А с ними переписывать, по идее, придётся меньше.
Здравствуйте, LaPerouse, Вы писали:
LP>Возвращать код ошибки — это прошлый век.
Код ошибки — да, прошлый век.
Алгебраический тип — нет.
LP>Для ошибок есть исключения.
В требовательном к надежности коде исключения неприемлемы. В таких случаях что взять в качестве альтернативы union-типам?
(Хотя лично мое мнение — исключения вообще не нужны, но это уже к теме не относится.)
Ну или другой пример — передача в функции нуллабельных ссылок. Здесь какие варианты? Хардкод особого "нулла" в компиляторе, без контроля разыменования, как сейчас везде сделано?
LP>foo (Foo val1 val2) = val1 + val2 LP>foo (Foo val1 val2 val3) = val1 + val2 LP>Добавляем в Foo третье поле val3. Конкретно в функции foo это поле НЕ используется. Но мы должны ее изменить
Разумеется, мы должны ее изменить. Потому что сейчас не используется, а через месяц будет использоваться. Это уже деталь реализации — что используется, а что нет.
LP>И таких функций по всему коду — море, в разных модулях и классах.
Ну и что?
Когда мы добавляем параметр функции, у нас тоже море вызовов по всему коду, которые надо изменить.
, либо мы платим тормозами за корректность, либо заворачиваемся в unsafe даже в таких типичных местах как массивы.
Ну справедливости ради — если мы обходим коллекцию целиком через итераторы, то код будет (по крайней мере, должен быть) идентичным. Да и для доступа к "случайным" элементам поведение раста мне кажется более "удобным": определённое поведение (паника) с возможностью отключить проверки (и подчеркнув это необходимостью использовать unsafe).
Может у меня опыт не такой, но в плюсах, зачастую, вижу использование [] с асертом рядом, at доводилось видеть весьма редко.
, либо мы платим тормозами за корректность, либо заворачиваемся в unsafe даже в таких типичных местах как массивы. DE>Ну справедливости ради — если мы обходим коллекцию целиком через итераторы, то код будет (по крайней мере, должен быть) идентичным.
О чём речь? Идентичным чему?
DE>Да и для доступа к "случайным" элементам поведение раста мне кажется более "удобным": определённое поведение (паника) с возможностью отключить проверки (и подчеркнув это необходимостью использовать unsafe).
Я только за явные секции с unsafe'ом, да и вообще не только unsafe — это могут быть всякие явные монадические области и тому подобное.
DE>Может у меня опыт не такой, но в плюсах, зачастую, вижу использование [] с асертом рядом, at доводилось видеть весьма редко.
Но против дорогого преждевременного defensive programming а-ля .at
Отключаемые assert'ы на пред/пост условия, инварианты/варианты циклов и т.п. — пожалуйста. Есть кстати хорошая презентация на тему методологии assert'ов в C++ — John Lakos "Defensive Programming Done Right" (1, 2)
Здравствуйте, ELazin, Вы писали:
EL> В том же Rust строки — мутабельные. Язык, появившийся в 2015-м году имеет мутабельные строки в своей стандартной библиотеке. Жизнь людей ничему не учит.
И чем это плохо?
EL>А если я возьму для этого Rust, мне все равно придется писать unsafe код, только у меня не будет calloc и арифметики указателей и всего такого.
Во первых, почему не будет?
Во вторых, если ты напишешь библиотеку, то пользоваться ей можно будет не прибегая к unsafe и имея при этом внутри всё что хочется. Разве это плохо?
Здравствуйте, LaPerouse, Вы писали:
LP>foo (Foo val1 val2) = val1 + val2 LP>Добавляем в Foo третье поле val3. Конкретно в функции foo это поле НЕ используется. Но мы должны ее изменить LP>foo (Foo val1 val2 val3) = val1 + val2
Честно говоря, не совсем понял (псевдо?)код, но в расте это уже работает для "нормальных структур" (в том числе, внутри enum). То есть можно делать так:
Почему оно не работает для tuple-struct (Bar) — не знаю. Может недосмотр, может сознательное решение. Похоже на второе потому что проигнорировать все поля сразу можно (всё тем же ..).
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>О чём речь? Идентичным чему?
Я к тому, что если мы обходим коллекцию целиком, то не получаем аналог at для каждого элемента.
EP>Но против дорогого преждевременного defensive programming а-ля .at
Можно, конечно, поспорить на тему того насколько оно дорого, но мне всё-таки больше нравится defensive programming, чем неопределённое поведение. Хотя да, в плюсах at не использую.
Здравствуйте, DarkEld3r, Вы писали:
DE>Я к тому, что если мы обходим коллекцию целиком, то не получаем аналог at для каждого элемента.
Это понятно, но эти простые случаи не особо интересно рассматривать, так как на C++ в этом месте будет либо range-based-for, либо один из многих алгоритмов STL, которые оттестированы и отлажены, то есть выход за границы мы и так там не получим.
То есть по-хорошему это не use-case'ы для применения индексов в пользовательском коде.
EP>>Но против дорогого преждевременного defensive programming а-ля .at DE>Можно, конечно, поспорить на тему того насколько оно дорого, но мне всё-таки больше нравится defensive programming,
А мне больше нравится выделять всякие хитрые доступы по индексу в отдельный алгоритм или класс, и обкладывать их тестами и assert'ами.
Это кстати всё равно придётся делать и в языках с проверкой индексов, так как проверка помогает диагностировать только малую часть возможных багов, и например не спасёт от зацикливания или что ещё хуже неправильного результата.
Если же стоит организационная проблема с кадрами которые пишут опасный код с запутанной адресной арифметикой и т.п. и не могут его отлаживать, то да — можно и запретить некоторые опасные конструкции и выдать взамен defensive а-ля .at, но это крайняя мера, и C++ тут скорей всего не лучший выбор.
DE>чем неопределённое поведение.
Определённое но бесполезное не особо лучше-то, изначальный баг оно же не исправит, а лишь поможет его диагностировать, да и то только на стороне пользователя.
DE>Хотя да, в плюсах at не использую.
Если например индекс приходит откуда-то извне — то можно и использовать .at или подобное, но здесь проверка нужна в любом случае — это не defensive programming.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>То есть по-хорошему это не use-case'ы для применения индексов в пользовательском коде.
Индексов — нет. Просто мне кажется, что "полный проход" по "стандартной коллекции" (вектор/массив) используется, возможно, даже чаще чем обращение по индексу. То есть, это use-case более частый.
EP>А мне больше нравится выделять всякие хитрые доступы по индексу в отдельный алгоритм или класс, и обкладывать их тестами и assert'ами.
Дык, в этом плане раст никак не мешает, разве нет? Раз уж алгоритм и так хитрый, то осознанное использование отдельных методов для сознательного выбора способа "обработки" неправильных индексов сложности не добавит, как мне кажется.
EP>Определённое но бесполезное не особо лучше-то, изначальный баг оно же не исправит, а лишь поможет его диагностировать, да и то только на стороне пользователя.
Ну если поможет, то (совсем) бесполезным это поведение сложно назвать.
Здравствуйте, T4r4sB, Вы писали:
TB>А почему рядом, а не внутри?
Внутрь стандартного вектора не так просто (свой) асерт запихнуть. Не делать/оборачивать же свой контейнер ради этого.
Здравствуйте, DarkEld3r, Вы писали:
EP>>То есть по-хорошему это не use-case'ы для применения индексов в пользовательском коде. DE>Индексов — нет. Просто мне кажется, что "полный проход" по "стандартной коллекции" (вектор/массив) используется, возможно, даже чаще чем обращение по индексу. То есть, это use-case более частый.
Полностью согласен, он более частый, я бы сказал даже на порядки. Только это не доступ по индексу
EP>>А мне больше нравится выделять всякие хитрые доступы по индексу в отдельный алгоритм или класс, и обкладывать их тестами и assert'ами. DE>Дык, в этом плане раст никак не мешает, разве нет? Раз уж алгоритм и так хитрый, то осознанное использование отдельных методов для сознательного выбора способа "обработки" неправильных индексов сложности не добавит, как мне кажется.
Я о том что это придётся делать в любом случае. И пользы от подобного defensive остаётся очень мало, особенно учитывая то что выгоду он даёт только в release у конечного пользователя (без использования defensive programming, те же самые проверки происходят в debug сборках).
EP>>Определённое но бесполезное не особо лучше-то, изначальный баг оно же не исправит, а лишь поможет его диагностировать, да и то только на стороне пользователя. DE>Ну если поможет, то (совсем) бесполезным это поведение сложно назвать.
Да, совсем бесполезным не является, но и соотношение между преимуществами и недостатками своеобразное, особенно на уровне C++/Rust.
Здравствуйте, AlexRK, Вы писали:
ARK>В требовательном к надежности коде исключения неприемлемы.
Очень спорное утверждение, видимо, связанное с непониманием того, как исключения могут работать "в требовательном к надежности коде". Вы с checked exceptions в Java знакомы?
Здравствуйте, DarkEld3r, Вы писали:
DE>Здравствуйте, T4r4sB, Вы писали:
TB>>А почему рядом, а не внутри? DE>Внутрь стандартного вектора не так просто (свой) асерт запихнуть. Не делать/оборачивать же свой контейнер ради этого.
Во-первых, какого хрена его там нет изначально, смысла вылазить за индекс — никакого, ну и короче идиотизм отказываться от проверки в дебаге.
Во-вторых, у себя дома можно и поколупать стандартную библиотеку.
Здравствуйте, Baudolino, Вы писали:
ARK>>В требовательном к надежности коде исключения неприемлемы. B>Очень спорное утверждение, видимо, связанное с непониманием того, как исключения могут работать "в требовательном к надежности коде".
Это утверждение, которое вполне подтверждается практикой. Все распространенные операционные написаны на С. Софт для марсохода написан на С. Многие программы, связанные с авиакосмической отраслью, написаны на SPARK: http://www.adacore.com/customers. (Правда, на Аде тоже пишут, и одна из космических катастроф — Ариан 5 — была вызвана необработанным исключением.) Игры на приставках тоже в основном пишутся без использования исключений (по заявлению одного игродела).
B>Вы с checked exceptions в Java знакомы?
Кое-что слышал об этом. А вы с RuntimeException в Java знакомы?
Здравствуйте, AlexRK, Вы писали:
ARK>Игры на приставках тоже в основном пишутся без использования исключений (по заявлению одного игродела).
Об играх разговор особый. В играх можно считать, что все операции всегда заканчиваются успешно, ресурсов всегда хватает, файлы всегда открываются, етс. В играх вообще исключительных ситуаций не бывает, поэтому их обрабатывать не нужно. А если какая-нибудь исключительная ситуация всё-таки произойдёт, то игра может просто упасть, и ничего страшного, это-же просто игра! Поэтому я бы не стал считать игроделов авторитетными источниками в вопросах надёжности кода.
Здравствуйте, uncommon, Вы писали:
ARK>>Игры на приставках тоже в основном пишутся без использования исключений (по заявлению одного игродела).
U>Об играх разговор особый. В играх можно считать, что все операции всегда заканчиваются успешно, ресурсов всегда хватает, файлы всегда открываются, етс. В играх вообще исключительных ситуаций не бывает, поэтому их обрабатывать не нужно. А если какая-нибудь исключительная ситуация всё-таки произойдёт, то игра может просто упасть, и ничего страшного, это-же просто игра! Поэтому я бы не стал считать игроделов авторитетными источниками в вопросах надёжности кода.
Да, согласен. Про приставки я сказал "до кучи". Источник, на который я ссылался, утверждал, что включение исключений дает до 30% пенальти производительности.
Здравствуйте, AlexRK, Вы писали:
ARK>Да, согласен. Про приставки я сказал "до кучи". Источник, на который я ссылался, утверждал, что включение исключений дает до 30% пенальти производительности.
Я бы с ним не согласился. Особенно, когда известно, что на x64, например, исключения имеют нулевой overhead.
Здравствуйте, uncommon, Вы писали:
ARK>>Да, согласен. Про приставки я сказал "до кучи". Источник, на который я ссылался, утверждал, что включение исключений дает до 30% пенальти производительности. U>Я бы с ним не согласился. Особенно, когда известно, что на x64, например, исключения имеют нулевой overhead.
Там речь шла про приставки прошлого поколения — PS3 и Xbox 360, которые не x86. Возможно, на текущем поколении положение дел изменилось.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, Baudolino, Вы писали:
ARK>>>В требовательном к надежности коде исключения неприемлемы. B>>Очень спорное утверждение, видимо, связанное с непониманием того, как исключения могут работать "в требовательном к надежности коде".
ARK>Это утверждение, которое вполне подтверждается практикой.
Помимо перечисленного вами софта есть еще десятки тысяч приложений, не менее критичных к надежности данных, но при этом не связанных ограничениями по рабочему окружению, характерными для операционок и космических систем. Например, большая часть финансового софта написана на Java. Код, написанный на Java, обрабатывает транзакций на триллион долларов ежедневно, и, поверьте мне, он должен быть не менее надежным, чем код прошивки марсохода, потому что один сбой в какой-нибудь биржевой или банковской системе может стоить её пользователям больше, чем военный спутник.
Но это в общем-то не важно: даже если бы надежных систем, написанных на языке с исключениями, не было, доказательство примером является логической ошибкой, и вы, как программист, должны это хорошо понимать.
ARK>А вы с RuntimeException в Java знакомы?
Наличие в каком-либо языке механизмов, позволяющих писать говнокод, не доказывает того, что исключения — зло, и лучше бы их не придумывали.
Это доказывает лишь то, что на Java, так же как и на С или С++ можно написать ужасный говнокод, потому что при проектировании языка были выбраны неудачные решения.
B>>Вы с checked exceptions в Java знакомы? ARK>Кое-что слышал об этом.
Замечательно. Тогда вы наверное знаете, что это вид исключений, подлежащий обязательному декларированию в сигнатуре метода.
А теперь давайте посмотрим на код:
T1 fn1(P... args) throws E { ... }
/* без обработки ошибки */
T2 fn2(P... args) throws E {
...
return new T2(fn1(args));
}
/* с обработкой ошибки */
Optional<T1> fn3(P... args) {
try {
return Optional.of(fn1(args));
} catch (E ex) {
log.error("error in fn1", ex);
return Optional.empty();
}
}
Немного изменим запись, сохранив логику реализации:
(T1|E) fn1(P... args) { ... }
(T2|E) fn2(P... args) {
var x = fn1(args);
x match
case T1 : return new T2(x);
case E : {
return x;
}
}
Optional<T1> fn3(P... args) {
var x = fn1(args);
x match
case T1 : return Optional.of(x);
case E : {
log.error("error in fn1", x);
return Optional.empty();
}
}
Ничего не напоминает?
Checked exceptions это эквивалент использования union types для обработки ошибок с синтаксическим сахаром (просто сравните реализацию fn2 в обоих случаях).
Не более того. Разница с unchecked exceptions состоит в том, что пользователь API здесь может не ждать сюрпризов и утечек абстракции, помимо того, что уже объявлено в сигнатуре, и он обязан либо обработать ошибку, либо задекларировать её и делегировать обработку на уровень выше. Проблемы той же Java, связанные с исключениями, связаны с тем, что во-первых в языке присутствуют unchecked exceptions, а во-вторых в стандартной библиотеке есть общий базовый класс для checked exceptions, с помощью которого в говнокоде постоянно утекают абстракции через throws Exception.
Здравствуйте, Baudolino, Вы писали:
B>Проблемы той же Java, связанные с исключениями, связаны с тем, что во-первых в языке присутствуют unchecked exceptions, а во-вторых в стандартной библиотеке есть общий базовый класс для checked exceptions, с помощью которого в говнокоде постоянно утекают абстракции через throws Exception.
Периодически встречал заявления, что checked exceptions в джаве — это была неудачная идея. Я лично далёк от джава-мира так что интересно насколько эти идеи общепринятые. Во многих проектах они используются? Как себя в этом плане стандартная библиотека ведёт?
Most of the onboard autonomous driving software on MER and MSL is written in C++:
Dense Stereo Vision
Autonomous Terrain Assessment
Local and Global Waypoint Planning
Multi-sol Driving
Visual Odometry
Slip Checks
Keepout Zone Prediction
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, AlexRK, Вы писали:
ARK>>Софт для марсохода написан на С.
EP>Многое
YouTube 1:04:20 — no exceptions, no multiple inheritance, no RTTI, динамическое выделение памяти только в модуле управления движением по поверхности. Что используют: namespaces, operator overloading, одиночное наследование, системы статического анализа, команду из сотни тестеров.
Здравствуйте, Baudolino, Вы писали:
B>Но это в общем-то не важно: даже если бы надежных систем, написанных на языке с исключениями, не было, доказательство примером является логической ошибкой, и вы, как программист, должны это хорошо понимать.
Разговор начался с того, что мой собеседник заявил о ненужности union-типов, мотивируя это тем, что возвращать ошибки надо всегда с помощью исключений. ОК, пусть пример в качестве обоснования не подходит. В таком случае надо вернуться на шаг назад и доказать, что исключения могут заменить union-типы _всегда_ (и, как вы понимаете, это доказательство должен делать не я).
B>Checked exceptions это эквивалент использования union types для обработки ошибок с синтаксическим сахаром (просто сравните реализацию fn2 в обоих случаях). B>Не более того. Разница с unchecked exceptions состоит в том, что пользователь API здесь может не ждать сюрпризов и утечек абстракции, помимо того, что уже объявлено в сигнатуре, и он обязан либо обработать ошибку, либо задекларировать её и делегировать обработку на уровень выше.
Да, так и есть.
B>Проблемы той же Java, связанные с исключениями, связаны с тем, что во-первых в языке присутствуют unchecked exceptions, а во-вторых в стандартной библиотеке есть общий базовый класс для checked exceptions, с помощью которого в говнокоде постоянно утекают абстракции через throws Exception.
Верно. ИМХО, только лишь наличие checked exceptions не делает язык предсказуемым, необходимо одновременное отсутствие unchecked. Поэтому Java в качестве надежного языка у меня вызывает некоторые сомнения. Да еще и сборщик мусора...
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Многое на C++
Да, верно. Что-то я не увидел это в прошлой презентации. Очень рискованное решение, однако.
Но:
So we limited our code to “Embedded C++” constructs
Exceptions: none
Templates: none
Iostream: none
Multiple inheritance: none
Operator overloading: almost none (only “new” and “delete”).
Dynamic Allocation: Guarantee no system heap corruption using a dedicated memory pool and Placement New.
Хе-хе.
Так что в контексте исключений замена C на С++ в данном случае ничего не изменила.
Здравствуйте, AlexRK, Вы писали:
ARK>Очень рискованное решение, однако.
Почему? По сравнению с чем?
ARK>Но:
Да, видел.
ARK>
ARK>Templates: none
Шаблоны не используют из-за определённых предубеждений, о чём он и сказал в видео — мол нужно убедить многих.
ARK>Так что в контексте исключений замена C на С++ в данном случае ничего не изменила.
В контексте исключений — исключения реализуются и на C, например через setjmp+longjmp — поэтому о том и речь, смотреть нужно на используемые в коде механизмы, а не на язык
Здравствуйте, Evgeny.Panasyuk, Вы писали:
ARK>>Очень рискованное решение, однако. EP>Почему? По сравнению с чем?
Много граблей, избыточного хлама, вообще язык слишком велик (чем больше язык, тем сложнее создать инструменты статического анализа и тем меньше доверия к ним, да и к компиляторам тоже).
По сравнению с более простыми и/или последовательными языками (Ц или даже Оберон ).
EP>Шаблоны не используют из-за определённых предубеждений, о чём он и сказал в видео — мол нужно убедить многих.
В презентации написано, что из-за распухания кода.
ARK>>Так что в контексте исключений замена C на С++ в данном случае ничего не изменила. EP>В контексте исключений — исключения реализуются и на C, например через setjmp+longjmp — поэтому о том и речь, смотреть нужно на используемые в коде механизмы, а не на язык
Насколько мне известно, исключений там нет ни в каком виде.
Здравствуйте, AlexRK, Вы писали:
ARK>вообще язык слишком велик
Можно ограничить подмножество — что собственно они и сделали. Причём на запретные конструкции элементарно делается верификатор.
ARK>чем больше язык, тем сложнее создать инструменты статического анализа
Отчасти да, но "статический анализ" можно делать и в самом языке, через систему типов, что проще внешнего анализатора.
Например единицы измерений и размерности довольно просто реализуются внутри C++. Для C же (или другого "простого" языка) пришлось бы писать внешний анализатор, либо и вовсе не делать такой анализ, что и произошло с Mars Climate Orbiter:
Due to complications arising from human error, the spacecraft encountered Mars at a lower than anticipated altitude and disintegrated due to atmospheric stresses. Mars Reconnaissance Orbiter has since completed most of the intended objectives for this mission.
...
The primary cause of this discrepancy was that one piece of ground software supplied by Lockheed Martin produced results in a United States customary unit ("American"), contrary to its Software Interface Specification (SIS), while a second system, supplied by NASA, that used those results expected them to be in metric units, in accord with the SIS. Software that calculated the total impulse produced by thruster firings calculated results in pound-seconds. The trajectory calculation used these results to correct the predicted position of the spacecraft for the effects of thruster firings. This software expected its inputs to be in newton-seconds.
EP>>Шаблоны не используют из-за определённых предубеждений, о чём он и сказал в видео — мол нужно убедить многих. ARK> ARK>В презентации написано, что из-за распухания кода.
Он в конце так и сказал (1:22:11) — мол я был бы рад их использовать, нет технических проблем, но трудно убедить остальных, так как у многих есть предубеждения насчёт распухания кода.
ARK>>>Так что в контексте исключений замена C на С++ в данном случае ничего не изменила. EP>>В контексте исключений — исключения реализуются и на C, например через setjmp+longjmp — поэтому о том и речь, смотреть нужно на используемые в коде механизмы, а не на язык ARK>Насколько мне известно, исключений там нет ни в каком виде.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
ARK>>вообще язык слишком велик EP>Можно ограничить подмножество — что собственно они и сделали. Причём на запретные конструкции элементарно делается верификатор.
ИМХО, подмножество все равно вышло слишком большое. Все эти хитрые правила приведения типов, правила перегрузок, возможность привести что угодно к чему угодно, неопределенное поведение...
EP>Отчасти да, но "статический анализ" можно делать и в самом языке, через систему типов, что проще внешнего анализатора.
Что-то можно конечно, но вещи посложнее, типа контроля границы массивов — это вряд ли уже. Внешний анализатор все равно нужен.
EP>Для C же (или другого "простого" языка) пришлось бы писать внешний анализатор, либо и вовсе не делать такой анализ, что и произошло с Mars Climate Orbiter:
Да, тут опростоволосились.
ARK>>>>Так что в контексте исключений замена C на С++ в данном случае ничего не изменила. EP>>>В контексте исключений — исключения реализуются и на C, например через setjmp+longjmp — поэтому о том и речь, смотреть нужно на используемые в коде механизмы, а не на язык ARK>>Насколько мне известно, исключений там нет ни в каком виде.
EP>* Exceptions in C with Longjmp and Setjmp EP>* Exception Handling in C without C++
Да не, я понимаю, что в С исключения можно эмулировать. Я говорю, что в марсоходе их нет.
Здравствуйте, AlexRK, Вы писали:
ARK>В таком случае надо вернуться на шаг назад и доказать, что исключения могут заменить union-типы _всегда_ (и, как вы понимаете, это доказательство должен делать не я).
Исключения не могут заменить union-типы всегда — это легко проиллюстрировать примером, в котором union-тип используется для ветвления кода в стеке вызовов:
(R1|R2|R3) fn1(P... params) { ... }
void fn2(P... params) {
var x = fn1(params)
x match
case R1 : doSomething1(x)
case R2 : doSomething2(x)
case R3 : doSomething3(x)
return x
}
В этом примере все типы возвращаемого значения равнозначны и не являются ошибкой, поэтому, хотя исключения могут смоделировать аналогичное поведение, использовать их будет здесь семантически некорректно. Однако, та же задача может быть решена и другими способами, например, в данном случае хорошо подходит полиморфизм.
Это не стоит считать доказательством, а скорее это направление, в котором можно двигаться, чтобы получить такое доказательство.
ARK>Верно. ИМХО, только лишь наличие checked exceptions не делает язык предсказуемым, необходимо одновременное отсутствие unchecked. Поэтому Java в качестве надежного языка у меня вызывает некоторые сомнения. Да еще и сборщик мусора...
Надёжных языков не бывает, бывают программисты, которые пишут надёжный код, и тот — в рамках заданных допущений. Как бы язык не старался нас защитить, всегда будет возможность написать программу, в которой будут утечки памяти (как это произошло с долгоживущими коллекциями в Java), неожиданные блокировки в многопоточных программах и другие трудноуловимые сбои — все эти проблемы просто переезжают на другой уровень абстракции, на котором синтаксис и семантика языка уже не работают.
Здравствуйте, DarkEld3r, Вы писали:
DE>Периодически встречал заявления, что checked exceptions в джаве — это была неудачная идея. Я лично далёк от джава-мира так что интересно насколько эти идеи общепринятые. Во многих проектах они используются? Как себя в этом плане стандартная библиотека ведёт?
В Java-мире нет консенсуса на этот счет. В стандартной библиотеке есть много checked-исключений, часто они используются и в прикладном коде. Мне лично нравится идея декларировать контракты методов полностью, включая возможные ошибки. На мой взгляд, единственная проблема, которая с ними реально есть, это отсутствие generic-исключений:
Сейчас такой код написать нельзя, поэтому либо Consumer будет бросать общий суперкласс всех исключений, что выглядит отвратительно, либо нужно писать try-catch в лямбде, что ухудшает читаемость кода.
Здравствуйте, kaa.python, Вы писали:
KP>Тот, кому важны микросекунды – C++ тоже не возьмет по причине слишком больших накладных расходов в виде обработки исключений, подсчете ссылок и т.д. Посмотри на тесты скорости: в 50% случаев Rust обгоняет C++, в 30% обгоняет C и это без unsafe.
Посмотрел не первый тест. Раст обгоняет обгоняет С++ только потому что код теста многопоточный, а С++-код однопоточный. С Раст действительно обошел немного, но думаю дело или в многопоточности или в выделении памяти.
Однопоточный вариант ~ на секунду отстает от С++ (т.е. на 20%) и на 1.5 от С.
И (сюрприз!) почти на секунду отстает от моновского C#. Но это уже с жельничаю. Этот тест тоже сногопоточный.
Зато Java на доли секунды, но все же, обогнала Раст в однопоточном варианте.
Так почему ты не делаешь вывод, что Ява вполне себе замена всем этим навомодным языкас и С++ в придачу?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Посмотрел не первый тест. Раст обгоняет обгоняет С++ только потому что код теста многопоточный, а С++-код однопоточный. С Раст действительно обошел немного, но думаю дело или в многопоточности или в выделении памяти.
Тесты конкретно на Alioth'е для Раста сделаны не очень правильно.
У нас есть реализация TLS на Rust — она обгоняет по скорости OpenSSL'ную (которая на С) и при этом внутри ещё и безопасна. Все unsafe-операции сосредоточены на периметре.
Здравствуйте, kaa.python, Вы писали:
KP>Она была бы отличной заменой C++, будь JVM установлена на компьютерах по умолчанию или весила бы не 150-250 Мб в зависимости от платформы.
Какие проблемы, в наше время, скачать ~60 мег (размер JRE)? Сейчас и сотни мег не проблема. С Явой как раз очень удобно получается, каждое приложение может нести рантайм (возможно урезанный) с собой. Большинство значимых расширений для Эклипса, например, предлагаются (в том числе) и в виде архива включающего Эклипс, сам плагин к нему и JRE. Остается только скопировать на винт и запустить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Какие проблемы, в наше время, скачать ~60 мег (размер JRE)? Сейчас и сотни мег не проблема.
Зависит от того, что ты пишешь. У нас все (или почти все) продукты на писаны на C++ (Maya, 3D Max, ACAD и т.д.). Мы пишем один из компонентов, общий для всех продуктов. Если мы его попытаемся выкатить в виде "вот вам компонент, а вот это рантайм для него", не нужно быть предсказателем что бы понять куда нас пошлют.
Поэтому, в ряде случаев, писать на языке не требующем большого рантайма более чем оправданно.
Если же подходить к вопросу философски, то мой выбор языков для проекта идет по цепочке Python -> Java -> C++.
Здравствуйте, kaa.python, Вы писали:
KP>Зависит от того, что ты пишешь. У нас все (или почти все) продукты на писаны на C++ (Maya, 3D Max, ACAD и т.д.). Мы пишем один из компонентов, общий для всех продуктов. Если мы его попытаемся выкатить в виде "вот вам компонент, а вот это рантайм для него", не нужно быть предсказателем что бы понять куда нас пошлют.
3D Max и Автокад — это сугубо телескопные, причем виндовые приложения. Для них сам бог велел использовать донет в качестве расширений.
Вы там совсем развлечениями занимаетесь, если пытаетесь плагины к этим продуктам на Go писать.
Включить в состав плагина JRE или его огрызок тоже никаких проблем не составит.
KP>Поэтому, в ряде случаев, писать на языке не требующем большого рантайма более чем оправданно.
Это зависит только от того насколько сложный плагин и что в нем делать надо. Если это что-то простенькое — несомненно. Если кода много, то разговоры про рантаймы смешы.
Дотнет, вообще, является частью ОС. Если писать в расчете на 4.0, то работать будет практически везде. Да и в автомате проинсталлировать можно.
KP>Если же подходить к вопросу философски, то мой выбор языков для проекта идет по цепочке Python -> Java -> C++.
Попробуй Nemerle и Scvala. Если освоишь, потом от Python и Java совсем плеваться будешь. Да и от C++, тоже. Для твоих задач оба языка оптимальны. Ну, плюсы для числодробильных вычислений возможно понадобятся, но их не сложно включить в проекты.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>3D Max и Автокад — это сугубо телескопные, причем виндовые приложения. Для них сам бог велел использовать донет в качестве расширений.
У ACAD есть версия для OSX. Есть чисто линуксовые продукты. Мы пишем компонент для всех них
VD>Вы там совсем развлечениями занимаетесь, если пытаетесь плагины к этим продуктам на Go писать.
Не, не плагин. Неотемлимую часть всех автодесковких продуктов
VD>Дотнет, вообще, является частью ОС. Если писать в расчете на 4.0, то работать будет практически везде. Да и в автомате проинсталлировать можно.
Да кого интересует Windows-only решение?
VD>Попробуй Nemerle и Scvala. Если освоишь, потом от Python и Java совсем плеваться будешь. Да и от C++, тоже. Для твоих задач оба языка оптимальны. Ну, плюсы для числодробильных вычислений возможно понадобятся, но их не сложно включить в проекты.
Scvala – это Scala я полагаю. Пробовал, не понравилось. Эдакий C++ для JVM с элементами Perl в области написания одноразового (в том смысле что через пару месяцев не поймешь что нагорожено) кода. От Nemerle плеваться начинаю даже не начав осваивать – это ж я что, должен венду ставить или с Mono сексом заниматься? Увольте
Здравствуйте, kaa.python, Вы писали:
KP>Да кого интересует Windows-only решение?
Перечисленные тобой продукты и есть Windows-only. Ну разве что ACAD (это автокад?) на ACAD портировали. Я даже не знал об этом.
KP>Scvala – это Scala я полагаю. Пробовал, не понравилось. Эдакий C++ для JVM с элементами Perl в области написания одноразового (в том смысле что через пару месяцев не поймешь что нагорожено) кода.
Ты явно смотрел краем глаза и увидел что-то не то. В Скале, конечно, много накручено. Но язык очень добротный. В нем есть все что нужно для жизни. Просто изучи его как следует и изменишь мнение.
KP>От Nemerle плеваться начинаю даже не начав осваивать – это ж я что, должен венду ставить или с Mono сексом заниматься? Увольте
Ну, плеваться не читай — это не о языке, а о тебе. Надеюсь ты это понимаешь.
Далее, делая продукты для "венды" не ставить "венду" довольно странно. Экзотично, я бы сказал.
С Mono особых проблем тоже нет. И немерл с ним работает.
Сейчас еще есть два варианта:
1. Core CLR.
2. .NET Native.
Области новые и несомненно по трахаться с ними придется, но независимость, в итоге, будет хорошая.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Перечисленные тобой продукты и есть Windows-only. Ну разве что ACAD (это автокад?) на ACAD портировали. Я даже не знал об этом.
У меня таки есть подозрение, что работая в Автодеске я лучше знаю о том, какие из наших продуктов Windows-only, а какие нет
VD>Ты явно смотрел краем глаза и увидел что-то не то. В Скале, конечно, много накручено. Но язык очень добротный. В нем есть все что нужно для жизни. Просто изучи его как следует и изменишь мнение.
Может про Scala я и не прав и стоит посмотреть на него еще раз. У меня пока что ощущение того, что слишком уж он наверченный.
VD>Ну, плеваться не читай — это не о языке, а о тебе. Надеюсь ты это понимаешь.
Да, Влад, я понимаю. В первую очередь то, что "одноплатформенный" язык в 2016 – это мусор. Именно поэтому я даже не пытаюсь начать использовать довольно прикольный Swift. Хотя он просто отличная замена Python мог бы оказаться (и может и окажется).
VD>Далее, делая продукты для "венды" не ставить "венду" довольно странно. Экзотично, я бы сказал.
У нас продукты на всех платформах. На работе никто не будет использовать язык который не позволит написать компонент для всех них разом. А дома у меня нет и не будет Windows, очень уж убога ОС, а уж лицензионное соглашение 10-ки вообще за гранью добра и зла.
VD>С Mono особых проблем тоже нет. И немерл с ним работает.
Мы недавно на практике узнали как же это выглядит – нет проблем с Mono. Некие умники догадались написать сервис на C# (.NET 3.5) Все шло хорошо до тех пор, пока клиенты не захотели этот же сервис, но на Linux, что логично, так как сервера на Windows прошлый век. И тут выяснилось, что пока его изрядно не переписали ничего не работало, так как далеко не все что есть даже в столь дремучем .NET реализовано в последнем Mono. А если реализовано, то работает так же как и в .NET.
VD>Области новые и несомненно по трахаться с ними придется, но независимость, в итоге, будет хорошая.
KP>Мы недавно на практике узнали как же это выглядит – нет проблем с Mono. Некие умники догадались написать сервис на C# (.NET 3.5) Все шло хорошо до тех пор, пока клиенты не захотели этот же сервис, но на Linux, что логично, так как сервера на Windows прошлый век. И тут выяснилось, что пока его изрядно не переписали ничего не работало, так как далеко не все что есть даже в столь дремучем .NET реализовано в последнем Mono. А если реализовано, то работает так же как и в .NET.
А что вы хотите? Это же опенсурс. Программисты пишут для себя, если повезёт, то и другие смогут пользоваться после доработки напильником. Закиньте несколько PR на моно, и у вас всё получится.
Кстати, в линуксе вэйланд допили? Или до сих пор заплатки на экс-окна лепят?
Здравствуйте, red75, Вы писали:
R>А что вы хотите? Это же опенсурс. Программисты пишут для себя, если повезёт, то и другие смогут пользоваться после доработки напильником. Закиньте несколько PR на моно, и у вас всё получится.
Лично я ничего не хочу. Просто объясняю что стереотип "если написали на .NET, то возьмите Mono и будет работать везде" – это не более чем дремучее заблуждение.
R>Кстати, в линуксе вэйланд допили? Или до сих пор заплатки на экс-окна лепят?
Не знаю, если честно. Я в качестве основной системы обычно OS X использую и проблемы Linux за пределами командной строки меня мало волнуют
Здравствуйте, DarkEld3r, Вы писали:
B>>Проблемы той же Java, связанные с исключениями, связаны с тем, что во-первых в языке присутствуют unchecked exceptions, а во-вторых в стандартной библиотеке есть общий базовый класс для checked exceptions, с помощью которого в говнокоде постоянно утекают абстракции через throws Exception. DE>Периодически встречал заявления, что checked exceptions в джаве — это была неудачная идея. Я лично далёк от джава-мира так что интересно насколько эти идеи общепринятые.
Практически общепринятые.
DE>Во многих проектах они используются?
Если речь про библиотеки — используются крайне редко. Я сходу не припомню популярную библиотеку с Checked Exceptions.
DE>Как себя в этом плане стандартная библиотека ведёт?
99% стандартной библиотеки было написано давно, когда эту идею считали хорошей, поэтому там есть Checked Exceptions. Основные, с которыми приходится сталкиваться это IOException, SQLException. В Java 8 ввели класс RuntimeIOException, который наследуется от RuntimeException и "оборачивает" IOException. В Java 8 нет никаких способов использовать Checked Exceptions со стандартными функциями, принимающими лямбды. Хотя могли бы что-нибудь придумать для их поддержки. Но не стали.
В общем мой вердикт — в Java проверяемые исключения неофициально и официально признаны неудачной идеей. Не удивлюсь, если в какой-нибудь следующей Java их просто уберут из языка. Обратную совместимость это не сломает.
Здравствуйте, Васильич, Вы писали:
В>Гарантии безопасной работы с памятью, большей частью на этапе компиляции;
Мдя, я на этих гарантиях сдался походу. Любая попытка сделать более-менее гибкую архитектуру, которая не сваливается в бесконечный рефакторинг при любом изменении, приводит тупо к обмазыванию всего и вся в Rc<RefCell>. А это нифига не этап компиляции так-то.
Здравствуйте, T4r4sB, Вы писали:
В>>Гарантии безопасной работы с памятью, большей частью на этапе компиляции; TB>Мдя, я на этих гарантиях сдался походу. Любая попытка сделать более-менее гибкую архитектуру, которая не сваливается в бесконечный рефакторинг при любом изменении, приводит тупо к обмазыванию всего и вся в Rc<RefCell>. А это нифига не этап компиляции так-то.
Это значит, что выбрана неверная архитектура.
Вот ты на Rust откуда перешёл? Если с C++, то просто представь себе, как бы ты писал на C++ этот же проект, естественно максимально соблюдая правильный современный стиль C++. И далее просто переведи эту архитектуру на Rust. И если в какой-то точке проекта для этого потребуется вставить одну unsafe строчку, то это будет абсолютно нормально. И даже более канонично для Rust, чем плодить ненужные рантайм проверки в стиле управляемых языков.
Самая большая проблема C++, что многие его свойства были обнаружены случайно
и получили дальше какое-то дальнейшее развитие. Язык развивался эволюционным путём
фактически. И в какой-то момент следовало бы откинуть всё и начать с начала.
Перво-наперво C++ это не единый язык, как другие языки. Это по меньшей мере
два языка работающих с разными абстракциями и в разное время. Один из них -- "C с классами",
мало чем отличается от других языков, того же Rust. И даже уступает им. Но вся соль
в другом, в декларативном языке работающем в пространстве типов в момент компиляции.
В том, что ошибочно считают шаблонами. Проблема лишь в том, что этот второй язык возник
случайно, имеет массу ограничений, дефектов и неожиданных свойств.
Здравствуйте, Васильич, Вы писали:
В>Это очень показательный пример, когда человек, привыкший к необдуманному кодингу, сталкивается с растом. Тут важно запомнить одно: сильнейшая сторона Rust'а в его строгости,
Нет, здесь Rust ничем не отличается от голого C и подобных языков.
C++ в отличии от может знать правила преобразования типов и применять их автомагически.
Либо требовать так же вписывать reinterpret_cast с неизвестным результатом.
Здравствуйте, ELazin, Вы писали:
В>>У Rust'а: В>>Продвинутая система модулей; EL>В С++ тоже скоро будет.
Не нужна. Что она даёт? Кроме того, что хедеры теперь будут идти в блобах. Время компиляции?
Это не та проблема. Будет как в C#, когда у них тоже "модули", но рядышком лежать те же
недохедеры (в студии по F11, вроде, вызываются). Хуже того, масса кода требует перекомпиляции
каждый раз и может параметром воспринимать значения макросов, наличие и свойста типов в неймспейсах
и т.п. Модули имеют узкое применение, интерфейс к сторонней библиотеке, например.
В>>C++ имеет похожие возможности в некоторых областях, но при этом не дает никаких гарантий. EL>Что значит "не дает гарантий"? Какие гарантии дает язык? У С++ есть стандарт, поэтому я могу точно сказать как должен вести себя тот или иной фрагмент кода. Стандарт определяет некоторые вещи как UB (undefined behaviour)
А в следующей версии Rust всё будет шиворот-навыворот, вот тебе и "гарантии".
Как начинать какой-то проект с Rust, если он не будет собираться завтрашним компилятором, а сегодняшний
окажется устаревшим и неподдерживаемым.
Здравствуйте, AlexRK, Вы писали:
ARK>>>В требовательном к надежности коде исключения неприемлемы. B>>Очень спорное утверждение, видимо, связанное с непониманием того, как исключения могут работать "в требовательном к надежности коде".
ARK>Это утверждение, которое вполне подтверждается практикой. Все распространенные операционные написаны на С. Софт для марсохода написан на С.
Дада, у них там вместо исключтений -- longjmp. Дальше можно не продолжать...
Здравствуйте, fk0, Вы писали:
fk0> Одно и сомнительное -- borrow checker. Сомнительное, потому, что идея fk0>хоть интересная, но сырая.
А ещё более-менее вменяемый дизайн без косорылых несимметричностей, а ещё более простой способ скачивать модули, а ещё возможность любой тип распечатать без ручного перечисления полей, а ещё комплиятор выдаёт куда более вменяемые ошибки, чем кусок кала под названием Govno Compiler Collection
