Здравствуйте, WolfHound, Вы писали:


Pzz>>Управляемые языки исключают некоторые классы ошибок (например, обращение по невалидному указателю или за пределами массива), совсем никак не исключая других классов ошибок (например, использование некорректных алгоритмов).
WH>Это зависит. Если говорить по жабу и .НЕТ то да. А если почистить систему типов и добавить зависимые типы то там можно и некорректные алгоритмы отлавливать. Пусть и ни на 100% но юнит тесты можно списать в утиль с чистой совестью.

А можно подробнее или где об этом почитать?
Речь случайно не о фантомных типах O'Caml/F#/... ? http://till-varoquaux.blogspot.com/2007/06/phun-with-phantom-types.html ?

Здравствуйте, WolfHound, Вы писали:

WH>Это зависит. Если говорить по жабу и .НЕТ то да. А если почистить систему типов и добавить зависимые типы то там можно и некорректные алгоритмы отлавливать. Пусть и ни на 100% но юнит тесты можно списать в утиль с чистой совестью.

Можно отлавливать алгоритмы, у которых "вилка не подошла к розетке". Но как вы поймаете, с помощью какой угодно системы типов, ситуацию, когда вам, грубо говоря, надо было взять среднее квадратичное, а вы взяли среднее арифметическое?

Pzz>>я бы, кстати, предпочел термин "безопасные", потому что безопасный язык можно реализовать на голом железе, без всяких "управляемых" сред
WH>А что конкретно ты понимаешь под "средой"?

То, что находится между программой и операционной системе, if any.

Pzz>>А пользователю вашему все равно, к какому классу относилась ошибка, убившая его файл или банковский счет, к тому, которые предотвращаются использованием "безопасных" инструментов, или к тому, которые не предотвращаются.
WH>Устранение некоторых классов ошибок == меньше ошибок при тех же усилиях.

Зато оставшиеся ошибки становятся гораздо более заковыристыми

Здравствуйте, Pzz, Вы писали:

Pzz>>>А пользователю вашему все равно, к какому классу относилась ошибка, убившая его файл или банковский счет, к тому, которые предотвращаются использованием "безопасных" инструментов, или к тому, которые не предотвращаются.
WH>>Устранение некоторых классов ошибок == меньше ошибок при тех же усилиях.

Pzz>Зато оставшиеся ошибки становятся гораздо более заковыристыми

C чего это?

Здравствуйте, criosray, Вы писали:

Pzz>>Зато оставшиеся ошибки становятся гораздо более заковыристыми

C>C чего это?

Потому что простые отсеиваются компилятором.

Здравствуйте, Pzz, Вы писали:


Pzz>>>Зато оставшиеся ошибки становятся гораздо более заковыристыми

C>>C чего это?

Pzz>Потому что простые отсеиваются компилятором.

Где логика? Как отсеивание части ошибок может делать "оставшиеся ошибки более заковыристыми"?

Здравствуйте, CreatorCray, Вы писали:

CC>Лично мне например нравится такой стиль:
CC>

CC>TreeNode *node = root.GetNode ("Foo");
CC>if (node)
CC>{
CC>}

CC>node = root.GetNode ("Bar");
CC>if (node)
CC>{
CC>}
CC>

Лучше так:

if (TreeNode* node = root.GetNode("Foo"))
{
}

if (TreeNode* node = root.GetNode("Bar"))
{
}

Сразу видно что присваивание намеренное и переменная за приделами if не светится.
Почти паттерн матчинг получается.

Здравствуйте, criosray, Вы писали:

C>А можно подробнее или где об этом почитать?
C>Речь случайно не о фантомных типах O'Caml/F#/... ? http://till-varoquaux.blogspot.com/2007/06/phun-with-phantom-types.html ?
Это сильно кастрированный частный случай.
Но там почти в самом начале есть правильная ссылка http://en.wikipedia.org/wiki/Dependent_type

Здравствуйте, Pzz, Вы писали:

Pzz>Можно отлавливать алгоритмы, у которых "вилка не подошла к розетке". Но как вы поймаете, с помощью какой угодно системы типов, ситуацию, когда вам, грубо говоря, надо было взять среднее квадратичное, а вы взяли среднее арифметическое?
Ты удивишься но это при желании тоже можно свести к "вилка не подошла к розетке".
Вопрос лишь в том насколько это критично в данной конкретной задаче.

Pzz>То, что находится между программой и операционной системе, if any.
Ты про компилятор что ли?
На самом деле грань между заранее скомпилированной программой и отJITеной программой настолько тонка что тут и говорить не о чем.

WH>>Устранение некоторых классов ошибок == меньше ошибок при тех же усилиях.
Pzz>Зато оставшиеся ошибки становятся гораздо более заковыристыми
Одно из другого не следует.

Здравствуйте, WolfHound, Вы писали:

Pzz>>Можно отлавливать алгоритмы, у которых "вилка не подошла к розетке". Но как вы поймаете, с помощью какой угодно системы типов, ситуацию, когда вам, грубо говоря, надо было взять среднее квадратичное, а вы взяли среднее арифметическое?
WH>Ты удивишься но это при желании тоже можно свести к "вилка не подошла к розетке".

Можно, но это сведение будет само по себе не простым. И станет подходящим местом, чтобы влепить туда нетривиальную ошибку

WH>На самом деле грань между заранее скомпилированной программой и отJITеной программой настолько тонка что тут и говорить не о чем.

Я сказал простую вещь: понятия "безопасного" языка и "управляемого" языка ортогональны. Можно сделать безопасный язык, который статически компилируется в машинный код, можно сделать управляемый язык, который будет небесопасен (правда, второе непонятно зачем делать). Я ничего не сказал при этом относительно связанного с JIT-ом оверхеда. Против того, что я сказал, какие-нибудь возражения по существу имеются?

WH>>>Устранение некоторых классов ошибок == меньше ошибок при тех же усилиях.
Pzz>>Зато оставшиеся ошибки становятся гораздо более заковыристыми
WH>Одно из другого не следует.

Вы получаете инструмент, позволяющий со сравнимым уровнем усилий делать более сложные конструкции. А чем сложнее конструкция, тем более заковыристую ошибку в ней можно посадить.

Здравствуйте, criosray, Вы писали:

Pzz>>Потому что простые отсеиваются компилятором.

C>Где логика? Как отсеивание части ошибок может делать "оставшиеся ошибки более заковыристыми"?

У программиста появляется больше времени делать более хитрые ошибки.

С чем вы спорите? Безопасные среды появились раньше, чем вы родились на свет. Благодаря усилиям фирмы Мелкософт они уже достаточно давно популярны. Казалось бы, глюки в софтварии давно должны исчезнуть, однако экспериментальным фактом является то, что они почему-то не исчезают. Получается парадокс, не так ли?

Здравствуйте, Pzz, Вы писали:

Pzz>>>Потому что простые отсеиваются компилятором.

C>>Где логика? Как отсеивание части ошибок может делать "оставшиеся ошибки более заковыристыми"?

Pzz>У программиста появляется больше времени делать более хитрые ошибки.

У программиста появляется больше времени НЕ делать хитрые (и не очень) ошибки.

Здравствуйте, Pzz, Вы писали:


WH>>На самом деле грань между заранее скомпилированной программой и отJITеной программой настолько тонка что тут и говорить не о чем.

Pzz>Я сказал простую вещь: понятия "безопасного" языка и "управляемого" языка ортогональны.
Глупость.
Pzz>Можно сделать безопасный язык, который статически компилируется в машинный код, можно сделать управляемый язык, который будет небесопасен (правда, второе непонятно зачем делать). Я ничего не сказал при этом относительно связанного с JIT-ом оверхеда. Против того, что я сказал, какие-нибудь возражения по существу имеются?
Ну вперед — сделайте. За 50+ лет до Вас не смогли. Удачи.

WH>>>>Устранение некоторых классов ошибок == меньше ошибок при тех же усилиях.
Pzz>>>Зато оставшиеся ошибки становятся гораздо более заковыристыми
WH>>Одно из другого не следует.

Pzz>Вы получаете инструмент, позволяющий со сравнимым уровнем усилий делать более сложные конструкции. А чем сложнее конструкция, тем более заковыристую ошибку в ней можно посадить.
То есть когда Вы получаете ТЗ от заказчика, то отбрасываете половину со словами "мы этого делать не будем — наш инструмент нам не позволяет"?

Очень смешно.

Здравствуйте, criosray, Вы писали:

Pzz>>Я сказал простую вещь: понятия "безопасного" языка и "управляемого" языка ортогональны.
C>Глупость.

Ну а обосновать?

Pzz>>Можно сделать безопасный язык, который статически компилируется в машинный код, можно сделать управляемый язык, который будет небесопасен (правда, второе непонятно зачем делать). Я ничего не сказал при этом относительно связанного с JIT-ом оверхеда. Против того, что я сказал, какие-нибудь возражения по существу имеются?
C>Ну вперед — сделайте. За 50+ лет до Вас не смогли. Удачи.

Чего сделать не смогли?

C>То есть когда Вы получаете ТЗ от заказчика, то отбрасываете половину со словами "мы этого делать не будем — наш инструмент нам не позволяет"?

Сделать по-разному можно.

Здравствуйте, criosray, Вы писали:

Pzz>>У программиста появляется больше времени делать более хитрые ошибки.

C>У программиста появляется больше времени НЕ делать хитрые (и не очень) ошибки.

Ну так и где этот безглючный софтварий, написанный с помощью современного безопасного инструментария.

Здравствуйте, Pzz, Вы писали:

Pzz>>>Я сказал простую вещь: понятия "безопасного" языка и "управляемого" языка ортогональны.
C>>Глупость.

Pzz>Ну а обосновать?
Сначала Вы.

Pzz>>>Можно сделать безопасный язык, который статически компилируется в машинный код, можно сделать управляемый язык, который будет небесопасен (правда, второе непонятно зачем делать). Я ничего не сказал при этом относительно связанного с JIT-ом оверхеда. Против того, что я сказал, какие-нибудь возражения по существу имеются?
C>>Ну вперед — сделайте. За 50+ лет до Вас не смогли. Удачи.

Pzz>Чего сделать не смогли?
Вы что же забыли что писали тремя строчками выше?
"Можно сделать безопасный язык, который статически компилируется в машинный код, можно сделать управляемый язык, который будет небесопасен (правда, второе непонятно зачем делать)."

C>>То есть когда Вы получаете ТЗ от заказчика, то отбрасываете половину со словами "мы этого делать не будем — наш инструмент нам не позволяет"?

Pzz>Сделать по-разному можно.

То есть Вы понимаете какую глупость тут сморозили?

Здравствуйте, criosray, Вы писали:

Pzz>>Ну а обосновать?
C>Сначала Вы.

Я обосновал.

Pzz>>Чего сделать не смогли?
C>Вы что же забыли что писали тремя строчками выше?
C>"Можно сделать безопасный язык, который статически компилируется в машинный код, можно сделать управляемый язык, который будет небесопасен (правда, второе непонятно зачем делать)."

LISP, Ocaml, Haskell — умеют компилироваться в машинный код и при этом безопасны.

Pzz>>Сделать по-разному можно.

C>То есть Вы понимаете какую глупость тут сморозили?

Нет, не понимаю. Объясните.

Здравствуйте, Vamp, Вы писали:

V>Кстати, человек, действительно знакомый с С++ не по-наслышке, никогда такого, что у тебя в примере не напишет. Мне, например, сразу в глаза бросилось <= — такое условие в цикле итерации не встречается никогда.
V>Ну и в последних, писать итеративные циклы в С++, где есть for_each, bind и lambda — каменный век.

Самое главное в C++ есть std::vector и возможность использовать begin/end.
<= тоже сразу бросилось в глаза.

Здравствуйте, criosray, Вы писали:

C>>>

C>>>void myFoo(int *arr, int length)
C>>>{
C>>>    for (int i = 0; i < length; i++) { 
C>>>        arr[i] = 0;
C>>>    }
C>>>}
C>const int max_length = 4;
C>>>int length; std::cin >> length;
C>>>int *arr = new int[length];
C>>>...
C>>>length++;
if(length >= max_length || length<0){...}
C>>>...
C>>>myFoo(arr, length);
C>>>

C>Давайте без самодеятельности, ок? length должно быть получено в рантайм (пользовательский ввод, или на основе какой-то логики).

В этом случае надо проверять что ввёл пользователь. И делать это надо при работе с любым языком. Пользователю всё равно, что случится — бесконечный цикл или исключение будет кинуто, ему надо объяснить, что от него требуется и дать возможность ввести данные ещё раз.

Если ты приводишь такой пример, то наверное ты так и пишешь.
В С++ не является хорошим тоном использовать голые указатели, динамические массивы, не инициализированные переменные, передача по указателю там, где не требуется.

Здравствуйте, Vamp, Вы писали:

C>>Опечатка конечно подразумевалось for (i = 0;
C>>Если Вам нравится цепляться к словам, то и я прицеплюсь к Вашим: в языке С конструкция for (int i;... синтаксически некорректна.
V>А причем тут С? В начале речь шла о С++. В С++ это более чем корректная конструкция.

И даже более того — она предпочтительнее варианта с переменной из внешнего блока видимости.

Здравствуйте, criosray, Вы писали:

C>Здравствуйте, criosray, Вы писали:


C>Попробуйте скомпиллировать данный код в VC++ любой версии и запустить.
C>Сразу скажу, что код корректен.

30 секунд, включая создание проекта и копирование кода туда