Сообщение Re[9]: Rust vs C++ 17 от 09.01.2016 21:25
Изменено 09.01.2016 21:40 red75
Здравствуйте, 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-кода.
Tooling, конечно, у с++ лучше. Даже gbd уже года 3 показывает правильные значения переменных http://stackoverflow.com/questions/10315430/gdb-prints-wrong-values
А то что я писал про свою программку на Rust это не wishful thinking, а простое следствие того, что статический анализатор встроен в Rust.
Если выразить инварианты программы на уровне типов, то успешность компиляции будет гарантировать успешность работы. Я, конечно, до такого уровня не дошёл, но по крайней мере могу быть достаточно уверен, что ошибка не вызвана buffer overrun в какой-нибудь отдалённой части программы или кривой библиотеке.
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-кода.
Tooling, конечно, у с++ лучше. Даже gbd уже года 3 показывает правильные значения переменных http://stackoverflow.com/questions/10315430/gdb-prints-wrong-values
А то что я писал про свою программку на Rust это не wishful thinking, а простое следствие того, что статический анализатор встроен в Rust.
Если выразить инварианты программы на уровне типов, то успешность компиляции будет гарантировать успешность работы. Я, конечно, до такого уровня не дошёл, но по крайней мере могу быть достаточно уверен, что ошибка не вызвана buffer overrun в какой-нибудь отдалённой части программы или кривой библиотеке.
Здравствуйте, 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-кода.
Tooling, конечно, у с++ лучше. Даже gbd уже года 3 показывает правильные значения переменных http://stackoverflow.com/questions/10315430/gdb-prints-wrong-values
А то что я писал про свою программку на Rust это не wishful thinking, а простое следствие того, что статический анализатор встроен в Rust.
Если выразить инварианты программы на уровне типов, то успешность компиляции будет гарантировать успешность работы. Я, конечно, до такого уровня не дошёл (собственно в Rust'е это полностью и не получится. Например, там нельзя реализовать session types), но по крайней мере могу быть достаточно уверен, что ошибка не вызвана buffer overrun в какой-нибудь отдалённой части программы или кривой библиотеке.
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-кода.
Tooling, конечно, у с++ лучше. Даже gbd уже года 3 показывает правильные значения переменных http://stackoverflow.com/questions/10315430/gdb-prints-wrong-values
А то что я писал про свою программку на Rust это не wishful thinking, а простое следствие того, что статический анализатор встроен в Rust.
Если выразить инварианты программы на уровне типов, то успешность компиляции будет гарантировать успешность работы. Я, конечно, до такого уровня не дошёл (собственно в Rust'е это полностью и не получится. Например, там нельзя реализовать session types), но по крайней мере могу быть достаточно уверен, что ошибка не вызвана buffer overrun в какой-нибудь отдалённой части программы или кривой библиотеке.