У кого еще остались сомнения в целесообразности модульных тестов, в целесообразности использования языков/платформ с большим количеством статических и динамических проверок...
Здравствуйте, criosray, Вы писали:
C>У кого еще остались сомнения в целесообразности модульных тестов, в целесообразности использования языков/платформ с большим количеством статических и динамических проверок...
Я где-то читал, что повсеместное введение автомобильных ремней безопасности не снизило количество смертей на дорогах: люди почувствовали себя "безопаснее" и стали ездить быстрее.
Точно так же введение более "безопасных" языков, инструментов и методик для написания программ не сделает их в надежнее (в том смысле, как эта надежность видна пользователям). Вместо этого программы будут писаться более небрежно, уровень квалификации программистов снизится, в надежде, что некоторая часть ошибок уйдет благодаря более безопасным инструментам.
Внедрение безопасных методик и инструментов может повысить продуктивность и качество каждого из нас, уже сложившихся программистов, но не увеличит качество индустрии в целом. Продуктивность может и увеличит, за счет снижения требований к квалификации работников.
Re[4]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Antikrot, Вы писали:
C>>Я на С++ писал не меньше, а то и побольше Вашего. A>если судить по этому форуму, то пИсал ты на него больше, чем все остальный тут вместе взятые
Я не пИсал на него, как Вы выражаетесь. Просто я, имея нескромный опыт программирования на самых разных языках и парадигмах, понимаю на сколько убог этот язык.
Re[15]: Модульные тесты и "безопасные" языки - хорошо.
C>>Вы так программируете? Тогда Вас надо гнать в шею за такой индусокод.
ГВ>Ну-ка, ну-ка. Назови хотя бы две любые проблемы этого кода.
Достаточно одной — присваивание внутри выражения if ().
Re[13]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, CreatorCray, Вы писали:
C>>>>>>if (i = n) {...} C>>>>Проблема в том, что это корректный синтаксис. Корректный синтаксис допускающий некорректное поведение — более чем причина, чтоб ругать язык. V>>>Это совершенно корректный синтаксис. И совершенно корректное поведение. C>>Корректное поведение... смешно. Ну покажите мне код, где такое поведение корректное.
CC>Пфф! CC>
C>"Прелесть" С++ (кто представляет себе ассемблерный код после компиляции поймет что в таком случае произойдет): C>
C>int i;
C>int array[4];
C>for (int i = 0; i <= 4; i++) {
C> array[i]=0;
C>}
C>
C>(подсказка: бесконечный цикл)
Во-первых, совершенно необязательно. Зависит от компилятора, системы, параметров оптимизации и много чего другого. Например, никто не помешать разложить компилятору цикл в последовательность из четырех операций.
Во-вторых, подобное звучит примерно на столько же убедительно, насколько такое:
C++ — плохой язык, на нем можно написать такое: system("del C:\*.*").
Кстати, человек, действительно знакомый с С++ не по-наслышке, никогда такого, что у тебя в примере не напишет. Мне, например, сразу в глаза бросилось <= — такое условие в цикле итерации не встречается никогда.
Ну и в последних, писать итеративные циклы в С++, где есть for_each, bind и lambda — каменный век.
Да здравствует мыло душистое и веревка пушистая.
Re[2]: Модульные тесты и "безопасные" языки - хорошо.
C>>У кого еще остались сомнения в целесообразности модульных тестов, в целесообразности использования языков/платформ с большим количеством статических и динамических проверок...
Х>конечно не осталось! ведь всем известно что модульные тесты и языки/платформы с большим количеством статических и динамических проверок исключают ошибки на корню!
Исключают такого рода ошибки на корню фактически, да.
Х>P.S. Х>я конечно понимаю что тебе С++ в детстве на ухо наступил,
Я на С++ писал не меньше, а то и побольше Вашего.
Re[5]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>Потому, что управляемые языки ИСКЛЮЧАЮТ "ДТП", связанные, с этим (манипуляция указателей) классом ошибки. C>Ремень безопасности повышает шанс выжить в ДТП, но не уменьшает вероятности ДТП. Понимаете?
Управляемые языки исключают некоторые классы ошибок (например, обращение по невалидному указателю или за пределами массива), совсем никак не исключая других классов ошибок (например, использование некорректных алгоритмов).
Если продолжить аналогию с ДТП, управляемые языки (я бы, кстати, предпочел термин "безопасные", потому что безопасный язык можно реализовать на голом железе, без всяких "управляемых" сред) не позволяют вам нарушать правила дорожного движения. Но можно убиться насмерть не нарушив ни одного правила, потому что жизнь сложнее правил.
А пользователю вашему все равно, к какому классу относилась ошибка, убившая его файл или банковский счет, к тому, которые предотвращаются использованием "безопасных" инструментов, или к тому, которые не предотвращаются.
Re[4]: Модульные тесты и "безопасные" языки - хорошо.
Hello, Геннадий Васильев, you write:
ГВ> Тпру! А признать свою ошибку с бесконечным циклом слабо?
Он? Признать свою ошибку? Не смеши. Щас накидает тебе обвинений во лжи, закидает вопросами итд. Отстает только когда игнорируя все настаиваешь на своем. Да и то просто перкращает разговор.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, criosray, Вы писали:
C>>У кого еще остались сомнения в целесообразности модульных тестов, в целесообразности использования языков/платформ с большим количеством статических и динамических проверок...
Pzz>Я где-то читал, что повсеместное введение автомобильных ремней безопасности не снизило количество смертей на дорогах: люди почувствовали себя "безопаснее" и стали ездить быстрее.
Ой, а можно с контр-аналогией встряну? Спасибо.
Когда в ПДД, водителей мотоциклов обязали едить в шлеме, травматизм в стране резко вырос. Стали разбираться че за фигня. И вопреки очевидному мнению, что люди стали ездить небрежнее, чувствуя себя в большей защищенности, выяснилась несколько другая вещь. Травматизм действительно вырос, т.к. раньше люди тупо убивались насмерть и портили статистику моргам, а не отделениям травматологии.
Здравствуйте, criosray, Вы писали:
C>Я на С++ писал не меньше, а то и побольше Вашего.
если судить по этому форуму, то пИсал ты на него больше, чем все остальный тут вместе взятые
Re[2]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, criosray, Вы писали:
C>Попробуйте скомпиллировать данный код в VC++ любой версии и запустить. C>Сразу скажу, что код корректен.
C>Попробуйте без дебагера угадать в чем проблема. Удачи.
Сейчас скажу грубо, но как говориться троллю троллево:
Я тебе и без дебаггера скажу в чём проблема, проблема в том что ты не знаешь что такое триграфы. Ещё проблема в том что ты нихрена не писал на С++ как заявляешь, либо у тебя настолько ороговение мозга что я даже не знаю последствием какой травмы это может являться. Пиши на C# родной, забей на С++, очевидно что этот язык не для тебя.
People write code, programming languages don't.
Re: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>http://habrahabr.ru/blogs/lifehack/64627/
C>"Прелесть" С++ (кто представляет себе ассемблерный код после компиляции поймет что в таком случае произойдет): C>
C>int i;
C>int array[4];
C>for (int i = 0; i <= 4; i++) {
C> array[i]=0;
C>}
C>
C>(подсказка: бесконечный цикл)
садитесь, два.
Если бы Вы знали, как работает стэк, то поняли бы, что запись в array[4] затрет внешнюю (по отношению к циклу) переменную i, и никаким образом на количестве итераций не скажется.
Re: Модульные тесты и "безопасные" языки - хорошо.
C>У кого еще остались сомнения в целесообразности модульных тестов, в целесообразности использования языков/платформ с большим количеством статических и динамических проверок...
конечно не осталось! ведь всем известно что модульные тесты и языки/платформы с большим количеством статических и динамических проверок исключают ошибки на корню!
P.S.
я конечно понимаю что тебе С++ в детстве на ухо наступил, но всё же вот тебе домашнее задание — подумать почему же Lockheed Martin пишут софт для всяких там шаттлов и стелсов на С++. И ещё подумать почему у них в среднем одна ошибка на полмиллиона строк кода.
People write code, programming languages don't.
Re[3]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
Pzz>>Я где-то читал, что повсеместное введение автомобильных ремней безопасности не снизило количество смертей на дорогах: люди почувствовали себя "безопаснее" и стали ездить быстрее.
C>Некорректная аналогия.
Почему?
Вернее нет, следовало бы ответить в вашем стиле, корректная! И никаких объяснений
Re[10]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>>>if (i = n) {...} M_>>незнание синтаксиса — не причина ругать язык. C>Проблема в том, что это корректный синтаксис. Корректный синтаксис допускающий некорректное поведение — более чем причина, чтоб ругать язык.
Это корректный синтаксис и корректное поведение. Современные компиляторы выдают на такие конструкции предупреждения, но некорректными они от этого не становятся.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[9]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
ГВ>>>>Ну как это — о чём? В заглавном сообщении ты утверждал, что произойдёт бесконечный цикл (в своеобычной манере гуру, раскрывающего тайны мироздания плебсу). C>>>Он и произойдет. ГВ>>Это не обязательно. C>Этого я и не утверждал.
C>>>Язык ущербный, что поделаешь.
C>Только не эффектом, а поведением — детерменированным или недетерменированным. Да, я понимаю конечно и получше Вашего.
ГВ>>Дудки! Тому, кто уверяет, что программировал на C++ аж 10 лет и продолжает нести восхитительную ахинею касательно этого же C++, C>Какую ахинею? Вы действительно не знаете С++, раз думаете, что это ахинея. ГВ>>проводить ликбез я не буду по принципиальным соображениям. C>Еще бы. Яйцо курицу не учит.
ну прямо по описанному Шериданом сценарию! Браво!
Re[15]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>>>Вы так программируете? Тогда Вас надо гнать в шею за такой индусокод. ГВ>>Ну-ка, ну-ка. Назови хотя бы две любые проблемы этого кода. C>Достаточно одной — присваивание внутри выражения if ().
А в чём проблема присваивания внутри выражения if? Вроде бы, всё понятно даже программисту на самом обыкновенном C.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[3]: Модульные тесты и "безопасные" языки - хорошо.
C>"Прелесть" С++ (кто представляет себе ассемблерный код после компиляции поймет что в таком случае произойдет): C>
C>int i;
C>int array[4];
C>for (int i = 0; i <= 4; i++) {
C> array[i]=0;
C>}
C>
C>(подсказка: бесконечный цикл)
далеко не самый наглядный пример, если кто захочет проверить вероятность что счётчик цикла окажется сразу за array[3] и не будет загнан в регистр очень сильно не 100%
компилятор + опции?
Re[4]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Pzz, Вы писали:
Pzz>>>Я где-то читал, что повсеместное введение автомобильных ремней безопасности не снизило количество смертей на дорогах: люди почувствовали себя "безопаснее" и стали ездить быстрее.
C>>Некорректная аналогия.
Pzz>Почему?
Потому, что управляемые языки ИСКЛЮЧАЮТ "ДТП", связанные, с этим (манипуляция указателей) классом ошибки.
Ремень безопасности повышает шанс выжить в ДТП, но не уменьшает вероятности ДТП. Понимаете?
Re[2]: Модульные тесты и "безопасные" языки - хорошо.
C>>int i;
C>>int array[4];
C>>for (int i = 0; i <= 4; i++) {
C>> array[i]=0;
C>>}
C>>
C>>(подсказка: бесконечный цикл) M_>садитесь, два. M_>Если бы Вы знали, как работает стэк, то поняли бы, что запись в array[4] затрет внешнюю (по отношению к циклу) переменную i, и никаким образом на количестве итераций не скажется.
Опечатка конечно подразумевалось for (i = 0;
Если Вам нравится цепляться к словам, то и я прицеплюсь к Вашим: в языке С конструкция for (int i;... синтаксически некорректна.
Садитесь, два.
Re[3]: Модульные тесты и "безопасные" языки - хорошо.
C>>>"Прелесть" С++ (кто представляет себе ассемблерный код после компиляции поймет что в таком случае произойдет): C>>>
C>>>int i;
C>>>int array[4];
C>>>for (int i = 0; i <= 4; i++) {
C>>> array[i]=0;
C>>>}
C>>>
C>Опечатка конечно подразумевалось for (i = 0; C>Если Вам нравится цепляться к словам, то и я прицеплюсь к Вашим: в языке С конструкция for (int i;... синтаксически некорректна.
А причем тут С? В начале речь шла о С++. В С++ это более чем корректная конструкция.
Да здравствует мыло душистое и веревка пушистая.
Re[7]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
CC>>Имплементация С++0х не есть самодеятельность. C>Пока С++0x draft — есть самодеятельность.
Тут ещё нужно топнуть ногой.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[6]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Геннадий Васильев, Вы писали:
C>>>>>>(подсказка: бесконечный цикл) ГВ>>>>>Двойка за апелляцию к тому, чего толком не знаешь. Произойдёт UB. Остальные тезисы... Ну, ты понял. C>>>>Вот именно, что делает подобные ошибки во сто крат хуже, так как результат такой ошибки непредсказуем. ГВ>>>Тпру! А признать свою ошибку с бесконечным циклом слабо? C>>Вы о чем?
ГВ>Ну как это — о чём? В заглавном сообщении ты утверждал, что произойдёт бесконечный цикл (в своеобычной манере гуру, раскрывающего тайны мироздания плебсу).
Он и произойдет. ГВ>На самом деле спецификация языка не предусматривает каких-то определённых эффектов в этом случае. Это всем известно, никакой Америки тут не открыто.
Язык ущербный, что поделаешь.
ГВ>Приличные люди в таких случаях извиняются за поднятие шума на ровном месте. А потом уже можно обсудить UB и иже с ними. Кстати, именно из-за UB столь яростно продвигаемые тобой unit-тесты в этом случае могут только добавить путаницы: то есть под тестовым окружением всё сработает, а программа завалится.
Зависимость тут не от окружения, а от компиллятора. Поэтому если тестировать продакшн левел бинарник, как это делается в нормальных системах разработки, то проблема будет тут же выявлена — будет сгенерировано исключение с сообщением о выходе за границы массива во время выполнения теста.
Re[8]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>Ну как это — о чём? В заглавном сообщении ты утверждал, что произойдёт бесконечный цикл (в своеобычной манере гуру, раскрывающего тайны мироздания плебсу). C>>Он и произойдет.
ГВ>Это не обязательно.
Этого я и не утверждал.
ГВ>>>На самом деле спецификация языка не предусматривает каких-то определённых эффектов в этом случае. Это всем известно, никакой Америки тут не открыто. C>>Язык ущербный, что поделаешь.
ГВ>Иными словами, ты не понимаешь разницы между неопределённым и определённым эффектом.
Только не эффектом, а поведением — детерменированным или недетерменированным. Да, я понимаю конечно и получше Вашего.
ГВ>>>Приличные люди в таких случаях извиняются за поднятие шума на ровном месте. А потом уже можно обсудить UB и иже с ними. Кстати, именно из-за UB столь яростно продвигаемые тобой unit-тесты в этом случае могут только добавить путаницы: то есть под тестовым окружением всё сработает, а программа завалится. C>>Зависимость тут не от окружения, а от компиллятора. Поэтому если тестировать продакшн левел бинарник, как это делается в нормальных системах разработки, то проблема будет тут же выявлена — будет сгенерировано исключение с сообщением о выходе за границы массива во время выполнения теста.
ГВ>Дудки! Тому, кто уверяет, что программировал на C++ аж 10 лет и продолжает нести восхитительную ахинею касательно этого же C++,
Какую ахинею? Вы действительно не знаете С++, раз думаете, что это ахинея. ГВ>проводить ликбез я не буду по принципиальным соображениям.
Еще бы. Яйцо курицу не учит.
Re[4]: Модульные тесты и "безопасные" языки - хорошо.
Приветствую, игппук, вы писали:
и> C>Прямой доступ к памяти и ручные манипуляции указателями это бомба с часовым механизмом. и> вы правы. указатели и прямой доступ к памяти — это игрушки не для детей.
Угу, еще палец невзначай оторвет. Не, ненадо давать детям такое. Пусть в пеесочке вон играются...
Здравствуйте, criosray, Вы писали:
ГВ>>Ну как это — о чём? В заглавном сообщении ты утверждал, что произойдёт бесконечный цикл (в своеобычной манере гуру, раскрывающего тайны мироздания плебсу). C>Он и произойдет.
Это не обязательно.
ГВ>>На самом деле спецификация языка не предусматривает каких-то определённых эффектов в этом случае. Это всем известно, никакой Америки тут не открыто. C>Язык ущербный, что поделаешь.
Иными словами, ты не понимаешь разницы между неопределённым и определённым эффектом. Хм. Действительно, требовать извинений в этом случае бессмысленно — не знал, да ещё и забыл, не забыл лишь метнуть какашку. Последнее можно списать на привычку.
ГВ>>Приличные люди в таких случаях извиняются за поднятие шума на ровном месте. А потом уже можно обсудить UB и иже с ними. Кстати, именно из-за UB столь яростно продвигаемые тобой unit-тесты в этом случае могут только добавить путаницы: то есть под тестовым окружением всё сработает, а программа завалится. C>Зависимость тут не от окружения, а от компиллятора. Поэтому если тестировать продакшн левел бинарник, как это делается в нормальных системах разработки, то проблема будет тут же выявлена — будет сгенерировано исключение с сообщением о выходе за границы массива во время выполнения теста.
Дудки! Тому, кто уверяет, что программировал на C++ аж 10 лет и продолжает нести восхитительную ахинею касательно этого же C++, проводить ликбез я не буду по принципиальным соображениям.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[8]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, criosray, Вы писали:
C>>Не будет ошибки — трудноуловимого бага, как в С++, будет исключение с сообщением о том, что индекс за пределами диапазона.
Pzz>Вот приятно получить от банкомата исключение с сообщением в тот момент, когда бапки со счета он уже списал, за щеку себе отслюнил, а в руки вам еще не выдал.
Смешно. Для этого существуют транзакции.
Re[3]: Модульные тесты и "безопасные" языки - хорошо.
C>>>if (i = n) {...} C>Проблема в том, что это корректный синтаксис. Корректный синтаксис допускающий некорректное поведение — более чем причина, чтоб ругать язык.
Это совершенно корректный синтаксис. И совершенно корректное поведение. Если лично ТЫ не знаешь, как работает оператор присваивания и конструкция if — то так и скажи.
C>>>Это С++ болеет детскими болезнями. До таких языков как С#, Nemerle, Boo, F#, Haskell, OCaml, Erlang, Python, Ruby... ему как от земли до неба.
brain fcuk забыл.
Да здравствует мыло душистое и веревка пушистая.
Re[16]: Модульные тесты и "безопасные" языки - хорошо.
Этот код хоть и немного лучше оригинала, но все-равно откровенно плох. Выражение if подразумевает логическое, а не целочисленное значение. Да, когда-то в С (без плюсов) не было типа boolean, потому логические правду и ложь представляли в виде целочисленных 1 и 0. В С++ для совместимости с С это оставили, хотя и ввели наконец полноценный тип bool. Вышеприведенный код это гремучая смесь из С и С++. Все тот же индусокод.
CC>Да, лично я предпочитаю не писать присвоение в условии. Но это вопрос стиля, мне так больше нравится. CC>Но и не считаю что присвоение в условии неправильно.
CC>Зелёному новичку разумеется надо вбить в голову что присвоение в условии это полный капец и так делать нельзя. Во избежание. Ибо сдуру и по неопытности он наворотит говнокода. CC>Когда подрастёт — можно объяснить что иногда на самом деле так делать всё таки можно. CC>Впрочем когда подрастёт — сам должен понять.
Когда действительно подрастет, то поймет почему ТАК писать нельзя.
Re[9]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, WolfHound, Вы писали:
Pzz>>Можно отлавливать алгоритмы, у которых "вилка не подошла к розетке". Но как вы поймаете, с помощью какой угодно системы типов, ситуацию, когда вам, грубо говоря, надо было взять среднее квадратичное, а вы взяли среднее арифметическое? WH>Ты удивишься но это при желании тоже можно свести к "вилка не подошла к розетке".
Можно, но это сведение будет само по себе не простым. И станет подходящим местом, чтобы влепить туда нетривиальную ошибку
WH>На самом деле грань между заранее скомпилированной программой и отJITеной программой настолько тонка что тут и говорить не о чем.
Я сказал простую вещь: понятия "безопасного" языка и "управляемого" языка ортогональны. Можно сделать безопасный язык, который статически компилируется в машинный код, можно сделать управляемый язык, который будет небесопасен (правда, второе непонятно зачем делать). Я ничего не сказал при этом относительно связанного с JIT-ом оверхеда. Против того, что я сказал, какие-нибудь возражения по существу имеются?
WH>>>Устранение некоторых классов ошибок == меньше ошибок при тех же усилиях. Pzz>>Зато оставшиеся ошибки становятся гораздо более заковыристыми WH>Одно из другого не следует.
Вы получаете инструмент, позволяющий со сравнимым уровнем усилий делать более сложные конструкции. А чем сложнее конструкция, тем более заковыристую ошибку в ней можно посадить.
Re[11]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
Pzz>>Потому что простые отсеиваются компилятором.
C>Где логика? Как отсеивание части ошибок может делать "оставшиеся ошибки более заковыристыми"?
У программиста появляется больше времени делать более хитрые ошибки.
С чем вы спорите? Безопасные среды появились раньше, чем вы родились на свет. Благодаря усилиям фирмы Мелкософт они уже достаточно давно популярны. Казалось бы, глюки в софтварии давно должны исчезнуть, однако экспериментальным фактом является то, что они почему-то не исчезают. Получается парадокс, не так ли?
Re[16]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, March_rabbit, Вы писали:
C>>>>>Я-то прекрасно знаю, как работает оператор присваивания и конструкция if — именно потому и говорю. В 9 из 10 случаев в С/С++ исходниках можно увидеть if (NULL == something) {} вместо if (something == NULL) {}. Это наверно от хорошей жизни, да? V>>>>За 11 лет — видел только в индусских рекомендациях. Это от индуизма. M_>>>а вот тут не согласен: расположение константы впереди защищает от описки, которую не сразу и заметишь. CC>>От описки защищает правильно настроенные опции компилятора M_>в смысле, очередной варнинг? Или запрет присвоения в условии? M_>Если ты про варнинг, то.... В нашем проекте этих варнингов столько, что новые часто не замечаются. Мозилла вся насквозь пропитана варнинговым кодом. Поэтому предупреждение — не выход.
Ну, по хорошему в проекте должно стоять "Treat warning as error".
Что в общем то сразу отбивает охоту писать присвоения в if Так что проблема решается как бы сама собой.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[25]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, WFrag, Вы писали:
WF>Здравствуйте, _d_m_, Вы писали:
___>>Ну это уже как-бы за рамками данного обсуждения. Ведь речь идет о распределенных транзакциях и о том, что может в ней участвовать.
WF>Я начал с того момента, где criosray «доработал» твой алгоритм.
А вот так всегда в КСВ — вопрос: разница между трудноуловимым багом и исключениями перерос в то, что клиент сопрет купюру из серединки и скажет, что не брал. И более того найдутся апологеты которые скажут, что это косяк управляемых языков и исключения это гавно
Re: Модульные тесты и "безопасные" языки - хорошо.
Возможно, многие в курсе про недавнюю узявимость в ActiveX компоненте MSVidCtl, которая потенциально могла позволить злоумышленнику выполнить произвольный код используя переполнение буфера. Недавно, в блоге посвященному практике SDL появилось описание ошибки программиста, которая привела к уязвимости защиты.
Ошибка заключается в одном символе, вместо правильного кода:
hr = pStream->Read((void*)pbArray, (ULONG)cbSize, NULL);
* This source code was highlighted with Source Code Highlighter.
программист написал
hr = pStream->Read((void*)&pbArray, (ULONG)cbSize, NULL);
* This source code was highlighted with Source Code Highlighter.
использование лишнего символа & (получение адреса) привело к тому, что злоумышленник получил возможность произвести удаленное переполнение буфера с известными последствиями.
Подробнее про эту ошибку, почему ее пропустили и что будет сделано, чтобы подобные ошибки больше не появлялись, пожно почитать в блоге там же есть описание и другой ошибки связанной с ATL.
Re[2]: Модульные тесты и "безопасные" языки - хорошо.
КБ>if (p < 0,5) { std::cout << "Вот так спутники и падают..."; }
КБ>
КБ>
Для спутников наши используют виртовские языки, а не С/С++. Как ГОРАЗДО более надежные и ГОРАЗДО меньшего размера...
С сайта Информатика-21:
А.А.Колташев, нач. отдела системного программирования для космических аппаратов ОАО «Информационные спутниковые системы» им. М.Ф.Решетнева, г. Железногорск, Красноярского края (ИСС — главное спутникостроительное предприятие России; акад. М.Ф.Решетнев — сподвижник С.П.Королева и основатель ИСС; об истории см. Википедию). Ученик школ А.П.Ершова, И.В.Поттосина и В.В.Липаева. Оказавшись у истоков появления бортовых ЦВМ на спутниках связи, разработал принципы и технологии построения бортового ПО, руководил созданием ОС для первого советского стационарного спутника с БЦВМ (1981). Руководил созданием действующей технологии разработки БПО для данного приложения, в т.ч. уникальной мобильной кросс-системы программирования на основе виртовской Модулы-2 (см. Модуле-2; о спутниках Глонасс-М, часть 2). С 1990 г. читает курс "Технологии программирования" сначала в Сибирской Аэрокосмической Академии, затем в Красноярском гос. тех. университете. Доцент каферды АСОИУ КрГТУ. Профессиональная обязанность и научный интерес — создание мобильной технологии программирования с гарантированным уровнем качества для встроенных компьютеров.
На сайте Информатика-21 есть все ссылки.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[2]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Vamp, Вы писали:
C>>"Прелесть" С++ (кто представляет себе ассемблерный код после компиляции поймет что в таком случае произойдет): C>>
C>>int i;
C>>int array[4];
C>>for (int i = 0; i <= 4; i++) {
C>> array[i]=0;
C>>}
C>>
C>>(подсказка: бесконечный цикл) V>Во-первых, совершенно необязательно. Зависит от компилятора, системы, параметров оптимизации и много чего другого. Например, никто не помешать разложить компилятору цикл в последовательность из четырех операций. V>Во-вторых, подобное звучит примерно на столько же убедительно, насколько такое:
V>
V>C++ — плохой язык, на нем можно написать такое: system("del C:\*.*").
V>Кстати, человек, действительно знакомый с С++ не по-наслышке, никогда такого, что у тебя в примере не напишет.
Напишет.
void myFoo(int *arr, int length)
{
for (int i = 0; i < length; i++) {
arr[i] = 0;
}
}
...
int *arr = new int[length];
...
length++;
...
myFoo(arr, length);
V>Мне, например, сразу в глаза бросилось <= — такое условие в цикле итерации не встречается никогда.
В VISA тоже так думали.
V>Ну и в последних, писать итеративные циклы в С++, где есть for_each, bind и lambda — каменный век.
В std есть lambda? С каких пор?
Re[4]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, swined, Вы писали:
S>одно не ясно — почему они все вместе не портили статистику ментам, как пострадавшие в аварии?
Портили. Именно поэтому, у меня и моих коллег, после распространения управляемых сред, работы меньше не стало. Просто уязвимости стали другие, однако большая их часть, стала нести с собой гораздо меньше рисков
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, _d_m_, Вы писали:
___>>Ну конечно 100% нет. Но с учетом вышесказанного мной, здесь мы уже переходим в раздел вероятностей, где обезьяны печатают "Война и мир" случайными нажатиями.
G>Вроде существуют способы сделать 100% транзакционность в распределенной среде.
Не верю! Невозможно.
Re[3]: Модульные тесты и "безопасные" языки - хорошо.
C>void myFoo(int *arr, int length)
C>{
C> for (int i = 0; i < length; i++) {
C> arr[i] = 0;
C> }
C>}
C>...
C>int *arr = new int[length];
C>...
C>length++;
C>...
C>myFoo(arr, length);
C>
Ты уж дай волю фантазии, пусть твой C++-ник напишет так:
length *= 10;
Целовать — так королеву, обнулять память — так подчистую!
V>>Ну и в последних, писать итеративные циклы в С++, где есть for_each, bind и lambda — каменный век. C>В std есть lambda? С каких пор?
А что, на std свет клином сошёлся?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[7]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>Это не вопрос на вопрос, это уточняющий вопрос. Чтоб признать ошибку я должен узнать о чем идет речь.
Он от этого меньше стал вопросом? Да и уточнять тут особо нечего. Я мог бы это высказать в твоём стиле: "Если ты не понял этот вопрос то ты либо тролль, либо у тебя ФГМ.", но не стану. Вобщем ты съезжаешь с темы, впрочем, как всегда.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[10]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>>>Ну как это — о чём? В заглавном сообщении ты утверждал, что произойдёт бесконечный цикл (в своеобычной манере гуру, раскрывающего тайны мироздания плебсу). C>>>>Он и произойдет. ГВ>>>Это не обязательно. C>>Этого я и не утверждал.
ГВ>Ты уж сам разберись в своих посланиях: не то ты утверждал про цикл, не то не утверждал. Поясняющих ремарок про "обязательность" ты тоже не сделал, так что полагаем, что ты всё же уверен именно в бесконечном цикле.
Я не собираюсь играть с Вами в слова. Свою точку зрения я уже доказал.
ГВ>>>>>На самом деле спецификация языка не предусматривает каких-то определённых эффектов в этом случае. Это всем известно, никакой Америки тут не открыто. C>>>>Язык ущербный, что поделаешь. ГВ>>>Иными словами, ты не понимаешь разницы между неопределённым и определённым эффектом. C>>Только не эффектом, а поведением — детерменированным или недетерменированным. Да, я понимаю конечно и получше Вашего.
ГВ>Молодец, формально правильно именно "поведение", кстати, именно "определённое" (defined), а не "детерминированное".
Определенное поведение это такое, которое БЫЛО кем-то заданно.
Детерменированное поведение это такое, которое однозначно предопределенно.
Не видите разницы?
ГВ>Вопрос: что это меняет? Пропала разница между детерминированностью (определённостью) и недетерминированностью (неопределённостью)?
В данном случае поведение недетерменированное. Недетерменированное поведение в программировании ведет к огромному числу проблем в самых неожиданных местах.
C>>>>Зависимость тут не от окружения, а от компиллятора. Поэтому если тестировать продакшн левел бинарник, как это делается в нормальных системах разработки, то проблема будет тут же выявлена — будет сгенерировано исключение с сообщением о выходе за границы массива во время выполнения теста. ГВ>>>Дудки! Тому, кто уверяет, что программировал на C++ аж 10 лет и продолжает нести восхитительную ахинею касательно этого же C++, C>>Какую ахинею? Вы действительно не знаете С++, раз думаете, что это ахинея.
ГВ>Я думаю, что у тебя каша в голове. Предметно её распутывать, честно говоря, не имею ни малейшего желания.
Вы свою бы распутали для начала.
ГВ>>>проводить ликбез я не буду по принципиальным соображениям. C>>Еще бы. Яйцо курицу не учит. ГВ>Разумеется. Сам себя не похвалишь, адепты и не додумаются.
Никакой хвальбы — просто констатация фактов.
Re[11]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
ГВ>>Ты уж сам разберись в своих посланиях: не то ты утверждал про цикл, не то не утверждал. Поясняющих ремарок про "обязательность" ты тоже не сделал, так что полагаем, что ты всё же уверен именно в бесконечном цикле. C>Я не собираюсь играть с Вами в слова. Свою точку зрения я уже доказал.
Это тебе кажется, что ты её доказал. На самом деле ты доказал, что "бумага всё стерпит". Тоже мне, новость...
ГВ>>Молодец, формально правильно именно "поведение", кстати, именно "определённое" (defined), а не "детерминированное". C>Определенное поведение это такое, которое БЫЛО кем-то заданно. C>Детерменированное поведение это такое, которое однозначно предопределенно. C>Не видите разницы?
В данном контексте этой разницей можно пренебречь. UB — undefined behavior. Термин вполне устоявшийся и общепонятный.
ГВ>>Вопрос: что это меняет? Пропала разница между детерминированностью (определённостью) и недетерминированностью (неопределённостью)? C>В данном случае поведение недетерменированное. Недетерменированное поведение в программировании ведет к огромному числу проблем в самых неожиданных местах.
Ага, теперь ты со мной будешь играть в слова, вообще отвязанные от контекста. Прикольно. С одной стороны, это, конечно, хорошо, что ты проявляешь интерес к словам и формулировкам (не всё ж языком парадигматично ООП-нутых трипов изъясняться), а с другой, ты пока ещё слишком торопишься. Ну ничего, различение приходит с опытом — практикуй с должным усердием и не пугайся трудностей.
C>>>>>Зависимость тут не от окружения, а от компиллятора. Поэтому если тестировать продакшн левел бинарник, как это делается в нормальных системах разработки, то проблема будет тут же выявлена — будет сгенерировано исключение с сообщением о выходе за границы массива во время выполнения теста. ГВ>>>>Дудки! Тому, кто уверяет, что программировал на C++ аж 10 лет и продолжает нести восхитительную ахинею касательно этого же C++, C>>>Какую ахинею? Вы действительно не знаете С++, раз думаете, что это ахинея.
ГВ>>Я думаю, что у тебя каша в голове. Предметно её распутывать, честно говоря, не имею ни малейшего желания. C>Вы свою бы распутали для начала.
Так как же я её распутаю? У меня ж миелофона нет, чтобы ход твоих мыслей проследить и правильно вербализовать. Вот и приходится дешифровывать твои сообщения.
ГВ>>>>проводить ликбез я не буду по принципиальным соображениям. C>>>Еще бы. Яйцо курицу не учит. ГВ>>Разумеется. Сам себя не похвалишь, адепты и не додумаются. C>Никакой хвальбы — просто констатация фактов.
Хм. Факт, я так понимаю, это то, что ты считаешь фактом, безотносительно объективной реальности. Э... Дружище, ну вот говорил я тебе, не кури ООП-траву, да всё впустую.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[14]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, March_rabbit, Вы писали:
C>>>Я-то прекрасно знаю, как работает оператор присваивания и конструкция if — именно потому и говорю. В 9 из 10 случаев в С/С++ исходниках можно увидеть if (NULL == something) {} вместо if (something == NULL) {}. Это наверно от хорошей жизни, да? V>>За 11 лет — видел только в индусских рекомендациях. Это от индуизма. M_>а вот тут не согласен: расположение константы впереди защищает от описки, которую не сразу и заметишь.
От описки защищает правильно настроенные опции компилятора
А константа впереди ломает глазки при чтении кода.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[16]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, March_rabbit, Вы писали:
CC>>Что в общем то сразу отбивает охоту писать присвоения в if Так что проблема решается как бы сама собой. M_>ага... и превращает опенсорц код в нечто неюзабельное
Это только в минус опенсорц коду.
M_>для примера попробуй взять мозиллу тандерберд 2 и собрать с этой опцией.... Сумеешь — памятник тебе поставлю!
Дык сразу писать надо ровными ручками а не как попало.
M_>На самом деле не смешно нифига... Было уже пару раз, что пропускал серьезный варнинг в этой куче предупреждений от любого хедера мозиллы.... А ничего не поделаешь, там вся идеология такая, что волосы дыбом встают
Идеология значит неправильная.
В нормальном проекте варнингов быть не должно.
Если варнинг все же не существенен но не лечится — тогда его локально давят с комментом почему задавили
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[20]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, WolfHound, Вы писали:
WH>Это зависит. Если говорить по жабу и .НЕТ то да. А если почистить систему типов и добавить зависимые типы то там можно и некорректные алгоритмы отлавливать. Пусть и ни на 100% но юнит тесты можно списать в утиль с чистой совестью.
Можно отлавливать алгоритмы, у которых "вилка не подошла к розетке". Но как вы поймаете, с помощью какой угодно системы типов, ситуацию, когда вам, грубо говоря, надо было взять среднее квадратичное, а вы взяли среднее арифметическое?
Pzz>>я бы, кстати, предпочел термин "безопасные", потому что безопасный язык можно реализовать на голом железе, без всяких "управляемых" сред WH>А что конкретно ты понимаешь под "средой"?
То, что находится между программой и операционной системе, if any.
Pzz>>А пользователю вашему все равно, к какому классу относилась ошибка, убившая его файл или банковский счет, к тому, которые предотвращаются использованием "безопасных" инструментов, или к тому, которые не предотвращаются. WH>Устранение некоторых классов ошибок == меньше ошибок при тех же усилиях.
Зато оставшиеся ошибки становятся гораздо более заковыристыми
Re[9]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
Pzz>>Я сказал простую вещь: понятия "безопасного" языка и "управляемого" языка ортогональны. C>Глупость.
Ну а обосновать?
Pzz>>Можно сделать безопасный язык, который статически компилируется в машинный код, можно сделать управляемый язык, который будет небесопасен (правда, второе непонятно зачем делать). Я ничего не сказал при этом относительно связанного с JIT-ом оверхеда. Против того, что я сказал, какие-нибудь возражения по существу имеются? C>Ну вперед — сделайте. За 50+ лет до Вас не смогли. Удачи.
Чего сделать не смогли?
C>То есть когда Вы получаете ТЗ от заказчика, то отбрасываете половину со словами "мы этого делать не будем — наш инструмент нам не позволяет"?
Сделать по-разному можно.
Re[15]: Модульные тесты и "безопасные" языки - хорошо.
TreeNode *node = root.GetNode ("Foo");
if (node)
{
}
node = root.GetNode ("Bar");
if (node)
{
}
Да, лично я предпочитаю не писать присвоение в условии. Но это вопрос стиля, мне так больше нравится.
Но и не считаю что присвоение в условии неправильно.
Зелёному новичку разумеется надо вбить в голову что присвоение в условии это полный капец и так делать нельзя. Во избежание. Ибо сдуру и по неопытности он наворотит говнокода.
Когда подрастёт — можно объяснить что иногда на самом деле так делать всё таки можно.
Впрочем когда подрастёт — сам должен понять.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[15]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, _d_m_, Вы писали:
___>Нам хэндшейки нужны только на Commit-e. Больше нигде. Серверу вообще пофиг — что там у клиента исключение или что еще. Ему дали команду списать деньги, а дальше одно из двух — либо комит, либо ролбэк.
Коммит в какой момент? Когда бапки уже выдали клиенту? А если коммит не пройдет, получается мы бапки подарим. До выдачи? А если не получится выдать, по механическим причинам, а потом не пройдет обратная транзакция? Получается, что клиент подарит бапки нам.
Фактически, банкомат делает коммит, когда уже решил деньги отслюнавливать. Иногда у него не получается отслюнявить, тогда он делает обратную транзакцию. Я один раз такое видел, банкомат долго тарахтел деньгами, потом плюнул и сказал, что денег не даст. На счету было две транзакции: снятие и сразу возврат. Иногда обратная тракзакция не проходит, тогда у клиента начинается хождение по мукам
Pzz>>Поэтому гарантировать можно что-то одно из двух: либо что операция случится не более одного раза, либо что не менее одного раза. Но невозможно гаратнировать одновременно и то и то.
___>Ну конечно 100% нет. Но с учетом вышесказанного мной, здесь мы уже переходим в раздел вероятностей, где обезьяны печатают "Война и мир" случайными нажатиями.
Мне, кстати, навскидку непонятно, как организовать последовательность шагов в хендшейке так, чтобы получить вероятность ошибки хендшейка меньше, чем вероятность ошибки в одном шаге.
Re[8]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, nme, Вы писали:
nme>Можно примеры таких фич?
WH>>Но даже для этой части нет гарантии того что проверки будут статическими.
nme>Вроде как Code Contracts это в первую очередь статические проверки (есть опция проверять в рантайме, но это не основное их предназначение).
Почитай хотя бы этот документ. http://download.microsoft.com/download/C/2/7/C2715F76-F56C-4D37-9231-EF8076B7EC13/userdoc.pdf
Там от слова runtime в глазах рябит.
Например этот тип при помощи горы кода может быть (я не уверен и проверять лень) получится нарисовать на Code Contracts
type IndexedMesh[Vertex : #, vertexCount : uint, indexCount : uint]
vertices : array[Vertex, vertexCuont];
indices : array[uintLimited[vertexCount], indexCount];
end
Но ты гарантированно получишь кучу проверок времени исполнения.
2.7 Quantifiers
Limited support is available for quantifiers within contracts. We support only those forms which are executable at runtime. This currently means that the range of quantification must be effectively computable.
Also, the “body” of each quantification must be an expression, i.e., not contain any loops or assignment statements. 2.7.1 ForAll
Universal quantifications are written using Contract. ForAll . ...
А этот код Code Contracts вообще никак проверить не смогут
for (i in mesh.indices.Indices)
def vertex = mesh.vertices[mesh.indices[i]];
...
end
В тоже время ЗТ не только все проверят на этапе компиляции но и гарантированно не вставят проверки времени исполнения ибо есть формальное доказательство их не нужности.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Хвост, Вы писали: Х>я конечно понимаю что тебе С++ в детстве на ухо наступил, но всё же вот тебе домашнее задание — подумать почему же Lockheed Martin пишут софт для всяких там шаттлов и стелсов на С++.
Потому что негоже отказываться от тонн отлаженно-оттестированного и надежного легаси-кода.
Х>И ещё подумать почему у них в среднем одна ошибка на полмиллиона строк кода.
А вот не факт, что код этот не подвергается какого-либо рода верификации. По "embedded code verification" гуглится огого сколько всего.
Ну и процесс тестирования грамотно поставлен.
Альсо, в аэрокосмосе наверняка последствия просочившихся в релиз багов для команды разработчиков весьма плачевны. Слышал про увольнения целых отделов на этой почве. Так что у руководства есть стимул набирать квалифицированных сотрудников, а у девелоперов — хорошо работать.
Re[2]: Модульные тесты и "безопасные" языки - хорошо.
C>>У кого еще остались сомнения в целесообразности модульных тестов, в целесообразности использования языков/платформ с большим количеством статических и динамических проверок...
Pzz>Я где-то читал, что повсеместное введение автомобильных ремней безопасности не снизило количество смертей на дорогах: люди почувствовали себя "безопаснее" и стали ездить быстрее.
Некорректная аналогия.
Re[3]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
A>>настоящие джедаи используют С++ со включением всех runtime checks и статический анализатор кода
C>Ну и какой компилятор С++ поможет в вышеуказанном случае?
Мне только пришлось вынести массив из тела функции. Иначе он довольно быстро соображал, что за записанными туда значениями все равно никто не придет, и не делал более глубокий анализ (ибо если ему очевидно, что в массив можно вовсе не писать, то по его мнению не за чем проверять, корректно ли вычисляется индекс, которым он все равно не собирался воспользоваться).
Re[6]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Mystic, Вы писали:
C>>Потому, что управляемые языки ИСКЛЮЧАЮТ "ДТП", связанные, с этим (манипуляция указателей) классом ошибки.
M>Будут ошибки, связанные не с манипуляцией указателями, а с манипуляцией индексами. Если код перевести на C#, то ошибка никуда не исчезнет, но сразу проявится при запуске.
Не будет ошибки — трудноуловимого бага, как в С++, будет исключение с сообщением о том, что индекс за пределами диапазона.
Re[7]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>Не будет ошибки — трудноуловимого бага, как в С++, будет исключение с сообщением о том, что индекс за пределами диапазона.
Вот приятно получить от банкомата исключение с сообщением в тот момент, когда бапки со счета он уже списал, за щеку себе отслюнил, а в руки вам еще не выдал.
Re: Модульные тесты и "безопасные" языки - хорошо.
в любом случае тут за length++ положено канделябром по башке.
V>>Ну и в последних, писать итеративные циклы в С++, где есть for_each, bind и lambda — каменный век. C>В std есть lambda? С каких пор?
С недавних.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[9]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, _d_m_, Вы писали:
Pzz>>Вот приятно получить от банкомата исключение с сообщением в тот момент, когда бапки со счета он уже списал, за щеку себе отслюнил, а в руки вам еще не выдал.
___>Смешно. Для этого существуют транзакции.
Транзакции, как известно, могут гарантировать что-то одно из двух. В случае банкомата это либо то, что денег не возьмут лишний раз со счета, либо то, что не выдадут лишний раз на руки. Как вы думаете, какой из этих вариатнов выбрали в банкомате?
Re[11]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Sinclair, Вы писали:
Pzz>>Транзакции, как известно, могут гарантировать что-то одно из двух. S>Не понял. Как известно, транзакции как раз и сделаны для того, чтобы гарантировать ровно 2 из двух. Разве нет?
Нет. Вы не знаете наверняка, не успел банкомат деньги выдать, или не успел сообщить серверу об их выдаче. И так на любом этапе.
Re[5]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>>>Я на С++ писал не меньше, а то и побольше Вашего. A>>если судить по этому форуму, то пИсал ты на него больше, чем все остальный тут вместе взятые C>Я не пИсал на него, как Вы выражаетесь. Просто я, имея нескромный опыт программирования на самых разных языках и парадигмах, понимаю на сколько убог этот язык.
А что ты такого замечательного писал, а? Сайтик для дяди васи или автоматизацию ларька?
Re[7]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>>>>>Я на С++ писал не меньше, а то и побольше Вашего. A>>>>если судить по этому форуму, то пИсал ты на него больше, чем все остальный тут вместе взятые C>>>Я не пИсал на него, как Вы выражаетесь. Просто я, имея нескромный опыт программирования на самых разных языках и парадигмах, понимаю на сколько убог этот язык.
HL>>А что ты такого замечательного писал, а? Сайтик для дяди васи или автоматизацию ларька? C>Это все, что Вы способны придумать? Слабова-то.
Нет, это не всё. Ты давай ответь по существу, что такого замечательного ты написал на (C#? java?), что ты говоришь о C++, как о "убогом" языке?
Re[5]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>Человеку свойственно ошибаться. В С++ ошибки трудноуловимы и их гораздо легче допустить в виду относительной низкоуровневости языка.
Данная ошибка следствие бардака в голове. Какое отношение идиотизм разработчика имеет к языку?
C>>>В std есть lambda? С каких пор? CC>>С недавних. C>Еще нету не выдумывайте. Самодеятельность отдельных компиллятор в расчет не берем.
Имплементация С++0х не есть самодеятельность.
То, что ты не хочешь этого видеть — твои личные трудности.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[6]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, CreatorCray, Вы писали:
C>>Человеку свойственно ошибаться. В С++ ошибки трудноуловимы и их гораздо легче допустить в виду относительной низкоуровневости языка. CC>Данная ошибка следствие бардака в голове. Какое отношение идиотизм разработчика имеет к языку?
Открываем первый пост. Идем по ссылке и внимательно читаем. Потом думаем. Если по прежнему не понятно — еще ра читаем и еще раз думаем.
Re[5]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, March_rabbit, Вы писали:
M_>>Да и вообще, код безграмотный. С таким подходом в любом языке можно наваять фигню, послое чего смело утверждать, что язык — г.... C>С той разницей, что на С++ это гораздо легче сделать и сложнее отладить.
Да ну. Сразу получил исключение: Run-Time Check Failure #2 — Stack around the variable 'array' was corrupted. И остановка на выходе из ф-ции.
(еще и warning C4101: 'i' : unreferenced local variable). В общем код плохой, а не язык.
Все настроики компилятора по умолчанию(2005 студия).
Re[3]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Хвост, Вы писали:
Х>Здравствуйте, criosray, Вы писали:
C>>Здравствуйте, criosray, Вы писали:
C>>Попробуйте скомпиллировать данный код в VC++ любой версии и запустить. C>>Сразу скажу, что код корректен.
C>>Попробуйте без дебагера угадать в чем проблема. Удачи.
Х>Сейчас скажу грубо, но как говориться троллю троллево:
Х>Я тебе и без дебаггера скажу в чём проблема, проблема в том что ты не знаешь что такое триграфы.
Я не знаю что такое триграфы? Я привел в качестве примера одного из многих подводных камней код с триграфом, определенным в одном компилляторе и неопределенном в другом компилляторе (что мы воочию убедились) и на основе этого Вы сделали такое интересный вывод? Давече здесь упоминали женскую логику... похоже Ваш случай.
Х>Ещё проблема в том что ты нихрена не писал на С++ как заявляешь,
Х>либо у тебя настолько ороговение мозга что я даже не знаю последствием какой травмы это может являться.
А это уже неприкрытое оскорбление. Вы не волнуйтесь, с мозгом у меня все в порядке, а вот у Вас явные проблемы с адекватным восприятием других людей. Х>Пиши на C# родной, забей на С++, очевидно что этот язык не для тебя.
И уж тем более не для Вас.
Re[8]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
M>>во-вторых, какой нормальный программист напишет в комментариях "так ведь ???" да еще оформлять их слешами в конце?.. C>Вы будете сильно удивлены, когда узнаете ЧТО программисты пишут в комментариях.
Ну, удиви меня.
ИМХО именно этот этюд — надуманный и высосанный из пальца.
Re[5]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Sheridan, Вы писали:
ГВ>> Тпру! А признать свою ошибку с бесконечным циклом слабо?
S>Он? Признать свою ошибку? Не смеши. Щас накидает тебе обвинений во лжи, закидает вопросами итд. Отстает только когда игнорируя все настаиваешь на своем. Да и то просто перкращает разговор.
Вы, уважаемый, за собой бы последили.
Re[10]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Sheridan, Вы писали:
ГВ>> Тпру! А признать свою ошибку с бесконечным циклом слабо? S>Он? Признать свою ошибку? Не смеши. Щас накидает тебе обвинений во лжи, закидает вопросами итд. Отстает только когда игнорируя все настаиваешь на своем. Да и то просто перкращает разговор.
Не подсказывай.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[11]: Модульные тесты и "безопасные" языки - хорошо.
C>>>>if (i = n) {...} M_>>>незнание синтаксиса — не причина ругать язык. C>>Проблема в том, что это корректный синтаксис. Корректный синтаксис допускающий некорректное поведение — более чем причина, чтоб ругать язык.
ГВ>Это корректный синтаксис и корректное поведение.
Вы сами-то в это верите? ГВ>Современные компиляторы выдают на такие конструкции предупреждения, но некорректными они от этого не становятся.
Ну хорошо, как же мне включить предупреждения в самом что ни на есть современном VC++?
Re[11]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Vamp, Вы писали:
C>>>>if (i = n) {...} C>>Проблема в том, что это корректный синтаксис. Корректный синтаксис допускающий некорректное поведение — более чем причина, чтоб ругать язык. V>Это совершенно корректный синтаксис. И совершенно корректное поведение.
Корректное поведение... смешно. Ну покажите мне код, где такое поведение корректное. V>Если лично ТЫ не знаешь, как работает оператор присваивания и конструкция if — то так и скажи.
Я-то прекрасно знаю, как работает оператор присваивания и конструкция if — именно потому и говорю. В 9 из 10 случаев в С/С++ исходниках можно увидеть if (NULL == something) {} вместо if (something == NULL) {}. Это наверно от хорошей жизни, да?
C>>>>Это С++ болеет детскими болезнями. До таких языков как С#, Nemerle, Boo, F#, Haskell, OCaml, Erlang, Python, Ruby... ему как от земли до неба. V>brain fcuk забыл.
Узнали для себя много нового?
Re[8]: Модульные тесты и "безопасные" языки - хорошо.
C>Конструкция напечататьхелловорлд имеет побочные эффекты, а именно подразумевает вывод на устройство вывода, что автоматически делает ее небезопасной в отличии от чисто функционального f(x) -> x * x, к примеру.
Ну-ну. И что потом с этим ха квадрат делать? Он так и останется в памяти компьютера вещью в себе? В реальном мире программам приходится заниматься такими небезопасными вещами, как пользовательский ввод-вывод и даже! о черт! генерировать случайные числа.
C>Вы, мой друг, еще очень много не знаете, я так погляжу...
Есть многое на свете, друг Горацио
Да здравствует мыло душистое и веревка пушистая.
Re[12]: Модульные тесты и "безопасные" языки - хорошо.
C>Корректное поведение... смешно. Ну покажите мне код, где такое поведение корректное.
A фиг ли скрывать?
struct crioscray {
handle crioscray_mind_handle;
const crioscray operator=(const crioscray& ccray) { synch_with_cryoscray_mind(ccray.crioscray_mind.handle); return *this};
operator bool() const {return is_crioscray_sane(crioscray_mind_handle)};
}
...
crioscray cray1, cray2;
if (cray1 = cray2) {
cout << "Crioscray is sane, here are two copies of it, use one and save the other as a backup in case something goes wrong!";
start_experiment(cray1);
} else {
cout << "Now we have two insane crioscray copies, screw them all!";
}
C>Я-то прекрасно знаю, как работает оператор присваивания и конструкция if — именно потому и говорю. В 9 из 10 случаев в С/С++ исходниках можно увидеть if (NULL == something) {} вместо if (something == NULL) {}. Это наверно от хорошей жизни, да?
За 11 лет — видел только в индусских рекомендациях. Это от индуизма.
V>>brain fcuk забыл. C>Узнали для себя много нового?
Нет, ничего нового не узнал.
Да здравствует мыло душистое и веревка пушистая.
Re[14]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, gandjustas, Вы писали:
G>>Вроде существуют способы сделать 100% транзакционность в распределенной среде.
DOO>Нет.
Дальше википедии читать не умеем?
Эта задача решается доверенным надежным посредником (координатором).
Re[18]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, DOOM, Вы писали:
DOO>>Здравствуйте, gandjustas, Вы писали:
G>>>Вроде существуют способы сделать 100% транзакционность в распределенной среде.
DOO>>Нет.
G>Дальше википедии читать не умеем?
Умеем. Если я привел ссылку на википедию это не значит, что я только ее там прочитал. Задача упомянута в книге Танненбаума "Компьютерные сети", если что.
G>Эта задача решается доверенным надежным посредником (координатором).
Во-первых, это будет уже другая задача.
Во-вторых, у тебя возникает та же самая задача при общении с твоим надежным посредником.
Поэтому, если ты считаешь, что решение есть — приведи хоть какое-то его описание — посмотрим, что же оно решает на самом деле.
Re[20]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, gandjustas, Вы писали:
G>>>Эта задача решается доверенным надежным посредником (координатором). DOO>>Во-первых, это будет уже другая задача. G>Читай до просветления "Вроде существуют способы сделать 100% транзакционность в распределенной среде."
Дальше что?
Прагматичный подход к решению задачи предполагает не полное устранение ненадежности канала, а её сведение к допустимому уровню.
DOO>>Во-вторых, у тебя возникает та же самая задача при общении с твоим надежным посредником. G>Читай выделенное до просветления "Эта задача решается доверенным надежным посредником".
Не наступает просветления — у нас канал ненадежен. Посредник может хоть мамой клясться, но на канал он не влияет.
DOO>>Поэтому, если ты считаешь, что решение есть — приведи хоть какое-то его описание — посмотрим, что же оно решает на самом деле. G>WS-Atomic, MS DTC.
Это описание? По-моему, это названия конкретных систем, реализующих очень простой и примитивный механизм: есть кто-то, кто дает отмашку — причем непонятно, получили ли эту отмашку все участники. Вся их надежность заключается в том, что они ничего не забывают — т.е. рано или поздно ситуация придет в норму. Но в промежуток — все плохо.
Ситуация с банкоматом:
банкомат и сервер должны совместно выполнить транзакцию по списыванию и выдаче денег. Пусть ее ведет твой надежный координатор. Типа того же DTC.
Банкомат и сервер подтвердили готовность. Координатор дал отмашку. Банкомат выдал деньги и тут упала сеть. Что делать? Координатор не знает получена ли его отмашка банкоматом — т.е. он не знает выданы деньги или нет. То, что система придет в нормальное состояние, когда сеть восстановится — я понимаю, но в промежуток ничего не понятно — если ты транзакцию откатишь, а банкомат деньги выдал, то пользователь снимет те же самые деньги в соседнем банкомате, если ты транзакцию подтвердишь, а банкомат денег не выдал, то ты спишешь деньги со счета пользователя и он не сможет их взять в другом банкомате. Если ты будешь ждать и на это время заморозишь операции со счетом — то пользователь тебе придет бить морду.
Вот такие они "надежные" распределенные транзакции.
Re[23]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, gandjustas, Вы писали:
G>>Я ен говорю про конкретно задачу двух генералов, я говорю о решении общей проблемы. G>>Если ты хочешь свести её к задаче двух генералов, то у тебя 100% гарантии не будет. DOO>Это всегда будет сводиться к задаче о двух генералах.
У тебя — может быть.
DOO>>>Не наступает просветления — у нас канал ненадежен. Посредник может хоть мамой клясться, но на канал он не влияет. G>>Ты слово "надежный" понимаешь? DOO>Дальше что? каналненадежен.
Всегда чтоли? Вот TCP надежен, хотя работает поверх ненадежного IP.
Если принять за аксиому что все каналы ненадежны то ничего не поможет. Но в реальном мире создают надежные каналы поверх ненадежных.
DOO>>>Ситуация с банкоматом: DOO>>>банкомат и сервер должны совместно выполнить транзакцию по списыванию и выдаче денег. Пусть ее ведет твой надежный координатор. Типа того же DTC. DOO>>>Банкомат и сервер подтвердили готовность. Координатор дал отмашку. Банкомат выдал деньги и тут упала сеть. Что делать? Координатор не знает получена ли его отмашка банкоматом — т.е. он не знает выданы деньги или нет. То, что система придет в нормальное состояние, когда сеть восстановится — я понимаю, но в промежуток ничего не понятно — если ты транзакцию откатишь, а банкомат деньги выдал, то пользователь снимет те же самые деньги в соседнем банкомате, если ты транзакцию подтвердишь, а банкомат денег не выдал, то ты спишешь деньги со счета пользователя и он не сможет их взять в другом банкомате. Если ты будешь ждать и на это время заморозишь операции со счетом — то пользователь тебе придет бить морду.
DOO>>>Вот такие они "надежные" распределенные транзакции.
G>>В ситуации с банкоматом выдаватель денег не транзакционен. Если ты забрал из банкомата каким-либо образом хотябы одну бумажку вернуть ее не получится. Откат невозможен. DOO>Откат невозможен всегда, когда уже прошел commit. Т.е. при отсутствии информации надо либо ждать ее появления (вариант 3), либо принимать какое-то решение без необходимой информации (варианты 1 и 2).
Можно и так счиатать, тогда в случае с банкоматом commit происходит не по желанию системы, а под воздействием внешних факторв (которые нельзя направить через координатор). Это транзакционность компонента в рамках системы нарушает.
G>>В ситуации с двумя генералами это аналогично тому что одной из армий вешестоящее командование прикажет атаковать, незавиимо от того дошло ли сообщение до дргуой армии. DOO>Но поскольку атаковать надо все равно — поэтому и приходится совершать транзакцию без 100% уверенности в ее согласованности. И не может быть 100% уверенности.
Только транзакционностью тут уже не пахнет.
Re[18]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, March_rabbit, Вы писали:
M_>>не нравится количество повторяющихся строк. Ибо это — неизбужный копипаст. А в копипасте главное — меньший объем, чтобы увереннее его проверить. CC>Зато строки проще. Да и в конкретном случае это несущественно.
CC>>>Но и не считаю что присвоение в условии неправильно. M_>>Разрешено синтаксисом языка, значит может применяться. CC>Именно
M_>>Гм. Это смотря как вбить. Новичок после этого может и не развиться, останется в этих рамках, даже не умея объяснить, что здесь неправильно. Ибо это как правило "не выходи на улицу без шапки — сонлнце голову напечет"... CC>А это уже зависит от интеллекта новичка. Если развиться не сможет, значит пусть хоть через табу будет убережён от тупых ошибок. CC>Ты вспомни как даётся та же химия в школе и в универе: в школе все на очень простой модели, в универе: "забудьте все чему вас учили в школе" и пошли рассказывать как оно на самом деле работает.
Кстати, математика так же. По крайней мере на мехмате.
Re[2]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, _d_m_, Вы писали: ___>>Виртовские? Pascal и C#? S>С# к Вирту никакого отношения не имеет. Это ты с прямым углом перепутал.
Ой, таки да. С Хайлсбергом перепутал.
Re[5]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Pzz, Вы писали:
Pzz>Можно отлавливать алгоритмы, у которых "вилка не подошла к розетке". Но как вы поймаете, с помощью какой угодно системы типов, ситуацию, когда вам, грубо говоря, надо было взять среднее квадратичное, а вы взяли среднее арифметическое?
Ты удивишься но это при желании тоже можно свести к "вилка не подошла к розетке".
Вопрос лишь в том насколько это критично в данной конкретной задаче.
Pzz>То, что находится между программой и операционной системе, if any.
Ты про компилятор что ли?
На самом деле грань между заранее скомпилированной программой и отJITеной программой настолько тонка что тут и говорить не о чем.
WH>>Устранение некоторых классов ошибок == меньше ошибок при тех же усилиях. Pzz>Зато оставшиеся ошибки становятся гораздо более заковыристыми
Одно из другого не следует.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Модульные тесты и "безопасные" языки - хорошо.
WH>>На самом деле грань между заранее скомпилированной программой и отJITеной программой настолько тонка что тут и говорить не о чем.
Pzz>Я сказал простую вещь: понятия "безопасного" языка и "управляемого" языка ортогональны.
Глупость. Pzz>Можно сделать безопасный язык, который статически компилируется в машинный код, можно сделать управляемый язык, который будет небесопасен (правда, второе непонятно зачем делать). Я ничего не сказал при этом относительно связанного с JIT-ом оверхеда. Против того, что я сказал, какие-нибудь возражения по существу имеются?
Ну вперед — сделайте. За 50+ лет до Вас не смогли. Удачи.
WH>>>>Устранение некоторых классов ошибок == меньше ошибок при тех же усилиях. Pzz>>>Зато оставшиеся ошибки становятся гораздо более заковыристыми WH>>Одно из другого не следует.
Pzz>Вы получаете инструмент, позволяющий со сравнимым уровнем усилий делать более сложные конструкции. А чем сложнее конструкция, тем более заковыристую ошибку в ней можно посадить.
То есть когда Вы получаете ТЗ от заказчика, то отбрасываете половину со словами "мы этого делать не будем — наш инструмент нам не позволяет"?
Очень смешно.
Re[13]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
Pzz>>У программиста появляется больше времени делать более хитрые ошибки.
C>У программиста появляется больше времени НЕ делать хитрые (и не очень) ошибки.
Ну так и где этот безглючный софтварий, написанный с помощью современного безопасного инструментария.
Re[13]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
Pzz>>Ну а обосновать? C>Сначала Вы.
Я обосновал.
Pzz>>Чего сделать не смогли? C>Вы что же забыли что писали тремя строчками выше? C>"Можно сделать безопасный язык, который статически компилируется в машинный код, можно сделать управляемый язык, который будет небесопасен (правда, второе непонятно зачем делать)."
LISP, Ocaml, Haskell — умеют компилироваться в машинный код и при этом безопасны.
Pzz>>Сделать по-разному можно.
C>То есть Вы понимаете какую глупость тут сморозили?
Нет, не понимаю. Объясните.
Re[5]: Модульные тесты и "безопасные" языки - хорошо.
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 должно быть получено в рантайм (пользовательский ввод, или на основе какой-то логики).
В этом случае надо проверять что ввёл пользователь. И делать это надо при работе с любым языком. Пользователю всё равно, что случится — бесконечный цикл или исключение будет кинуто, ему надо объяснить, что от него требуется и дать возможность ввести данные ещё раз.
Если ты приводишь такой пример, то наверное ты так и пишешь.
В С++ не является хорошим тоном использовать голые указатели, динамические массивы, не инициализированные переменные, передача по указателю там, где не требуется.
Re[7]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
M>>Будут ошибки, связанные не с манипуляцией указателями, а с манипуляцией индексами. Если код перевести на C#, то ошибка никуда не исчезнет, но сразу проявится при запуске.
C>Не будет ошибки — трудноуловимого бага, как в С++, будет исключение с сообщением о том, что индекс за пределами диапазона.
Точно такой же bullshit. При тестировании у тебя не вылетает, и в продакшн идет подукт с этим багом. Вот клиенту полегчает от эксепшена.
Да еще если код у тебя без debug-info, да еще если обфускированный, то сообщение об ошибке не поможет локализовать ситуацию даже через user feedback.
Re[2]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Antikrot, Вы писали:
C>>"Прелесть" С++ (кто представляет себе ассемблерный код после компиляции поймет что в таком случае произойдет): C>>
C>>int i;
C>>int array[4];
C>>for (int i = 0; i <= 4; i++) {
C>> array[i]=0;
C>>}
C>>
C>>(подсказка: бесконечный цикл) A>далеко не самый наглядный пример, если кто захочет проверить вероятность что счётчик цикла окажется сразу за array[3] и не будет загнан в регистр очень сильно не 100% A>компилятор + опции?
Важно другое — важно, что сильно не 0%, что счетчик не окажется сразу за array[3] и не будет перезаписан 0.
Прямой доступ к памяти и ручные манипуляции указателями это бомба с часовым механизмом.
Re[3]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>Важно другое — важно, что сильно не 0%, что счетчик не окажется сразу за array[3] и не будет перезаписан 0. C>Прямой доступ к памяти и ручные манипуляции указателями это бомба с часовым механизмом.
а типа в C# ты не допускаешь использование unsafe кода с указателями при обработке больших массивов и получения всяких нехорошестей?
Re: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>У кого еще остались сомнения в целесообразности модульных тестов, в целесообразности использования языков/платформ с большим количеством статических и динамических проверок...
настоящие джедаи используют С++ со включением всех runtime checks и статический анализатор кода
Re[2]: Модульные тесты и "безопасные" языки - хорошо.
C>>У кого еще остались сомнения в целесообразности модульных тестов, в целесообразности использования языков/платформ с большим количеством статических и динамических проверок...
A>настоящие джедаи используют С++ со включением всех runtime checks и статический анализатор кода
Ну и какой компилятор С++ поможет в вышеуказанном случае?
Re[4]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Antikrot, Вы писали:
C>>Важно другое — важно, что сильно не 0%, что счетчик не окажется сразу за array[3] и не будет перезаписан 0. C>>Прямой доступ к памяти и ручные манипуляции указателями это бомба с часовым механизмом. A>а типа в C# ты не допускаешь использование unsafe кода с указателями при обработке больших массивов и получения всяких нехорошестей?
unsafe крайне редкое явление и там, где его применяют, куда как хорошо понимают чем это чревато, а потому вдвойне внимательно тестируют такой код.
Re[3]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>>>У кого еще остались сомнения в целесообразности модульных тестов, в целесообразности использования языков/платформ с большим количеством статических и динамических проверок... A>>настоящие джедаи используют С++ со включением всех runtime checks и статический анализатор кода C>Ну и какой компилятор С++ поможет в вышеуказанном случае?
а почему обязательно компилятор? тебе же религия не запрещает пользоваться fxcop-ом. вот и тут можно взять внешний bounds checker какой-нибудь.
впрочем... код такой — массив никуда не выносил:
#include <stdio.h>
int main()
{
int i;
int array[4];
for (int i = 0; i <= 4; i++) {
array[i]=0;
}
for(int k = 0; k < 4; k++)
{printf("%d ",array[k]);}
}
статически:
icl -Qdiag-enable:sc test.cpp
C:\temp>icl /Qdiag-enable:sc test.cpp
test.cpp
test.cpp(7): error #12049: Buffer overflow: array index of "array" is possibly o
utside the bounds; array "array" of size (0:3) can be indexed by value 4
динамически:
icl -RTC1 test.cpp
test.exe
выбрасывает в отладчик (если он есть конечно)
Re[5]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>Потому, что управляемые языки ИСКЛЮЧАЮТ "ДТП", связанные, с этим (манипуляция указателей) классом ошибки.
Будут ошибки, связанные не с манипуляцией указателями, а с манипуляцией индексами. Если код перевести на C#, то ошибка никуда не исчезнет, но сразу проявится при запуске.
Re[4]: Модульные тесты и "безопасные" языки - хорошо.
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 length = 4;
C>>int *arr = new int[length];
C>>...
C>>length++;
C>>...
C>>myFoo(arr, length);
C>>
C>>В std есть lambda? С каких пор? V>В tr есть. А еще есть буст.
Ни то, ни другое пока не стандарт, а следовательно пременимо далеко не везде. Не говоря уж о МАССЕ legacy кода.
Re[5]: Модульные тесты и "безопасные" языки - хорошо.
C>ccode] 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 length = 4; C>>>int length; std::cin >> length; C>>>int *arr = new int[length]; C>>>... C>>>length++; C>>>... C>>>myFoo(arr, length); C>>>[/ccode]
C>Давайте без самодеятельности, ок? length должно быть получено в рантайм (пользовательский ввод, или на основе какой-то логики).
Тогда это пишется так:
void myFoo(std::vector<int> &vec)
{
for (std::vector<int>::const_iterator it = vec.begin(), end = vec.end(); it != end; it++) {
*it = 0;
}
}
std::vector<int> arr(length);
myFoo(arr);
Хотя, как я уже сказал, разумный человек использует лямбду.
Да здравствует мыло душистое и веревка пушистая.
Re: Модульные тесты и "безопасные" языки - хорошо.
C>У кого еще остались сомнения в целесообразности модульных тестов, в целесообразности использования языков/платформ с большим количеством статических и динамических проверок...
C>http://habrahabr.ru/blogs/lifehack/64627/
C>"Прелесть" С++ (кто представляет себе ассемблерный код после компиляции поймет что в таком случае произойдет): C>
C>int i;
C>int array[4];
C>for (int i = 0; i <= 4; i++) {
C> array[i]=0;
C>}
C>
C>(подсказка: бесконечный цикл)
Неверно. UB. Вполне возможно, что просто ничего не будет.
/* temp.cpp */void func()
{
int i;
int array[4];
for (int i = 0; i <= 4; i++) {
array[i]=0;
}
}
; Listing generated by Microsoft (R) Optimizing Compiler Version 15.00.21022.08
TITLE d:\2009\MagiC_1_00\CCore\test\temp.cpp
.686P
.XMM
include listing.inc
.model flat
INCLUDELIB LIBCMT
PUBLIC ?func@@YAXXZ ; func
; Function compile flags: /Ogtpy
; File d:\2009\magic_1_00\ccore\test\temp.cpp
; COMDAT ?func@@YAXXZ
_TEXT SEGMENT
?func@@YAXXZ PROC ; func, COMDAT
; 5 : int i;
; 6 :
; 7 : int array[4];
; 8 : for (int i = 0; i <= 4; i++) {
; 9 : array[i]=0;
; 10 : }
; 11 : }
ret 0
?func@@YAXXZ ENDP ; func
_TEXT ENDS
END
Здравствуйте, Vamp, Вы писали:
C>>ccode] 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 length = 4; C>>>>int length; std::cin >> length; C>>>>int *arr = new int[length]; C>>>>... C>>>>length++; C>>>>... C>>>>myFoo(arr, length); C>>>>[/ccode]
C>>Давайте без самодеятельности, ок? length должно быть получено в рантайм (пользовательский ввод, или на основе какой-то логики). V>Тогда это пишется так:
V>
V>void myFoo(std::vector<int> &vec)
V>{
V> for (std::vector<int>::const_iterator it = vec.begin(), end = vec.end(); it != end; it++) {
V> *it = 0;
V> }
V>}
V>std::vector<int> arr(length);
V>myFoo(arr);
V>
Код неверный. std::vector<int>::const_iterator
Лучше так
int array[444];
Range(array).set_null();
V>Хотя, как я уже сказал, разумный человек использует лямбду.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Pzz, Вы писали:
Pzz>>Здравствуйте, criosray, Вы писали:
C>>>У кого еще остались сомнения в целесообразности модульных тестов, в целесообразности использования языков/платформ с большим количеством статических и динамических проверок...
Pzz>>Я где-то читал, что повсеместное введение автомобильных ремней безопасности не снизило количество смертей на дорогах: люди почувствовали себя "безопаснее" и стали ездить быстрее.
KV>Ой, а можно с контр-аналогией встряну? Спасибо.
KV>Когда в ПДД, водителей мотоциклов обязали едить в шлеме, травматизм в стране резко вырос. Стали разбираться че за фигня. И вопреки очевидному мнению, что люди стали ездить небрежнее, чувствуя себя в большей защищенности, выяснилась несколько другая вещь. Травматизм действительно вырос, т.к. раньше люди тупо убивались насмерть и портили статистику моргам, а не отделениям травматологии.
KV>"Так-то" (с)
одно не ясно — почему они все вместе не портили статистику ментам, как пострадавшие в аварии?
Re: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>"Прелесть" С++ (кто представляет себе ассемблерный код после компиляции поймет что в таком случае произойдет): C>
C>int i;
C>int array[4];
C>for (int i = 0; i <= 4; i++) {
C> array[i]=0;
C>}
C>
Если уж быть совсем точным, то это "прелесть" C. А в C++ есть std::vector который не позволяет выходить за границу массива.
P.S. Ты еще приведи ассемблерные вставки и рассажи как легко в С++ можно испортить стек\регистры...
UNIX way — это когда тебе вместо туалетной бумаги дают топор, рубанок и карту близлежащего леса
Re[2]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Pzz, Вы писали:
C>>У кого еще остались сомнения в целесообразности модульных тестов, в целесообразности использования языков/платформ с большим количеством статических и динамических проверок...
Pzz>Я где-то читал, что повсеместное введение автомобильных ремней безопасности не снизило количество смертей на дорогах: люди почувствовали себя "безопаснее" и стали ездить быстрее.
Т.е. повысив скорость смертность не увеличили.
Pzz>Внедрение безопасных методик и инструментов может повысить продуктивность и качество каждого из нас, уже сложившихся программистов, но не увеличит качество индустрии в целом. Продуктивность может и увеличит, за счет снижения требований к квалификации работников.
Т.е. увеличив количество решаемых задач/уменьшив время на разработку/уменьшив стоимость разработки надёжность не уменьшится.
Re[3]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>>>(подсказка: бесконечный цикл) M_>>садитесь, два. M_>>Если бы Вы знали, как работает стэк, то поняли бы, что запись в array[4] затрет внешнюю (по отношению к циклу) переменную i, и никаким образом на количестве итераций не скажется. C>Опечатка конечно подразумевалось for (i = 0;
не-не, изначальный вариант тоже может вызвать зацикливание (при определенных условиях).
Re[2]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, landerhigh, Вы писали:
C>>"Прелесть" С++ (кто представляет себе ассемблерный код после компиляции поймет что в таком случае произойдет): C>>
C>>int i;
C>>int array[4];
C>>for (int i = 0; i <= 4; i++) {
C>> array[i]=0;
C>>}
C>>
L>Что ж вы так убиваетесь? Вы так никогда не убъетесь! L>А еще можно format c: сделать.
#include <stdio.h>
#include <stdlib.h>
int i;
void func2()
{
system("формат це:");
}
void func1()
{
int array[4];
for (i = 0; i <= 6; i++) { //увеличивать верхний предел пока не будет достигнут результат
array[i]=(int)func2;
}
for(int k = 0; k < 4; k++) //чтоб компилятор не прибил всё как dead code
{printf("%d",array[k]);}
}
int main()
{
func1();
}
Re[2]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, catBasilio, Вы писали:
B>Если уж быть совсем точным, то это "прелесть" C. А в C++ есть std::vector который не позволяет выходить за границу массива. B>P.S. Ты еще приведи ассемблерные вставки и рассажи как легко в С++ можно испортить стек\регистры...
ага
типа __asm mov esp, eax; // БДЫЩ!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[7]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>Не будет ошибки — трудноуловимого бага, как в С++, будет исключение с сообщением о том, что индекс за пределами диапазона.
Ну не настолько и трудноуловимого. Добавить проверку выхода индекса за пределы диапазона не так уж и сложно, да и она живет во многих нативных языках. Во многих случаях, если поврежден хип, то сообщение об этом будет после завершения сеанса программы. Если для тебя такие ошибки кажутся жутко трудноуловимыми, то наверное действительно тебе надо писать на безопасных языках.
На моей памяти подобная трудноуловимая ошибка с выходом за пределы диапазона, когда я потратил пару дней на ее исправление, была в далеком 2001 году, но там набор инструментов был DOS, библиотека RTKernel и компилятор Borland C++ 3.1 (который использовался как чистый C). С тех пор да, такие ошибки возникают, но исправляются в рабочем порядке.
Re[3]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, yoriсk.kiev.ua, Вы писали:
Pzz>>Внедрение безопасных методик и инструментов может повысить продуктивность и качество каждого из нас, уже сложившихся программистов, но не увеличит качество индустрии в целом. Продуктивность может и увеличит, за счет снижения требований к квалификации работников.
YKU>Т.е. увеличив количество решаемых задач/уменьшив время на разработку/уменьшив стоимость разработки надёжность не уменьшится.
А зря радуетесь. Думаете, стоимость разработки понизится за счет того, что вы будете быстрее разрабатывать? Фигвам, стоимость понизится за счет того, что на ваше место наймут кого-нибудь менее квалифицированного и более дешевого.
Re[10]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Pzz, Вы писали: Pzz>Транзакции, как известно, могут гарантировать что-то одно из двух.
Не понял. Как известно, транзакции как раз и сделаны для того, чтобы гарантировать ровно 2 из двух. Разве нет?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Модульные тесты и "безопасные" языки - хорошо.
CC>в любом случае тут за length++ положено канделябром по башке.
О чем, собственно, и шла речь.
Человеку свойственно ошибаться. В С++ ошибки трудноуловимы и их гораздо легче допустить в виду относительной низкоуровневости языка.
V>>>Ну и в последних, писать итеративные циклы в С++, где есть for_each, bind и lambda — каменный век. C>>В std есть lambda? С каких пор? CC>С недавних.
Еще нету не выдумывайте. Самодеятельность отдельных компиллятор в расчет не берем.
Re[6]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, iHateLogins, Вы писали:
C>>>>Я на С++ писал не меньше, а то и побольше Вашего. A>>>если судить по этому форуму, то пИсал ты на него больше, чем все остальный тут вместе взятые C>>Я не пИсал на него, как Вы выражаетесь. Просто я, имея нескромный опыт программирования на самых разных языках и парадигмах, понимаю на сколько убог этот язык.
HL>А что ты такого замечательного писал, а? Сайтик для дяди васи или автоматизацию ларька?
Это все, что Вы способны придумать? Слабова-то.
Re[2]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Хвост, Вы писали:
Х>P.S. Х>я конечно понимаю что тебе С++ в детстве на ухо наступил, но всё же вот тебе домашнее задание — подумать почему же Lockheed Martin пишут софт для всяких там шаттлов и стелсов на С++. И ещё подумать почему у них в среднем одна ошибка на полмиллиона строк кода.
А еще стоит посчитать затраты на строку кода.
Никто ведь не говорит что нельзя на С++ написать надежную программу. Это можно сделать, но это гораздо дороже выйдет.
Re[6]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, CreatorCray, Вы писали:
C>>Человеку свойственно ошибаться. В С++ ошибки трудноуловимы и их гораздо легче допустить в виду относительной низкоуровневости языка. CC>Данная ошибка следствие бардака в голове. Какое отношение идиотизм разработчика имеет к языку?
C>>>>В std есть lambda? С каких пор? CC>>>С недавних. C>>Еще нету не выдумывайте. Самодеятельность отдельных компиллятор в расчет не берем. CC>Имплементация С++0х не есть самодеятельность.
Пока С++0x draft — есть самодеятельность.
Re[7]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>>>Человеку свойственно ошибаться. В С++ ошибки трудноуловимы и их гораздо легче допустить в виду относительной низкоуровневости языка. CC>>Данная ошибка следствие бардака в голове. Какое отношение идиотизм разработчика имеет к языку? C>Открываем первый пост. Идем по ссылке и внимательно читаем. Потом думаем. Если по прежнему не понятно — еще ра читаем и еще раз думаем.
Не переводи тему!
Твой пример с length++ никоим образом не связан с "пробелами вместо нулей" в шапке темы.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[5]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, Vamp, Вы писали:
C>>>Напишет.
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 length = 4;
C>>>int *arr = new int[length];
C>>>...
C>>>length++;
C>>>...
C>>>myFoo(arr, length);
C>>>
C>>>В std есть lambda? С каких пор? V>>В tr есть. А еще есть буст. C>Ни то, ни другое пока не стандарт, а следовательно пременимо далеко не везде. Не говоря уж о МАССЕ legacy кода.
И как же, например, .net в данном случае поможет преодолеть проблемы legacy кода ? Если переписывать legacy код, то вполне возможно что вариант с бустом и tr-1 вполне приемлем.
На самом деле коллеги абсолютно правы, так писать нельзя, да и лямбды тут нафиг ненужны.
Вот вполне кошерный вариант без буста и tr :
std::vector<int> arr(length); //можно eще и инициализировать чем нибудь сразу - std::vector<int> arr(length,2);
std::fill(arr.begin(),arr.end(),0);
Re[12]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Sinclair, Вы писали:
Pzz>>>Транзакции, как известно, могут гарантировать что-то одно из двух. S>>Не понял. Как известно, транзакции как раз и сделаны для того, чтобы гарантировать ровно 2 из двух. Разве нет?
Pzz>Нет. Вы не знаете наверняка, не успел банкомат деньги выдать, или не успел сообщить серверу об их выдаче. И так на любом этапе.
Это уже съезжаешь с темы, юлишь.
Ведь мы рассматриваем разницу в софте так? Если конечно деньги застрянут в купюродтатчике (или как его там) — здесь софт не поможет. Хотя и там существуют какие-либо датчики, которые могут участвовать в транзакции.
Так вот при исключении мы можем спокойно ролбэкнуть транзакцию. А в случае трудноуловимого бага — мы просто можем получить неконсистентые данные в БД, а заметим это лишь значительно позже.
запросить сумму;
Tran.Begin();
try
{
вычесть сумму в БД; // здесь может быть исключение
выдать в купюроотдатчик; // и здесь
Tran.Commit();
}
catch(...)
{
Tran.Rollback();
throw; -- исключение полетело по иерархии выше
}
Re[13]: Модульные тесты и "безопасные" языки - хорошо.
___>запросить сумму;
___>Tran.Begin();
___>try
___>{
___> вычесть сумму в БД; // здесь может быть исключение
___> выдать в купюроотдатчик; // и здесь
дождаться сигнала от банкомата, что деньги были выбраны из купюроотдатчика
если таймаут и купюроотдатчик заглотил деньги, то Tran.Rollback();
___> Tran.Commit();
___>}
___>catch(...)
___>{
___> Tran.Rollback();
___> throw; -- исключение полетело по иерархии выше
___>}
___>
Re[14]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C> дождаться сигнала от банкомата, что деньги были выбраны из купюроотдатчика C> если таймаут и купюроотдатчик заглотил деньги, то Tran.Rollback();
А сколько он их заглотил? Может я одну купюру незаметно утянул?
Re[15]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, WFrag, Вы писали:
C>> дождаться сигнала от банкомата, что деньги были выбраны из купюроотдатчика C>> если таймаут и купюроотдатчик заглотил деньги, то Tran.Rollback();
WF>А сколько он их заглотил? Может я одну купюру незаметно утянул?
А Вы попробуйте.
Re[13]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, _d_m_, Вы писали:
___>Это уже съезжаешь с темы, юлишь. ___>Ведь мы рассматриваем разницу в софте так? Если конечно деньги застрянут в купюродтатчике (или как его там) — здесь софт не поможет. Хотя и там существуют какие-либо датчики, которые могут участвовать в транзакции.
Мы тут имеем дело не с софтом, а как минимум с двумя софтами, взаимодействующими по электрическим сетям связи
И то, что одна сторона поймает исключение и прервет транзакцию не означает, что другая сторона об этом узнает. С этим можно бороться всякими многоуровневыми хендшейками, но все равно кто-то должен сказать последнее слово, на которое уже не ожидается подтверждающий ответ.
Поэтому гарантировать можно что-то одно из двух: либо что операция случится не более одного раза, либо что не менее одного раза. Но невозможно гаратнировать одновременно и то и то.
Re[16]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>>> дождаться сигнала от банкомата, что деньги были выбраны из купюроотдатчика C>>> если таймаут и купюроотдатчик заглотил деньги, то Tran.Rollback();
WF>>А сколько он их заглотил? Может я одну купюру незаметно утянул?
C>А Вы попробуйте.
Не хочется с банком потом разбираться. Камера же ещё снимает. Не вижу проблем придержать пачку денег и дернуть одну купюру.
А вообще, если банкомат обратно заглатывает деньги, то на счёт-то он их не возвращает (надо писать заявление в банк). Так что по факту там нет rollback. Возможно, это зависит от банка/банкомата.
iHateLogins wrote:
> Нет, это не всё. Ты давай ответь по существу, что такого замечательного ты написал на (C#? > java?), что ты говоришь о C++, как о "убогом" языке?
Судя о том что тут уже 4 дня нету ответов — ты попал в самую точку
Здравствуйте, Sheridan, Вы писали:
>> Нет, это не всё. Ты давай ответь по существу, что такого замечательного ты написал на (C#? >> java?), что ты говоришь о C++, как о "убогом" языке?
S>Судя о том что тут уже 4 дня нету ответов — ты попал в самую точку
Шеридан, Вы уже разобрались с тернарным оператором?
criosray wrote:
> S>Судя о том что тут уже 4 дня нету ответов — ты попал в самую точку > Шеридан, Вы уже разобрались с тернарным оператором?
Ой, и правда страшное слово. Рычащее, тупоносое...
Posted via RSDN NNTP Server 2.1 beta
Matrix has you...
Re[14]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, _d_m_, Вы писали:
___>>Это уже съезжаешь с темы, юлишь. ___>>Ведь мы рассматриваем разницу в софте так? Если конечно деньги застрянут в купюродтатчике (или как его там) — здесь софт не поможет. Хотя и там существуют какие-либо датчики, которые могут участвовать в транзакции.
Pzz>Мы тут имеем дело не с софтом, а как минимум с двумя софтами, взаимодействующими по электрическим сетям связи
Это называется — распределенная транзакция. Ничего экстраординарного.
Pzz>И то, что одна сторона поймает исключение и прервет транзакцию не означает, что другая сторона об этом узнает. С этим можно бороться всякими многоуровневыми хендшейками, но все равно кто-то должен сказать последнее слово, на которое уже не ожидается подтверждающий ответ.
Нам хэндшейки нужны только на Commit-e. Больше нигде. Серверу вообще пофиг — что там у клиента исключение или что еще. Ему дали команду списать деньги, а дальше одно из двух — либо комит, либо ролбэк.
Всего-то надо:
— клиенту знать, что комит успешен;
— серверу, что клиент получил уведомление об успешности комита — вот тогда наступает реальный комит.
Pzz>Поэтому гарантировать можно что-то одно из двух: либо что операция случится не более одного раза, либо что не менее одного раза. Но невозможно гаратнировать одновременно и то и то.
Ну конечно 100% нет. Но с учетом вышесказанного мной, здесь мы уже переходим в раздел вероятностей, где обезьяны печатают "Война и мир" случайными нажатиями.
Re[15]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, _d_m_, Вы писали:
___>Ну конечно 100% нет. Но с учетом вышесказанного мной, здесь мы уже переходим в раздел вероятностей, где обезьяны печатают "Война и мир" случайными нажатиями.
Вроде существуют способы сделать 100% транзакционность в распределенной среде.
Re[17]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, _d_m_, Вы писали:
___>>>Ну конечно 100% нет. Но с учетом вышесказанного мной, здесь мы уже переходим в раздел вероятностей, где обезьяны печатают "Война и мир" случайными нажатиями.
G>>Вроде существуют способы сделать 100% транзакционность в распределенной среде.
___>Не верю! Невозможно.
Ну почему же, возможно, если речь о простом терминале, коим и является по сути банкомат. Транзакция коммитится только в случае, если от банкомата пришло подтверждение, что клиент забрал деньги из лотка.
Re[18]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>Ну почему же, возможно, если речь о простом терминале, коим и является по сути банкомат. Транзакция коммитится только в случае, если от банкомата пришло подтверждение, что клиент забрал деньги из лотка.
Ага. Банкомат выдаёт деньги в лоток, сеть отрубается, клиент забирает деньги, транзакция на сервере откатывается. Круто.
Re[17]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, _d_m_, Вы писали:
___>>>Ну конечно 100% нет. Но с учетом вышесказанного мной, здесь мы уже переходим в раздел вероятностей, где обезьяны печатают "Война и мир" случайными нажатиями.
G>>Вроде существуют способы сделать 100% транзакционность в распределенной среде.
___>Не верю! Невозможно.
Координатор транзакций, которому доверяют все участники процесса, вроде как решает такую проблему.
Здравствуйте, Antikrot, Вы писали:
A>Здравствуйте, criosray, Вы писали:
C>>>>(подсказка: бесконечный цикл) M_>>>садитесь, два. M_>>>Если бы Вы знали, как работает стэк, то поняли бы, что запись в array[4] затрет внешнюю (по отношению к циклу) переменную i, и никаким образом на количестве итераций не скажется. C>>Опечатка конечно подразумевалось for (i = 0; A>не-не, изначальный вариант тоже может вызвать зацикливание (при определенных условиях).
при каких?
Re[19]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, WFrag, Вы писали:
C>>Ну почему же, возможно, если речь о простом терминале, коим и является по сути банкомат. Транзакция коммитится только в случае, если от банкомата пришло подтверждение, что клиент забрал деньги из лотка.
WF>Ага. Банкомат выдаёт деньги в лоток, сеть отрубается, клиент забирает деньги, транзакция на сервере откатывается. Круто.
А если подумать?
А если подумать, то при откате транзакции сумма блокируется до выяснения обстоятельств.
Re[20]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>>>Ну почему же, возможно, если речь о простом терминале, коим и является по сути банкомат. Транзакция коммитится только в случае, если от банкомата пришло подтверждение, что клиент забрал деньги из лотка.
WF>>Ага. Банкомат выдаёт деньги в лоток, сеть отрубается, клиент забирает деньги, транзакция на сервере откатывается. Круто.
C>А если подумать? C>А если подумать, то при откате транзакции сумма блокируется до выяснения обстоятельств.
Имелось в виду при обрыве связи с банкоматом.
Re[3]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, March_rabbit, Вы писали:
C>>>http://habrahabr.ru/blogs/lifehack/64627/
C>>>"Прелесть" С++ (кто представляет себе ассемблерный код после компиляции поймет что в таком случае произойдет): C>>>
C>>>int i;
C>>>int array[4];
C>>>for (int i = 0; i <= 4; i++) {
C>>> array[i]=0;
C>>>}
C>>>
C>>>(подсказка: бесконечный цикл) M_>>садитесь, два. M_>>Если бы Вы знали, как работает стэк, то поняли бы, что запись в array[4] затрет внешнюю (по отношению к циклу) переменную i, и никаким образом на количестве итераций не скажется. C>Опечатка конечно подразумевалось for (i = 0; C>Если Вам нравится цепляться к словам, то и я прицеплюсь к Вашим: в языке С конструкция for (int i;... синтаксически некорректна. C>Садитесь, два.
не удалось перевести тему (смотрим выделенное). Так что, не сяду
Ну а насчет придирок к словам — если в результате ошибки в словах получается неверный вывод — то следует придираться. Не было бы далекоидущих выводов — я бы и времени на ответ тратить не стал.
Да и вообще, код безграмотный. С таким подходом в любом языке можно наваять фигню, послое чего смело утверждать, что язык — г....
Re[20]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>А если подумать? C>А если подумать, то при откате транзакции сумма блокируется до выяснения обстоятельств.
Тогда другой вариант. Из всей пачки денег клиент выдергивает 1 купюру из середины. Банкомат забирает деньги обратно, дальше что? Он их пересчитывать будет?
Re[4]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, March_rabbit, Вы писали:
M_>Да и вообще, код безграмотный. С таким подходом в любом языке можно наваять фигню, послое чего смело утверждать, что язык — г....
С той разницей, что на С++ это гораздо легче сделать и сложнее отладить.
Re[21]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, WFrag, Вы писали:
C>>А если подумать? C>>А если подумать, то при откате транзакции сумма блокируется до выяснения обстоятельств.
WF>Тогда другой вариант. Из всей пачки денег клиент выдергивает 1 купюру из середины. Банкомат забирает деньги обратно, дальше что? Он их пересчитывать будет?
Датчики это тут же зафиксируют.
Re[22]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
WF>>Тогда другой вариант. Из всей пачки денег клиент выдергивает 1 купюру из середины. Банкомат забирает деньги обратно, дальше что? Он их пересчитывать будет? C>Датчики это тут же зафиксируют.
Датчики чего? Я вот не могу придумать способа заметить, что из середины что-то выдернули, не пересчитывая.
Re[5]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, March_rabbit, Вы писали:
C>>>>>(подсказка: бесконечный цикл) M_>>>>садитесь, два. M_>>>>Если бы Вы знали, как работает стэк, то поняли бы, что запись в array[4] затрет внешнюю (по отношению к циклу) переменную i, и никаким образом на количестве итераций не скажется. C>>>Опечатка конечно подразумевалось for (i = 0; A>>не-не, изначальный вариант тоже может вызвать зацикливание (при определенных условиях). M_>при каких?
ясное дело, если счётчик цикла будет в памяти сразу после array[3], и что он именно оттуда будет читаться. наличие внешней переменной с таким же именем тут при чем? и стэк тут совсем не причём, если конечно вы не покажете место в стандарте, где написано как компилятор должен складывать локальные переменные в стэк
это всё очень сильно компиляторнозависимое. я вполне себе воспроизвёл зацикливание с изначальным тестом, понятно что подобрав опции компилятора.
Re[2]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Antikrot, Вы писали:
A>Здравствуйте, criosray, Вы писали:
C>>"Прелесть" С++ (кто представляет себе ассемблерный код после компиляции поймет что в таком случае произойдет): C>>
C>>int i;
C>>int array[4];
C>>for (int i = 0; i <= 4; i++) {
C>> array[i]=0;
C>>}
C>>
C>>(подсказка: бесконечный цикл) A>далеко не самый наглядный пример, если кто захочет проверить вероятность что счётчик цикла окажется сразу за array[3] и не будет загнан в регистр очень сильно не 100% A>компилятор + опции?
Это только усложняет дело. Иногда происходящая ошибка(одну версию собрали — нормально, что-то поменяли, компилятор скомпилил по-другому(регистры, например, нужны для другого) — глючит, что-то еще поменяли(но не устранили реальный источник проблемы) — компилятор снова по-другому расположил переменные, и все работает) на порядки хуже воспроизводимой всегда.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[23]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, WFrag, Вы писали:
WF>>>Тогда другой вариант. Из всей пачки денег клиент выдергивает 1 купюру из середины. Банкомат забирает деньги обратно, дальше что? Он их пересчитывать будет? C>>Датчики это тут же зафиксируют.
WF>Датчики чего? Я вот не могу придумать способа заметить, что из середины что-то выдернули, не пересчитывая.
Ну Вы не можете, а те, кто делают банкоматы могут. Пачка денег в лотке зафиксированна под давлением. Если выдернуть купюру датчик тут же это определит.
Re[24]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
WF>>>>Тогда другой вариант. Из всей пачки денег клиент выдергивает 1 купюру из середины. Банкомат забирает деньги обратно, дальше что? Он их пересчитывать будет? C>>>Датчики это тут же зафиксируют.
WF>>Датчики чего? Я вот не могу придумать способа заметить, что из середины что-то выдернули, не пересчитывая. C>Ну Вы не можете, а те, кто делают банкоматы могут. Пачка денег в лотке зафиксированна под давлением. Если выдернуть купюру датчик тут же это определит.
Здравствуйте, WFrag, Вы писали:
WF>Здравствуйте, criosray, Вы писали:
C>>А если подумать? C>>А если подумать, то при откате транзакции сумма блокируется до выяснения обстоятельств.
WF>Тогда другой вариант. Из всей пачки денег клиент выдергивает 1 купюру из середины. Банкомат забирает деньги обратно, дальше что? Он их пересчитывать будет?
Нет — это даже более невероятно, чем обези печатающие на машинках "В. и М.". Как будет в этом случае выглядеть претензия клиента?
Re[22]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, _d_m_, Вы писали:
WF>>Тогда другой вариант. Из всей пачки денег клиент выдергивает 1 купюру из середины. Банкомат забирает деньги обратно, дальше что? Он их пересчитывать будет?
___>Нет — это даже более невероятно, чем обези печатающие на машинках "В. и М.". Как будет в этом случае выглядеть претензия клиента?
Случайно — невероятно, специально — так делают (а потом пишут заявление, типа ничего не брал и всё тут).
Я просто пытаюсь доказать, что нет осбого смысла придумывать сложные схемы выдачи денег, всё равно 100% ACID-ность операции выдачи денег не получится. Проще просто забирать деньги обратно, без возврата на счёт, таким образом переложив эту проблему на клиента. А там уже и камеры в ход пойдут, и логи банкомата, и содержимое кассеты с невзятыми деньгами, и.т.д.
Re[18]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, _d_m_, Вы писали:
___>>>>Ну конечно 100% нет. Но с учетом вышесказанного мной, здесь мы уже переходим в раздел вероятностей, где обезьяны печатают "Война и мир" случайными нажатиями.
G>>>Вроде существуют способы сделать 100% транзакционность в распределенной среде.
___>>Не верю! Невозможно.
C>Ну почему же, возможно, если речь о простом терминале, коим и является по сути банкомат. Транзакция коммитится только в случае, если от банкомата пришло подтверждение, что клиент забрал деньги из лотка.
А если вдуматься немножко глубже? А что если клиент забрал деньги из лотка, а связь в этот момент прервалась? Это не списание денег со счета, клиент (человек) как объект не участвует в транзакции и ему нельзя дать команду ролбэк.
Pzz прав, транзакцию надо фиксировать тогда, когда деньги лежат в лотке. Если деньги не забраны, то сторнировать.
И даже в этом случае у нас 100% гарантии.
1) клиент дает команду комит;
2) команда успешно доходит до сервера, он ее принимает, проводит практически транзакцию и блокирует ее ресусы до окончательного комита. Остается только поставить лекговесный флажок, сервер посылает клиенту, что мол коммит может быть успешен [1].
3) клиент посылает серверу подверждение[2], что [1] получил, вот тут и происходит реальный комит.
Но!
Сервер может не получить [2]. Или флажок завершения транзакции может быть не установлен из-за аварии. Что делать? Многократно обмениваться подверждениями, что подверждение подверждения о подверждении получено? Это опять не дает 100% гарантии — добро пожаловать в реальный мир (хотя даже то, что он реален не факт ). Вот это и есть самое слабое место транзакиции, и нет 100% протоколов.
Re[16]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, _d_m_, Вы писали:
___>>Нам хэндшейки нужны только на Commit-e. Больше нигде. Серверу вообще пофиг — что там у клиента исключение или что еще. Ему дали команду списать деньги, а дальше одно из двух — либо комит, либо ролбэк.
Pzz>Коммит в какой момент? Когда бапки уже выдали клиенту? А если коммит не пройдет, получается мы бапки подарим. До выдачи? А если не получится выдать, по механическим причинам, а потом не пройдет обратная транзакция? Получается, что клиент подарит бапки нам.
Pzz>Фактически, банкомат делает коммит, когда уже решил деньги отслюнавливать. Иногда у него не получается отслюнявить, тогда он делает обратную транзакцию. Я один раз такое видел, банкомат долго тарахтел деньгами, потом плюнул и сказал, что денег не даст. На счету было две транзакции: снятие и сразу возврат. Иногда обратная тракзакция не проходит, тогда у клиента начинается хождение по мукам
Да понятно, что в транзакции могут участвовать лишь объекты которые можно либо комитить, либо ролбэкнуть. Человек не может участвовать в транзакции — здесь только сторнирование.
Pzz>Мне, кстати, навскидку непонятно, как организовать последовательность шагов в хендшейке так, чтобы получить вероятность ошибки хендшейка меньше, чем вероятность ошибки в одном шаге.
Поэтому 2-х фазного протокола достаточно. Большей вероятности хоть при 500 фазном протоколе мы не получим.
PS: Приятно беседовать с умным человеком, который понимает с полуслова о чем речь
Re[23]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, WFrag, Вы писали:
WF>Здравствуйте, _d_m_, Вы писали:
WF>>>Тогда другой вариант. Из всей пачки денег клиент выдергивает 1 купюру из середины. Банкомат забирает деньги обратно, дальше что? Он их пересчитывать будет?
___>>Нет — это даже более невероятно, чем обези печатающие на машинках "В. и М.". Как будет в этом случае выглядеть претензия клиента?
WF>Случайно — невероятно, специально — так делают (а потом пишут заявление, типа ничего не брал и всё тут).
WF>Я просто пытаюсь доказать, что нет осбого смысла придумывать сложные схемы выдачи денег, всё равно 100% ACID-ность операции выдачи денег не получится. Проще просто забирать деньги обратно, без возврата на счёт, таким образом переложив эту проблему на клиента. А там уже и камеры в ход пойдут, и логи банкомата, и содержимое кассеты с невзятыми деньгами, и.т.д.
Ну это уже как-бы за рамками данного обсуждения. Ведь речь идет о распределенных транзакциях и о том, что может в ней участвовать.
Когда мне задают вопрос, а как ваша торговая система может защитить от воровства, если кассир не пробивает чек? Я отвечаю — от непробития чека вам не поможет любая торговая система.
Re[24]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, _d_m_, Вы писали:
___>Ну это уже как-бы за рамками данного обсуждения. Ведь речь идет о распределенных транзакциях и о том, что может в ней участвовать.
Я начал с того момента, где criosray «доработал» твой алгоритм.
Re[6]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Antikrot, Вы писали:
A>Здравствуйте, March_rabbit, Вы писали:
C>>>>>>(подсказка: бесконечный цикл) M_>>>>>садитесь, два. M_>>>>>Если бы Вы знали, как работает стэк, то поняли бы, что запись в array[4] затрет внешнюю (по отношению к циклу) переменную i, и никаким образом на количестве итераций не скажется. C>>>>Опечатка конечно подразумевалось for (i = 0; A>>>не-не, изначальный вариант тоже может вызвать зацикливание (при определенных условиях). M_>>при каких? A>ясное дело, если счётчик цикла будет в памяти сразу после array[3], и что он именно оттуда будет читаться. наличие внешней переменной с таким же именем тут при чем?
гы. дело в том, что стек растет сверху-вниз. Соответственно, за краем массива окажется внешняя переменная i. А не внутренняя. Внешняя переменная будет затерта, здесь вопроса нет. Но на работу цикла это не повлияет.
A>и стэк тут совсем не причём, если конечно вы не покажете место в стандарте, где написано как компилятор должен складывать локальные переменные в стэк
ммм.. вопросов нет, все это — дело компилятора. Но, учитывая направление роста стэка, трудно придумать, зачем компилятор будет располагать переменные в другом порядке относительно прямого (то, в котором объявления этих переменных встречаются).
A>это всё очень сильно компиляторнозависимое. я вполне себе воспроизвёл зацикливание с изначальным тестом, понятно что подобрав опции компилятора.
забавно. И что это за опции? Опишите вкратце? Ибо я не очень представляю, как настолько изменить поведение программы
Re[7]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, March_rabbit, Вы писали:
M_>>>>>>Если бы Вы знали, как работает стэк, то поняли бы, что запись в array[4] затрет внешнюю (по отношению к циклу) переменную i, и никаким образом на количестве итераций не скажется. C>>>>>Опечатка конечно подразумевалось for (i = 0; A>>>>не-не, изначальный вариант тоже может вызвать зацикливание (при определенных условиях). M_>>>при каких? A>>ясное дело, если счётчик цикла будет в памяти сразу после array[3], и что он именно оттуда будет читаться. наличие внешней переменной с таким же именем тут при чем? M_>гы. дело в том, что стек растет сверху-вниз. Соответственно, за краем массива окажется внешняя переменная i. А не внутренняя. Внешняя переменная будет затерта, здесь вопроса нет. Но на работу цикла это не повлияет.
Представим другую ситуацию: внешняя переменная — некий аккумулятор, который наполняется в цикле. Предположим, что мы собираем и тестируем нашу программу определенным компилятором, который не сгенерирует код, способный затереть значение во внешнем аккумуляторе по выходу за границы массива (например, соптимизирует аккумулятор так, чтоб он постоянно находился в неком регистре). Все вроде отлично — программа работает... Но вот решаете Вы портировать Вашу программу, например, под другую платформу и для сборки используете уже другой компиллятор, который сгенерирует такой машинный код, что переменная-аккумулятор теперь станет затираться. Как же так, код, который годами работал и тут на тебе — сбоит на ровном месте!
А ведь вместо обычного целочисленного аккумулятора по тому адресу на стеке вполне мог быть, скажем, адрес zero-terminated строки и вот мы его затерли и он стал указывать совсем другой участок памяти... И еще очень хорошо будет, если тут же выскочит segment fault, а не что похуже...
Re: Модульные тесты и "безопасные" языки - хорошо.
Попробуйте скомпиллировать данный код в VC++ любой версии и запустить.
Сразу скажу, что код корректен.
#include"stdafx.h"#include <iostream>
int _tmain(int argc, _TCHAR* argv[])
{
// Эта программа должна вывести /
// первые 8 чисел Фибоначчи: /
// 1, 1, 2, 3, 5, 8, 13, 21. /
// Определим первое и второе /
// значение ряда - это единицы: /int first = 1, second = 1;
// Сразу же выведем первое число: /
printf("%d, ", first);
// Цикл "делать следующее, пока /
// второе значение меньше 20". /while (second < 20) { // проверили/
// Следующее - это сумма /
// первого и второго. Вычислим /int next = first + second;
// Теперь надо записать второе /
// значение в первое, а следую- /
// щее - во второе, так ведь ???/
first = second;
second = next;
// Выведем на экран первое число/
printf("%d, ", first);
}
// Выведем последнее значение ряда/
printf("%d\n", second);
return 0;
}
Попробуйте без дебагера угадать в чем проблема. Удачи.
Re[7]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Vamp, Вы писали:
V>Без дебаггера, простым запуском, видно, что программа делает именно то, что заявлено в описании. V>hostame $ ./a.out V>1, 1, 2, 3, 5, 8, 13, 21 V>hostname $
У Вас тоже проблемы с чтением?
"Попробуйте скомпиллировать данный код в VC++ любой версии и запустить. "
Re[4]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>(подсказка: бесконечный цикл)
Двойка за апелляцию к тому, чего толком не знаешь. Произойдёт UB. Остальные тезисы... Ну, ты понял.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Геннадий Васильев, Вы писали:
C>>(подсказка: бесконечный цикл)
ГВ>Двойка за апелляцию к тому, чего толком не знаешь. Произойдёт UB. Остальные тезисы... Ну, ты понял.
Вот именно, что делает подобные ошибки во сто крат хуже, так как результат такой ошибки непредсказуем.
Re[5]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Sheridan, Вы писали:
c>> У Вас тоже проблемы с чтением? c>> "Попробуйте скомпиллировать данный код в VC++ любой версии и запустить. "
S>Спасибо что открыл мне глаза на микрософтовский компилятор.
А с ним все в порядке. Поспрашивайте вон у Хвоста что такое триграфы.
Re[8]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>Представим другую ситуацию: внешняя переменная — некий аккумулятор, который наполняется в цикле. Предположим, что мы собираем и тестируем нашу программу определенным компилятором, который не сгенерирует код, способный затереть значение во внешнем аккумуляторе по выходу за границы массива (например, соптимизирует аккумулятор так, чтоб он постоянно находился в неком регистре). Все вроде отлично — программа работает... Но вот решаете Вы портировать Вашу программу, например, под другую платформу и для сборки используете уже другой компиллятор, который сгенерирует такой машинный код, что переменная-аккумулятор теперь станет затираться. Как же так, код, который годами работал и тут на тебе — сбоит на ровном месте!
угу, именно поэтому я сразу сказал, что приведенный код — это говнокод.
На такого рода шаблоны со временем глаз уже настраивается. Заводишь массив — размер задаешь РОВНО в одном месте, в остальных — через sizeof или иначе (я обычно константу задаю, потом ее использую). Когда перебор элементов, то в условии ВСЕГДА знак <, и никак не иначе. Ну и так далее. Чисто опыт со временем.
C>А ведь вместо обычного целочисленного аккумулятора по тому адресу на стеке вполне мог быть, скажем, адрес zero-terminated строки и вот мы его затерли и он стал указывать совсем другой участок памяти... И еще очень хорошо будет, если тут же выскочит segment fault, а не что похуже...
Угу, один из способов взлома программ — это переполнение стэка. Принцип действия точно такой же.
И ведь сколько лет известна проблема, а все еще можно применить. Не далее как пару месяцев наза внутрях мозиллы чинил подобный вот код.....
Re[2]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>Попробуйте скомпиллировать данный код в VC++ любой версии и запустить. C>Сразу скажу, что код корректен.
C>Попробуйте без дебагера угадать в чем проблема. Удачи.
поскольку ругань закончилась, спрошу: и что там не так? Визуалки под рукой нет. Про триграфы только слышал в детстве, так и не осилил их запомнить
Re[9]: Модульные тесты и "безопасные" языки - хорошо.
CC>Так нагляднее:
...
Во первых, лично мне запись в одну строчку нагляднее. Но у на свобода — если тебе так нагляднее, найди себе компилятор, который поддерживает такую запись, и пиши так.
Да здравствует мыло душистое и веревка пушистая.
Re[3]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, March_rabbit, Вы писали:
C>>Попробуйте скомпиллировать данный код в VC++ любой версии и запустить. C>>Сразу скажу, что код корректен.
C>>Попробуйте без дебагера угадать в чем проблема. Удачи. M_>поскольку ругань закончилась, спрошу: и что там не так? Визуалки под рукой нет. Про триграфы только слышал в детстве, так и не осилил их запомнить
Из-за триграфа first=second не компилируется, поэтому результат 1 1 1 1 1 ... 20, а не 1 1 2 3 5 ... 21
Re[4]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, March_rabbit, Вы писали:
C>>>Попробуйте скомпиллировать данный код в VC++ любой версии и запустить. C>>>Сразу скажу, что код корректен.
C>>>Попробуйте без дебагера угадать в чем проблема. Удачи. M_>>поскольку ругань закончилась, спрошу: и что там не так? Визуалки под рукой нет. Про триграфы только слышал в детстве, так и не осилил их запомнить C>Из-за триграфа first=second не компилируется, поэтому результат 1 1 1 1 1 ... 20, а не 1 1 2 3 5 ... 21
вероятно, триграф выглядел как-то так: <??/> ?
еще когда наткнулся на них, подумал, что это — зло.
Re[3]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Хвост, Вы писали:
Х>Здравствуйте, criosray, Вы писали:
Х>Я тебе и без дебаггера скажу в чём проблема, проблема в том что ты не знаешь что такое триграфы. Ещё проблема в том что ты нихрена не писал на С++ как заявляешь, либо у тебя настолько ороговение мозга что я даже не знаю последствием какой травмы это может являться. Пиши на C# родной, забей на С++, очевидно что этот язык не для тебя.
Здравствуйте, midcyber, Вы писали:
Х>>Я тебе и без дебаггера скажу в чём проблема, проблема в том что ты не знаешь что такое триграфы. Ещё проблема в том что ты нихрена не писал на С++ как заявляешь, либо у тебя настолько ороговение мозга что я даже не знаю последствием какой травмы это может являться. Пиши на C# родной, забей на С++, очевидно что этот язык не для тебя.
M>Проблем еще несколько, во-первых, этот этюд
C>Из-за триграфа first=second не компилируется, поэтому результат 1 1 1 1 1 ... 20, а не 1 1 2 3 5 ... 21
Инструментом, который ты пользуешься, надо владеть. Вот и все.
Да здравствует мыло душистое и веревка пушистая.
Re[5]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Vamp, Вы писали:
C>>Из-за триграфа first=second не компилируется, поэтому результат 1 1 1 1 1 ... 20, а не 1 1 2 3 5 ... 21 V>Инструментом, который ты пользуешься, надо владеть. Вот и все.
Совершенно верно: знать и всегда помнить обо ВСЕХ подводных камнях.
Но в природе человека ошибаться. Поэтому язык, который допускает такое количество проблем, есть очень плохой язык. В то время, как современное программирование вплотную подходит к мультипарадигмам с чрезвычайно высоким уровнем "безопасности" программирования (строгая типизация, декларативность, минимизация побочных эффектов за счет применения функциональных парадигм, минимизация использования объектов с изменяемым состоянием и т.д. и т.д.), С++ по прежнему болеет все теми же детскими болезнями, которыми болел в 70х-80х... Грустно.
Re[6]: Модульные тесты и "безопасные" языки - хорошо.
C>Совершенно верно: знать и всегда помнить обо ВСЕХ подводных камнях.
Нет. Не обязательно. Например, не обязательно знать как значение триграфов. Достаточно знать, что они есть в природе и не писать ???/, тем более что вообще непонятно, зачем ставить закрывающий слеш в комментариях.
C>Но в природе человека ошибаться.
Нет, это не так. Это тупая отмазка, которую лепят недотепы. Человек создан подобным Богу, и если ты говоришь, что в природе человека ошибаться, ты намекаешь на то, что в природе Бога ошибаться. Лучше не богохульствовать.
C>Поэтому язык, который допускает такое количество проблем, есть очень плохой язык.
Язык проблем не допускает. В языке есть возможности, которыми ты волен пользоваться или не пользоваться.
C>В то время, как современное программирование вплотную подходит к мультипарадигмам с чрезвычайно высоким уровнем "безопасности" программирования (строгая типизация, декларативность, минимизация побочных эффектов за счет применения функциональных парадигм, минимизация использования объектов с изменяемым состоянием и т.д. и т.д.),
Самый безопасный язык — это только что придуманный мной СЯ (СуперЯзык). В нем существует ровно одна синтаксическая конструкция: НапечататьХеллоВорд.
Этот язык чрезвычайно безопасен, и любые возможные ошибки всегда отлавливаются компилятором. Если программа сокмпилировалась без ошибок — она будет работать без ошибок. В языке нету проблем, связанных с управлением памятью, утечками и переполнением буфера.
C>С++ по прежнему болеет все теми же детскими болезнями, которыми болел в 70х-80х... Грустно.
Это не С++ болеет детскими болезнями.
Да здравствует мыло душистое и веревка пушистая.
Re[7]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Vamp, Вы писали:
C>>Совершенно верно: знать и всегда помнить обо ВСЕХ подводных камнях. V>Нет. Не обязательно. Например, не обязательно знать как значение триграфов. Достаточно знать, что они есть в природе и не писать ???/, тем более что вообще непонятно, зачем ставить закрывающий слеш в комментариях.
C>>Но в природе человека ошибаться. V>Нет, это не так. Это тупая отмазка, которую лепят недотепы. Человек создан подобным Богу, и если ты говоришь, что в природе человека ошибаться, ты намекаешь на то, что в природе Бога ошибаться. Лучше не богохульствовать.
Ну что за глупости? Если уж кто богохульствует, так это Вы, когда приравниваете человека к Богу. Человек НЕ совершенен. Если Вы спорите с этим, то либо Вы троллите, либо просто тупы как пробка — выбирайте сами.
C>>Поэтому язык, который допускает такое количество проблем, есть очень плохой язык. V>Язык проблем не допускает. В языке есть возможности, которыми ты волен пользоваться или не пользоваться.
У Вас явные проблемы с логикой.
if (i = n) {...}
C>>В то время, как современное программирование вплотную подходит к мультипарадигмам с чрезвычайно высоким уровнем "безопасности" программирования (строгая типизация, декларативность, минимизация побочных эффектов за счет применения функциональных парадигм, минимизация использования объектов с изменяемым состоянием и т.д. и т.д.), V>Самый безопасный язык — это только что придуманный мной СЯ (СуперЯзык). В нем существует ровно одна синтаксическая конструкция: НапечататьХеллоВорд.
Конструкция напечататьхелловорлд имеет побочные эффекты, а именно подразумевает вывод на устройство вывода, что автоматически делает ее небезопасной в отличии от чисто функционального f(x) -> x * x, к примеру.
V>Этот язык чрезвычайно безопасен, и любые возможные ошибки всегда отлавливаются компилятором. Если программа сокмпилировалась без ошибок — она будет работать без ошибок. В языке нету проблем, связанных с управлением памятью, утечками и переполнением буфера.
Вы, мой друг, еще очень много не знаете, я так погляжу...
C>>С++ по прежнему болеет все теми же детскими болезнями, которыми болел в 70х-80х... Грустно. V>Это не С++ болеет детскими болезнями.
Это С++ болеет детскими болезнями. До таких языков как С#, Nemerle, Boo, F#, Haskell, OCaml, Erlang, Python, Ruby... ему как от земли до неба.
Re[3]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>>>(подсказка: бесконечный цикл) ГВ>>Двойка за апелляцию к тому, чего толком не знаешь. Произойдёт UB. Остальные тезисы... Ну, ты понял. C>Вот именно, что делает подобные ошибки во сто крат хуже, так как результат такой ошибки непредсказуем.
Тпру! А признать свою ошибку с бесконечным циклом слабо?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[4]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Геннадий Васильев, Вы писали:
C>>>>(подсказка: бесконечный цикл) ГВ>>>Двойка за апелляцию к тому, чего толком не знаешь. Произойдёт UB. Остальные тезисы... Ну, ты понял. C>>Вот именно, что делает подобные ошибки во сто крат хуже, так как результат такой ошибки непредсказуем.
ГВ>Тпру! А признать свою ошибку с бесконечным циклом слабо?
Вы о чем?
Re[5]: Модульные тесты и "безопасные" языки - хорошо.
C>Вы будете сильно удивлены, когда узнаете ЧТО программисты пишут в комментариях.
Хочу сильно удивиться. Примеры в студию!
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[6]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>>>>>(подсказка: бесконечный цикл) ГВ>>>>Двойка за апелляцию к тому, чего толком не знаешь. Произойдёт UB. Остальные тезисы... Ну, ты понял. C>>>Вот именно, что делает подобные ошибки во сто крат хуже, так как результат такой ошибки непредсказуем. ГВ>>Тпру! А признать свою ошибку с бесконечным циклом слабо? C>Вы о чем?
Ну как это — о чём? В заглавном сообщении ты утверждал, что произойдёт бесконечный цикл (в своеобычной манере гуру, раскрывающего тайны мироздания плебсу). На самом деле спецификация языка не предусматривает каких-то определённых эффектов в этом случае. Это всем известно, никакой Америки тут не открыто.
Приличные люди в таких случаях извиняются за поднятие шума на ровном месте. А потом уже можно обсудить UB и иже с ними. Кстати, именно из-за UB столь яростно продвигаемые тобой unit-тесты в этом случае могут только добавить путаницы: то есть под тестовым окружением всё сработает, а программа завалится.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[8]: Модульные тесты и "безопасные" языки - хорошо.
C>>Это не вопрос на вопрос, это уточняющий вопрос. Чтоб признать ошибку я должен узнать о чем идет речь.
DC>Он от этого меньше стал вопросом? Да и уточнять тут особо нечего. Я мог бы это высказать в твоём стиле: "Если ты не понял этот вопрос то ты либо тролль, либо у тебя ФГМ.", но не стану. Вобщем ты съезжаешь с темы, впрочем, как всегда.
Тпру! Когда Вы признаете свою ошибку? Только не съезжайте с темы и не спрашивайте какую ошибку! Просто ответьте!
Re[8]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>>>Поэтому язык, который допускает такое количество проблем, есть очень плохой язык. V>>Язык проблем не допускает. В языке есть возможности, которыми ты волен пользоваться или не пользоваться. C>У Вас явные проблемы с логикой.
C>if (i = n) {...}
незнание синтаксиса — не причина ругать язык.
C>Это С++ болеет детскими болезнями. До таких языков как С#, Nemerle, Boo, F#, Haskell, OCaml, Erlang, Python, Ruby... ему как от земли до неба.
забавно, что по распространенности им столь же далеко до него
Может, не настолько уж "детские болезни" и страшны?
Re[9]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, March_rabbit, Вы писали:
C>>>>Поэтому язык, который допускает такое количество проблем, есть очень плохой язык. V>>>Язык проблем не допускает. В языке есть возможности, которыми ты волен пользоваться или не пользоваться. C>>У Вас явные проблемы с логикой.
C>>if (i = n) {...} M_>незнание синтаксиса — не причина ругать язык.
Проблема в том, что это корректный синтаксис. Корректный синтаксис допускающий некорректное поведение — более чем причина, чтоб ругать язык.
C>>Это С++ болеет детскими болезнями. До таких языков как С#, Nemerle, Boo, F#, Haskell, OCaml, Erlang, Python, Ruby... ему как от земли до неба. M_>забавно, что по распространенности им столь же далеко до него
Весьма спорно. M_>Может, не настолько уж "детские болезни" и страшны?
На столько-на столько.
Re[11]: Модульные тесты и "безопасные" языки - хорошо.
C>>Поздравляю. Вот Вы и ответили вопросом на вопрос. Знаете поговорку про сучок в чужом глазу?
DC>Да повесь себе медаль .
DC>А ты продолжай съезжать с темы у тебя это хорошо получается, правда других достоинств чего-то не видно.
Вы все сказали?
Re[10]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
ГВ>>>>Ну как это — о чём? В заглавном сообщении ты утверждал, что произойдёт бесконечный цикл (в своеобычной манере гуру, раскрывающего тайны мироздания плебсу). C>>>Он и произойдет. ГВ>>Это не обязательно. C>Этого я и не утверждал.
Ты уж сам разберись в своих посланиях: не то ты утверждал про цикл, не то не утверждал. Поясняющих ремарок про "обязательность" ты тоже не сделал, так что полагаем, что ты всё же уверен именно в бесконечном цикле.
ГВ>>>>На самом деле спецификация языка не предусматривает каких-то определённых эффектов в этом случае. Это всем известно, никакой Америки тут не открыто. C>>>Язык ущербный, что поделаешь. ГВ>>Иными словами, ты не понимаешь разницы между неопределённым и определённым эффектом. C>Только не эффектом, а поведением — детерменированным или недетерменированным. Да, я понимаю конечно и получше Вашего.
Молодец, формально правильно именно "поведение", кстати, именно "определённое" (defined), а не "детерминированное". Вопрос: что это меняет? Пропала разница между детерминированностью (определённостью) и недетерминированностью (неопределённостью)?
C>>>Зависимость тут не от окружения, а от компиллятора. Поэтому если тестировать продакшн левел бинарник, как это делается в нормальных системах разработки, то проблема будет тут же выявлена — будет сгенерировано исключение с сообщением о выходе за границы массива во время выполнения теста. ГВ>>Дудки! Тому, кто уверяет, что программировал на C++ аж 10 лет и продолжает нести восхитительную ахинею касательно этого же C++, C>Какую ахинею? Вы действительно не знаете С++, раз думаете, что это ахинея.
Я думаю, что у тебя каша в голове. Предметно её распутывать, честно говоря, не имею ни малейшего желания. Добро бы ты ещё по-человечески спросил, а так, в порядке пикировки доказывать, что белое, это белое, хотя на нём можно нарисовать всё, что хочешь любой краской...
ГВ>>проводить ликбез я не буду по принципиальным соображениям. C>Еще бы. Яйцо курицу не учит.
Разумеется. Сам себя не похвалишь, адепты и не додумаются.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[12]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
ГВ>>Это корректный синтаксис и корректное поведение. C>Вы сами-то в это верите?
Зачем мне в это верить? Я это знаю.
ГВ>>Современные компиляторы выдают на такие конструкции предупреждения, но некорректными они от этого не становятся. C>Ну хорошо, как же мне включить предупреждения в самом что ни на есть современном VC++?
Warning C4706. Ключи: /W4 или, например, /w14706.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[13]: Модульные тесты и "безопасные" языки - хорошо.
ГВ>Warning C4706. Ключи: /W4 или, например, /w14706.
Если сильно мучает паранойя, то можно /we4706.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[12]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>Что сказать-то хотели?
Прочитать написанное, я так понимаю, принципы не позволяют.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[6]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Sheridan, Вы писали:
c>> Вы, уважаемый, за собой бы последили. S>Да я вообще за ум взялся — Мамут вон даже поттвердит.
Держите крепче, а то убежит.
Re[9]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Vamp, Вы писали:
C>>Конструкция напечататьхелловорлд имеет побочные эффекты, а именно подразумевает вывод на устройство вывода, что автоматически делает ее небезопасной в отличии от чисто функционального f(x) -> x * x, к примеру. V>Ну-ну. И что потом с этим ха квадрат делать? Он так и останется в памяти компьютера вещью в себе? В реальном мире программам приходится заниматься такими небезопасными вещами, как пользовательский ввод-вывод и даже! о черт! генерировать случайные числа.
Да что Вы говорите?! Не может быть!..
Re[10]: Модульные тесты и "безопасные" языки - хорошо.
V>>Ну-ну. И что потом с этим ха квадрат делать? Он так и останется в памяти компьютера вещью в себе? В реальном мире программам приходится заниматься такими небезопасными вещами, как пользовательский ввод-вывод и даже! о черт! генерировать случайные числа. C>Да что Вы говорите?! Не может быть!..
"Неприятный момент, да, Сысоев?" (С)
Да здравствует мыло душистое и веревка пушистая.
Re[8]: Модульные тесты и "безопасные" языки - хорошо.
Hello, criosray, you write:
c> c>> Вы, уважаемый, за собой бы последили. c> S>Да я вообще за ум взялся — Мамут вон даже поттвердит. c> Держите крепче, а то убежит.
Хорошо, по твоим следам идти не буду. Буду покрепче держать.
Здравствуйте, Vamp, Вы писали:
C>>Корректное поведение... смешно. Ну покажите мне код, где такое поведение корректное. V>A фиг ли скрывать? V>
V>...
V>
точно, сам использую подобные фишки изредка, правда дополняю их скобками и прочим для наглядности.
C>>Я-то прекрасно знаю, как работает оператор присваивания и конструкция if — именно потому и говорю. В 9 из 10 случаев в С/С++ исходниках можно увидеть if (NULL == something) {} вместо if (something == NULL) {}. Это наверно от хорошей жизни, да? V>За 11 лет — видел только в индусских рекомендациях. Это от индуизма.
а вот тут не согласен: расположение константы впереди защищает от описки, которую не сразу и заметишь.
Re[10]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Vamp, Вы писали:
CC>>Так нагляднее: V>... V>Во первых, лично мне запись в одну строчку нагляднее. Но у на свобода — если тебе так нагляднее, найди себе компилятор, который поддерживает такую запись, и пиши так.
Это любой С++0х компилятор позволяет
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[5]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Дудки! Тому, кто уверяет, что программировал на C++ аж 10 лет и продолжает нести восхитительную ахинею касательно этого же C++, проводить ликбез я не буду по принципиальным соображениям.
+10000!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
C>>>>>if (i = n) {...} C>>>Проблема в том, что это корректный синтаксис. Корректный синтаксис допускающий некорректное поведение — более чем причина, чтоб ругать язык. V>>Это совершенно корректный синтаксис. И совершенно корректное поведение. C>Корректное поведение... смешно. Ну покажите мне код, где такое поведение корректное.
Пфф!
TreeNode *node;
if (node = root.GetNode ("Foo"))
{
node->...
...
}
if (node = root.GetNode ("Bar"))
{
node->...
...
}
C>Я-то прекрасно знаю, как работает оператор присваивания и конструкция if — именно потому и говорю. В 9 из 10 случаев в С/С++ исходниках можно увидеть if (NULL == something) {} вместо if (something == NULL) {}. Это наверно от хорошей жизни, да?
Это далеко не в 9 из 10
Есть многие метры С++ сурсов и ни разу там такое не встречается.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[14]: Модульные тесты и "безопасные" языки - хорошо.
C>Вы так программируете? Тогда Вас надо гнать в шею за такой индусокод.
Ну-ка, ну-ка. Назови хотя бы две любые проблемы этого кода.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[15]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, March_rabbit, Вы писали:
C>>>>Я-то прекрасно знаю, как работает оператор присваивания и конструкция if — именно потому и говорю. В 9 из 10 случаев в С/С++ исходниках можно увидеть if (NULL == something) {} вместо if (something == NULL) {}. Это наверно от хорошей жизни, да? V>>>За 11 лет — видел только в индусских рекомендациях. Это от индуизма. M_>>а вот тут не согласен: расположение константы впереди защищает от описки, которую не сразу и заметишь. CC>От описки защищает правильно настроенные опции компилятора
в смысле, очередной варнинг? Или запрет присвоения в условии?
Если ты про варнинг, то.... В нашем проекте этих варнингов столько, что новые часто не замечаются. Мозилла вся насквозь пропитана варнинговым кодом. Поэтому предупреждение — не выход.
CC>А константа впереди ломает глазки при чтении кода.
Это есть. С непривычки ломает. Потому сам практически не использую.
Re[15]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, VoidEx, Вы писали:
VE>Достаточно нуля проблем. Я свою точку зрения доказал. Гнать надо вас в шею за такой код.
А ты, VoidEx, откуда вдруг нарисовался?
И какую это ты точку зрения доказал?
А не виртуал ли ты, мил человек?
Твой второй логин на RSDN часом не criosray?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[17]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, VoidEx, Вы писали:
VE>>Достаточно нуля проблем. Я свою точку зрения доказал. Гнать надо вас в шею за такой код. CC>А ты, VoidEx, откуда вдруг нарисовался? CC>И какую это ты точку зрения доказал? CC>А не виртуал ли ты, мил человек? CC>Твой второй логин на RSDN часом не criosray?
.
[записывает в секретный блокнот]
VE>Вроде писал прямо цитатами, а всё равно видимо непонятно, что это сарказм. По крайней мере двоим.
Для цитат тэг [ q ] придуман
Или в кавычки берут
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[16]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, criosray, Вы писали:
V>>городить что? C>while — не if, но и в этом случае гораздо правильнее будет:
C>
C> //Handle user input. 0 - quit, 1, 2, 3, 4 - do different stuff
C> while ((i = get_user_input()) != NULL) {
C> process_action(i);
C> }
C>
Ну что за непоследовательность?! В деле Правильного Кода полутона недопустимы:
for(int i = get_user_input(); NULL != i; i = get_user_input()){...}
И да восславится Правильный Код!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[3]: Модульные тесты и "безопасные" языки - хорошо.
KV>Ой, а можно с контр-аналогией встряну? Спасибо.
KV>Когда в ПДД, водителей мотоциклов обязали едить в шлеме, травматизм в стране резко вырос. Стали разбираться че за фигня. И вопреки очевидному мнению, что люди стали ездить небрежнее, чувствуя себя в большей защищенности, выяснилась несколько другая вещь. Травматизм действительно вырос, т.к. раньше люди тупо убивались насмерть и портили статистику моргам, а не отделениям травматологии.
KV>"Так-то" (с)
Хм... А я слышал эту байку только в варианте про первую мировую и стальные шлемы пехотинцев...
Re[17]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, March_rabbit, Вы писали:
C>>>>>>Я-то прекрасно знаю, как работает оператор присваивания и конструкция if — именно потому и говорю. В 9 из 10 случаев в С/С++ исходниках можно увидеть if (NULL == something) {} вместо if (something == NULL) {}. Это наверно от хорошей жизни, да? V>>>>>За 11 лет — видел только в индусских рекомендациях. Это от индуизма. M_>>>>а вот тут не согласен: расположение константы впереди защищает от описки, которую не сразу и заметишь. CC>>>От описки защищает правильно настроенные опции компилятора M_>>в смысле, очередной варнинг? Или запрет присвоения в условии? M_>>Если ты про варнинг, то.... В нашем проекте этих варнингов столько, что новые часто не замечаются. Мозилла вся насквозь пропитана варнинговым кодом. Поэтому предупреждение — не выход. CC>Ну, по хорошему в проекте должно стоять "Treat warning as error".
CC>Что в общем то сразу отбивает охоту писать присвоения в if Так что проблема решается как бы сама собой.
ага... и превращает опенсорц код в нечто неюзабельное
для примера попробуй взять мозиллу тандерберд 2 и собрать с этой опцией.... Сумеешь — памятник тебе поставлю!
На самом деле не смешно нифига... Было уже пару раз, что пропускал серьезный варнинг в этой куче предупреждений от любого хедера мозиллы.... А ничего не поделаешь, там вся идеология такая, что волосы дыбом встают
Re[16]: Модульные тесты и "безопасные" языки - хорошо.
не нравится количество повторяющихся строк. Ибо это — неизбужный копипаст. А в копипасте главное — меньший объем, чтобы увереннее его проверить.
CC>Да, лично я предпочитаю не писать присвоение в условии. Но это вопрос стиля, мне так больше нравится. CC>Но и не считаю что присвоение в условии неправильно.
Разрешено синтаксисом языка, значит может применяться.
CC>Зелёному новичку разумеется надо вбить в голову что присвоение в условии это полный капец и так делать нельзя. Во избежание. Ибо сдуру и по неопытности он наворотит говнокода. CC>Когда подрастёт — можно объяснить что иногда на самом деле так делать всё таки можно. CC>Впрочем когда подрастёт — сам должен понять.
Гм. Это смотря как вбить. Новичок после этого может и не развиться, останется в этих рамках, даже не умея объяснить, что здесь неправильно. Ибо это как правило "не выходи на улицу без шапки — сонлнце голову напечет"...
Re[17]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, March_rabbit, Вы писали:
M_>не нравится количество повторяющихся строк. Ибо это — неизбужный копипаст. А в копипасте главное — меньший объем, чтобы увереннее его проверить.
Зато строки проще. Да и в конкретном случае это несущественно.
CC>>Но и не считаю что присвоение в условии неправильно. M_>Разрешено синтаксисом языка, значит может применяться.
Именно
M_>Гм. Это смотря как вбить. Новичок после этого может и не развиться, останется в этих рамках, даже не умея объяснить, что здесь неправильно. Ибо это как правило "не выходи на улицу без шапки — сонлнце голову напечет"...
А это уже зависит от интеллекта новичка. Если развиться не сможет, значит пусть хоть через табу будет убережён от тупых ошибок.
Ты вспомни как даётся та же химия в школе и в универе: в школе все на очень простой модели, в универе: "забудьте все чему вас учили в школе" и пошли рассказывать как оно на самом деле работает.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[19]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, DOOM, Вы писали:
DOO>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Вроде существуют способы сделать 100% транзакционность в распределенной среде.
DOO>>>Нет.
G>>Дальше википедии читать не умеем? DOO>Умеем. Если я привел ссылку на википедию это не значит, что я только ее там прочитал. Задача упомянута в книге Танненбаума "Компьютерные сети", если что.
G>>Эта задача решается доверенным надежным посредником (координатором). DOO>Во-первых, это будет уже другая задача.
Читай до просветления "Вроде существуют способы сделать 100% транзакционность в распределенной среде."
DOO>Во-вторых, у тебя возникает та же самая задача при общении с твоим надежным посредником.
Читай выделенное до просветления "Эта задача решается доверенным надежным посредником".
DOO>Поэтому, если ты считаешь, что решение есть — приведи хоть какое-то его описание — посмотрим, что же оно решает на самом деле.
WS-Atomic, MS DTC.
Re[21]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, gandjustas, Вы писали:
G>>>>Эта задача решается доверенным надежным посредником (координатором). DOO>>>Во-первых, это будет уже другая задача. G>>Читай до просветления "Вроде существуют способы сделать 100% транзакционность в распределенной среде." DOO>Дальше что? DOO>
DOO>Прагматичный подход к решению задачи предполагает не полное устранение ненадежности канала, а её сведение к допустимому уровню.
Я ен говорю про конкретно задачу двух генералов, я говорю о решении общей проблемы.
Если ты хочешь свести её к задаче двух генералов, то у тебя 100% гарантии не будет.
DOO>>>Во-вторых, у тебя возникает та же самая задача при общении с твоим надежным посредником. G>>Читай выделенное до просветления "Эта задача решается доверенным надежным посредником". DOO>Не наступает просветления — у нас канал ненадежен. Посредник может хоть мамой клясться, но на канал он не влияет.
Ты слово "надежный" понимаешь?
DOO>>>Поэтому, если ты считаешь, что решение есть — приведи хоть какое-то его описание — посмотрим, что же оно решает на самом деле. G>>WS-Atomic, MS DTC. DOO>Это описание? По-моему, это названия конкретных систем, реализующих очень простой и примитивный механизм: есть кто-то, кто дает отмашку — причем непонятно, получили ли эту отмашку все участники. Вся их надежность заключается в том, что они ничего не забывают — т.е. рано или поздно ситуация придет в норму. Но в промежуток — все плохо.
Это общая суть транзакционности, внутри может быть все плохо, а вне транзакций состояние согласовано.
DOO>Ситуация с банкоматом: DOO>банкомат и сервер должны совместно выполнить транзакцию по списыванию и выдаче денег. Пусть ее ведет твой надежный координатор. Типа того же DTC. DOO>Банкомат и сервер подтвердили готовность. Координатор дал отмашку. Банкомат выдал деньги и тут упала сеть. Что делать? Координатор не знает получена ли его отмашка банкоматом — т.е. он не знает выданы деньги или нет. То, что система придет в нормальное состояние, когда сеть восстановится — я понимаю, но в промежуток ничего не понятно — если ты транзакцию откатишь, а банкомат деньги выдал, то пользователь снимет те же самые деньги в соседнем банкомате, если ты транзакцию подтвердишь, а банкомат денег не выдал, то ты спишешь деньги со счета пользователя и он не сможет их взять в другом банкомате. Если ты будешь ждать и на это время заморозишь операции со счетом — то пользователь тебе придет бить морду.
DOO>Вот такие они "надежные" распределенные транзакции.
В ситуации с банкоматом выдаватель денег не транзакционен. Если ты забрал из банкомата каким-либо образом хотябы одну бумажку вернуть ее не получится. Откат невозможен.
В ситуации с двумя генералами это аналогично тому что одной из армий вешестоящее командование прикажет атаковать, незавиимо от того дошло ли сообщение до дргуой армии.
Если все компоненты транзакционны, то есть транзакцию до завершения можно откатить, то существует способ организации распределенных транзакций по ненадежным каналам.
Re[22]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, gandjustas, Вы писали:
G>Я ен говорю про конкретно задачу двух генералов, я говорю о решении общей проблемы. G>Если ты хочешь свести её к задаче двух генералов, то у тебя 100% гарантии не будет.
Это всегда будет сводиться к задаче о двух генералах.
DOO>>Не наступает просветления — у нас канал ненадежен. Посредник может хоть мамой клясться, но на канал он не влияет. G>Ты слово "надежный" понимаешь?
Дальше что? каналненадежен.
DOO>>Ситуация с банкоматом: DOO>>банкомат и сервер должны совместно выполнить транзакцию по списыванию и выдаче денег. Пусть ее ведет твой надежный координатор. Типа того же DTC. DOO>>Банкомат и сервер подтвердили готовность. Координатор дал отмашку. Банкомат выдал деньги и тут упала сеть. Что делать? Координатор не знает получена ли его отмашка банкоматом — т.е. он не знает выданы деньги или нет. То, что система придет в нормальное состояние, когда сеть восстановится — я понимаю, но в промежуток ничего не понятно — если ты транзакцию откатишь, а банкомат деньги выдал, то пользователь снимет те же самые деньги в соседнем банкомате, если ты транзакцию подтвердишь, а банкомат денег не выдал, то ты спишешь деньги со счета пользователя и он не сможет их взять в другом банкомате. Если ты будешь ждать и на это время заморозишь операции со счетом — то пользователь тебе придет бить морду.
DOO>>Вот такие они "надежные" распределенные транзакции.
G>В ситуации с банкоматом выдаватель денег не транзакционен. Если ты забрал из банкомата каким-либо образом хотябы одну бумажку вернуть ее не получится. Откат невозможен.
Откат невозможен всегда, когда уже прошел commit. Т.е. при отсутствии информации надо либо ждать ее появления (вариант 3), либо принимать какое-то решение без необходимой информации (варианты 1 и 2).
G>В ситуации с двумя генералами это аналогично тому что одной из армий вешестоящее командование прикажет атаковать, незавиимо от того дошло ли сообщение до дргуой армии.
Но поскольку атаковать надо все равно — поэтому и приходится совершать транзакцию без 100% уверенности в ее согласованности. И не может быть 100% уверенности.
G>Если все компоненты транзакционны, то есть транзакцию до завершения можно откатить, то существует способ организации распределенных транзакций по ненадежным каналам.
Всегда будет точка принятия решения. Либо commit, либо rollback — и может быть ситуация, что при принятии решения нужной информации нет — тогда надо либо ждать ее появления (посылать очередного гонца), либо принимать решение, исходя их каких-то общих правил — как делают банки — деньги со счета списать не зная наверняка получил ли их клиент.
Re[21]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, DOOM, Вы писали:
DOO>Ситуация с банкоматом: DOO>банкомат и сервер должны совместно выполнить транзакцию по списыванию и выдаче денег. Пусть ее ведет твой надежный координатор. Типа того же DTC. DOO>Банкомат и сервер подтвердили готовность. Координатор дал отмашку. Банкомат выдал деньги и тут упала сеть. Что делать? Координатор не знает получена ли его отмашка банкоматом — т.е. он не знает выданы деньги или нет. То, что система придет в нормальное состояние, когда сеть восстановится — я понимаю, но в промежуток ничего не понятно — если ты транзакцию откатишь, а банкомат деньги выдал, то пользователь снимет те же самые деньги в соседнем банкомате, если ты транзакцию подтвердишь, а банкомат денег не выдал, то ты спишешь деньги со счета пользователя и он не сможет их взять в другом банкомате. Если ты будешь ждать и на это время заморозишь операции со счетом — то пользователь тебе придет бить морду.
До боли знакомая ситуация, только наоборот. С платежными терминалами похожая беда. И если обычные терминалы могут работать отчасти в оффлайне(т.е. если связи нет, отправить платеж чуть позже, хотя это тоже вызывает свои проблемы, особенно, если связь падает всерьез и надолго), то упавшая связь при подтверждении транзакции в POS терминалах — это крыша. И как такое решать, неясно.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[24]: Модульные тесты и "безопасные" языки - хорошо.
DOO>>>>Не наступает просветления — у нас канал ненадежен. Посредник может хоть мамой клясться, но на канал он не влияет. G>>>Ты слово "надежный" понимаешь? DOO>>Дальше что? каналненадежен. G>Всегда чтоли? Вот TCP надежен, хотя работает поверх ненадежного IP. G>Если принять за аксиому что все каналы ненадежны то ничего не поможет. Но в реальном мире создают надежные каналы поверх ненадежных.
А ничего, что Танненбаум приводит задачу о двух генералах как обоснование невозможности создания надежного механизма согласованного прекращения передачb в том самом надежном протоколе TCP?
И домашнее задание тебе — выучить, что именно гарантирует TCP.
DOO>>Откат невозможен всегда, когда уже прошел commit. Т.е. при отсутствии информации надо либо ждать ее появления (вариант 3), либо принимать какое-то решение без необходимой информации (варианты 1 и 2). G>Можно и так счиатать, тогда в случае с банкоматом commit происходит не по желанию системы, а под воздействием внешних факторв (которые нельзя направить через координатор). Это транзакционность компонента в рамках системы нарушает.
Хорошо приведи мне тогда идеальный пример, в котором подобная ситуация невозможна.
G>>>В ситуации с двумя генералами это аналогично тому что одной из армий вешестоящее командование прикажет атаковать, незавиимо от того дошло ли сообщение до дргуой армии. DOO>>Но поскольку атаковать надо все равно — поэтому и приходится совершать транзакцию без 100% уверенности в ее согласованности. И не может быть 100% уверенности. G>Только транзакционностью тут уже не пахнет.
Приведи свой пример — тогда уже не сможешь отмазаться
Re[24]: Модульные тесты и "безопасные" языки - хорошо.
DOO>>>>Не наступает просветления — у нас канал ненадежен. Посредник может хоть мамой клясться, но на канал он не влияет. G>>>Ты слово "надежный" понимаешь? DOO>>Дальше что? каналненадежен. G>Всегда чтоли? Вот TCP надежен, хотя работает поверх ненадежного IP. G>Если принять за аксиому что все каналы ненадежны то ничего не поможет. Но в реальном мире создают надежные каналы поверх ненадежных.
Блажен кто верует.
Надежные они лишь потому, что вероятность близка к 100%. Но гарантировать 100% невозможно. Аргументов пока от тебя не дождались.
Re[25]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, gandjustas, Вы писали:
DOO>>>>>Не наступает просветления — у нас канал ненадежен. Посредник может хоть мамой клясться, но на канал он не влияет. G>>>>Ты слово "надежный" понимаешь? DOO>>>Дальше что? каналненадежен. G>>Всегда чтоли? Вот TCP надежен, хотя работает поверх ненадежного IP. G>>Если принять за аксиому что все каналы ненадежны то ничего не поможет. Но в реальном мире создают надежные каналы поверх ненадежных.
___>Блажен кто верует. ___>Надежные они лишь потому, что вероятность близка к 100%. Но гарантировать 100% невозможно. Аргументов пока от тебя не дождались.
В реальном мире 100% гарантировать вообще невозможно. Главное чтобы надежность была не ниже надежности оборудования которое связывают эти каналы.
Re: Модульные тесты и "безопасные" языки - хорошо.
C>У кого еще остались сомнения в целесообразности модульных тестов, в целесообразности использования языков/платформ с большим количеством статических и динамических проверок...
C>http://habrahabr.ru/blogs/lifehack/64627/
C>"Прелесть" С++ (кто представляет себе ассемблерный код после компиляции поймет что в таком случае произойдет): C>
C>int i;
C>int array[4];
C>for (int i = 0; i <= 4; i++) {
C> array[i]=0;
C>}
C>
C>(подсказка: бесконечный цикл)
Правильнее всетаки так (если я правильно понял семантику данного кода):
memset((void*)array, 0, sizeof(array));
Re[2]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Константин Б., Вы писали:
Судя по тому, что на том же сайте находится и вот это:
Н.В.Чистяков, Главный конструктор комплексов дистанционно пилотируемых летательных аппаратов (ДПЛА): комплекса Строй-П с ДПЛА Пчела, известного по антитеррористическим кампаниям, комплексов ГрАНТ, БРАТ и других. Основатель Научно-производственного конструкторского центра Новик-XXI век. Программное обеспечение системы управления, воплощающее в себе весь опыт и знания конструкторского коллектива, — это мозг беспилотного летательного аппарата, а его проектирование и разработка — обязанность и привилегия Главного конструктора.
то и вояки наши используют виртовские дела, а не mainstream.
И правильно делают!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[3]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, _d_m_, Вы писали:
LVV>>Для спутников наши используют виртовские языки, а не С/С++. Как ГОРАЗДО более надежные и ГОРАЗДО меньшего размера... ___>Виртовские? Pascal и C#?
Модулу-2 и переходят на Оберон-Компонентный паскаль.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[6]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Pzz, Вы писали:
Pzz>Управляемые языки исключают некоторые классы ошибок (например, обращение по невалидному указателю или за пределами массива), совсем никак не исключая других классов ошибок (например, использование некорректных алгоритмов).
Это зависит. Если говорить по жабу и .НЕТ то да. А если почистить систему типов и добавить зависимые типы то там можно и некорректные алгоритмы отлавливать. Пусть и ни на 100% но юнит тесты можно списать в утиль с чистой совестью.
Pzz>я бы, кстати, предпочел термин "безопасные", потому что безопасный язык можно реализовать на голом железе, без всяких "управляемых" сред
А что конкретно ты понимаешь под "средой"?
Pzz>А пользователю вашему все равно, к какому классу относилась ошибка, убившая его файл или банковский счет, к тому, которые предотвращаются использованием "безопасных" инструментов, или к тому, которые не предотвращаются.
Устранение некоторых классов ошибок == меньше ошибок при тех же усилиях.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Модульные тесты и "безопасные" языки - хорошо.
Pzz>>Управляемые языки исключают некоторые классы ошибок (например, обращение по невалидному указателю или за пределами массива), совсем никак не исключая других классов ошибок (например, использование некорректных алгоритмов). WH>Это зависит. Если говорить по жабу и .НЕТ то да. А если почистить систему типов и добавить зависимые типы то там можно и некорректные алгоритмы отлавливать. Пусть и ни на 100% но юнит тесты можно списать в утиль с чистой совестью.
Здравствуйте, Pzz, Вы писали:
Pzz>>>А пользователю вашему все равно, к какому классу относилась ошибка, убившая его файл или банковский счет, к тому, которые предотвращаются использованием "безопасных" инструментов, или к тому, которые не предотвращаются. WH>>Устранение некоторых классов ошибок == меньше ошибок при тех же усилиях.
Pzz>Зато оставшиеся ошибки становятся гораздо более заковыристыми
C чего это?
Re[10]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Pzz, Вы писали:
Pzz>>>Потому что простые отсеиваются компилятором.
C>>Где логика? Как отсеивание части ошибок может делать "оставшиеся ошибки более заковыристыми"?
Pzz>У программиста появляется больше времени делать более хитрые ошибки.
У программиста появляется больше времени НЕ делать хитрые (и не очень) ошибки.
Re[12]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Pzz, Вы писали:
Pzz>>>Я сказал простую вещь: понятия "безопасного" языка и "управляемого" языка ортогональны. C>>Глупость.
Pzz>Ну а обосновать?
Сначала Вы.
Pzz>>>Можно сделать безопасный язык, который статически компилируется в машинный код, можно сделать управляемый язык, который будет небесопасен (правда, второе непонятно зачем делать). Я ничего не сказал при этом относительно связанного с JIT-ом оверхеда. Против того, что я сказал, какие-нибудь возражения по существу имеются? C>>Ну вперед — сделайте. За 50+ лет до Вас не смогли. Удачи.
Pzz>Чего сделать не смогли?
Вы что же забыли что писали тремя строчками выше?
"Можно сделать безопасный язык, который статически компилируется в машинный код, можно сделать управляемый язык, который будет небесопасен (правда, второе непонятно зачем делать)."
C>>То есть когда Вы получаете ТЗ от заказчика, то отбрасываете половину со словами "мы этого делать не будем — наш инструмент нам не позволяет"?
Pzz>Сделать по-разному можно.
То есть Вы понимаете какую глупость тут сморозили?
Re[2]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Vamp, Вы писали:
V>Кстати, человек, действительно знакомый с С++ не по-наслышке, никогда такого, что у тебя в примере не напишет. Мне, например, сразу в глаза бросилось <= — такое условие в цикле итерации не встречается никогда. V>Ну и в последних, писать итеративные циклы в С++, где есть for_each, bind и lambda — каменный век.
Самое главное в C++ есть std::vector и возможность использовать begin/end.
<= тоже сразу бросилось в глаза.
Re[4]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Vamp, Вы писали:
C>>Опечатка конечно подразумевалось for (i = 0; C>>Если Вам нравится цепляться к словам, то и я прицеплюсь к Вашим: в языке С конструкция for (int i;... синтаксически некорректна. V>А причем тут С? В начале речь шла о С++. В С++ это более чем корректная конструкция.
И даже более того — она предпочтительнее варианта с переменной из внешнего блока видимости.
Re[2]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, Pzz, Вы писали:
Pzz>Я где-то читал, что повсеместное введение автомобильных ремней безопасности не снизило количество смертей на дорогах: люди почувствовали себя "безопаснее" и стали ездить быстрее.
Ты откровенно переврал исходную историю.
Как раз количество смертей на дорогах резко снизилось, но повысилось количество аварий.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, WolfHound, Вы писали:
WH>Это зависит. Если говорить по жабу и .НЕТ то да. А если почистить систему типов и добавить зависимые типы то там можно и некорректные алгоритмы отлавливать.
Вроде как в .NET 4.0 появились Code Contracts. Чем .NET классы с code contracts отличаются от зависимых типов?
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[8]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, nme, Вы писали:
nme>Вроде как в .NET 4.0 появились Code Contracts. Чем .NET классы с code contracts отличаются от зависимых типов?
Примерно тем же самым чем статическая типизация отличается от динамической.
Мало того что Code Contracts могут делать лишь часть того на что способны ЗТ но даже для этой части нет гарантии того что проверки будут статическими.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, WolfHound, Вы писали:
WH>Примерно тем же самым чем статическая типизация отличается от динамической. WH>Мало того что Code Contracts могут делать лишь часть того на что способны ЗТ.
Можно примеры таких фич?
WH>Но даже для этой части нет гарантии того что проверки будут статическими.
Вроде как Code Contracts это в первую очередь статические проверки (есть опция проверять в рантайме, но это не основное их предназначение).
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[11]: Модульные тесты и "безопасные" языки - хорошо.
WH>Но ты гарантированно получишь кучу проверок времени исполнения. WH>
WH>2.7 Quanti?ers
WH>Limited support is available for quanti?ers within contracts. We support only those forms which are executable at runtime. This currently means that the range of quanti?cation must be effectively computable.
WH>Also, the “body” of each quanti?cation must be an expression, i.e., not contain any loops or assignment statements.
WH>2.7.1 ForAll
WH>Universal quanti?cations are written using Contract. ForAll . ...
В общем понятно. Для generic типов в .NET в качестве generic параметра можно передать только тип (т.е. нельзя передать int например). Отсюда невозможность статической проверки коллекций.
Можно сделать обёртку над массивом что-то вроде ArrayOfUintLimited, то что происходит в нутри неё придётся самому проверять, но такой код
WH>
WH>for (i in mesh.indices.Indices)
WH> def vertex = mesh.vertices[mesh.indices[i]];
WH> ...
WH>end
WH>
будет проверяться статически.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[12]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, nme, Вы писали:
nme>В общем понятно. Для generic типов в .NET в качестве generic параметра можно передать только тип (т.е. нельзя передать int например). Отсюда невозможность статической проверки коллекций.
В общем случае одних int'ов не хватит.
Нужна возможность использовать значения любых типов.
Причем значениями времени компиляции тоже не обойтись.
Должна быть возможность параметризовать типы значениями времени исполнения.
А это уже зависимые типы получаются.
nme>Можно сделать обёртку над массивом что-то вроде ArrayOfUintLimited, то что происходит в нутри неё придётся самому проверять,
Вот так ты и будешь для каждого частного случая рисовать костыли с кучей проверок времени исполнения.
nme>но такой код WH>>
WH>>for (i in mesh.indices.Indices)
WH>> def vertex = mesh.vertices[mesh.indices[i]];
WH>> ...
WH>>end
WH>>
nme>будет проверяться статически.
Конечно же не будет.
Ибо для этого тебе придется объяснить компилятору что в массиве indeces лежат индексы массива vertices, а Code Contracts такие зависимости отследить не в состоянии.
Quantifiers не подходят ибо работают только во время исполнения.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, WolfHound, Вы писали:
nme>>В общем понятно. Для generic типов в .NET в качестве generic параметра можно передать только тип (т.е. нельзя передать int например). Отсюда невозможность статической проверки коллекций. WH>В общем случае одних int'ов не хватит. WH>Нужна возможность использовать значения любых типов. WH>Причем значениями времени компиляции тоже не обойтись. WH>Должна быть возможность параметризовать типы значениями времени исполнения. WH>А это уже зависимые типы получаются.
Это понятно, а про int я написал, что это только пример.
WH>Вот так ты и будешь для каждого частного случая рисовать костыли с кучей проверок времени исполнения.
Это тоже итак понятно, т.к. вытекает из предыдущей проблемы.
WH>Конечно же не будет. WH>Ибо для этого тебе придется объяснить компилятору что в массиве indeces лежат индексы массива vertices, а Code Contracts такие зависимости отследить не в состоянии. WH>Quantifiers не подходят ибо работают только во время исполнения.
А в чём проблема? Code contracts конечно не могут проверить(статически) существования элемента в коллекции , но в данном случае это вроде как и не нужно. Элементы Indices вроде просто должны удовлетворять условию 0 <= index < vertexCount. А с этим Code contracts вполне способны разобраться.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[14]: Модульные тесты и "безопасные" языки - хорошо.
BTW Статическую проверку для коллекций можно организовать и без ЗТ, но только для иммутабельных типов. В Spec# можно было обьявлять иммутабельность в виде контракта, но в Code contracts на данный момент это не реализовано.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[14]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, nme, Вы писали:
WH>>А это уже зависимые типы получаются. nme>Это понятно, а про int я написал, что это только пример.
Те тебе понятно что зависимые типы таки нужны?
WH>>Вот так ты и будешь для каждого частного случая рисовать костыли с кучей проверок времени исполнения. nme>Это тоже итак понятно, т.к. вытекает из предыдущей проблемы.
Насчет кучи проверок времени исполнения тоже возражений нет.
nme>А в чём проблема? Code contracts конечно не могут проверить(статически) существования элемента в коллекции , но в данном случае это вроде как и не нужно. Элементы Indices вроде просто должны удовлетворять условию 0 <= index < vertexCount. А с этим Code contracts вполне способны разобраться.
А давай ты повторишь этот код на Code contracts так чтобы не было проверок времени исполнения.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, WolfHound, Вы писали:
nme>>А в чём проблема? Code contracts конечно не могут проверить(статически) существования элемента в коллекции , но в данном случае это вроде как и не нужно. Элементы Indices вроде просто должны удовлетворять условию 0 <= index < vertexCount. А с этим Code contracts вполне способны разобраться. WH>А давай ты повторишь этот код на Code contracts так чтобы не было проверок времени исполнения.
Да, похоже ты прав. Помоему, теоретически ничего не мешает провести статическую проверку в данной ситуации, но видимо процесс слишком трудоёмкий. С ЗТ ситуация по лучше, там ограничения хранятся внутри типа uintLimited, а не снаружи, как в ArrayOfUintLimited.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[16]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, nme, Вы писали:
nme>Да, похоже ты прав. Помоему, теоретически ничего не мешает провести статическую проверку в данной ситуации, но видимо процесс слишком трудоёмкий.
Нут так бег на костылях ни к чему хорошему ни когда не приводил...
nme>С ЗТ ситуация по лучше, там ограничения хранятся внутри типа uintLimited, а не снаружи, как в ArrayOfUintLimited.
Самое смешное что uintLimited ничего кроме собственно значения не хранит. Те sizeof uint == sizeof uintLimited[x].
И это простейший пример.
Сами по себе ЗТ способны проверять куда более интересные конструкции.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, WolfHound, Вы писали:
WH>Сами по себе ЗТ способны проверять куда более интересные конструкции.
Мне тут стало интересно как проверить такую конструкцию:
Есть например тип
class MyType
{
public T1 a;
public T2 b;
}
т.е. есть класс с двумя полями, типы полей это мутабельные типы. Далее мы хотим задать зависимость b от а, это можно сделать? Я полагаю для этого потребуется заменить T2 на DT2<a> и в конструкторе MyType передавать а как параметр в тип DT2.
Далее рассмотрим такой код:
MyType mType = ...;
var A = mType.a;
var B = mType.b;
Поймёт ли компилятор, что для А и В выполняется тоже отношение, что для a и b? Например если мы передадим A и B в какую-то функцию, а там будет соответствующая проверка.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[18]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, nme, Вы писали:
nme>т.е. есть класс с двумя полями, типы полей это мутабельные типы. Далее мы хотим задать зависимость b от а, это можно сделать? Я полагаю для этого потребуется заменить T2 на DT2<a> и в конструкторе MyType передавать а как параметр в тип DT2.
Извини я не могу ничего сказать по столь абстрактному примеру.
Можешь придумать что-то более конкретное?
nme>Поймёт ли компилятор, что для А и В выполняется тоже отношение, что для a и b? Например если мы передадим A и B в какую-то функцию, а там будет соответствующая проверка.
А тут нет никакой разницы с обычной статической типизацией.
А и В будут тех же типов что a и b. Таким образом с А и В можно делать все то что можно делать с a и b.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[19]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, WolfHound, Вы писали:
nme>>т.е. есть класс с двумя полями, типы полей это мутабельные типы. Далее мы хотим задать зависимость b от а, это можно сделать? Я полагаю для этого потребуется заменить T2 на DT2<a> и в конструкторе MyType передавать а как параметр в тип DT2. WH>Извини я не могу ничего сказать по столь абстрактному примеру. WH>Можешь придумать что-то более конкретное?
Ок, пусть так
class MyType
{
public int a;
public int b;
}
от b требуется чтобы оно было больше a. Считаем что a и b мутабельны (т.е. не опираемся на их иммутабельность).
nme>>Поймёт ли компилятор, что для А и В выполняется тоже отношение, что для a и b? Например если мы передадим A и B в какую-то функцию, а там будет соответствующая проверка. WH>А тут нет никакой разницы с обычной статической типизацией. WH>А и В будут тех же типов что a и b. Таким образом с А и В можно делать все то что можно делать с a и b.
Тут дело не в типах a и b, а в том что эти типы содержат информацию о том что а < b. Поймёт ли компилятор, что A < B?
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[20]: Модульные тесты и "безопасные" языки - хорошо.
nme>class MyType
nme>{
nme> public int a;
nme> public int b;
nme>}
nme>
nme>от b требуется чтобы оно было больше a. Считаем что a и b мутабельны (т.е. не опираемся на их иммутабельность).
Так не получится.
А вот если а неизменяемое тогда можно.
В прочем практика показывает что при переходе на функциональные языки количество изменяемых данных резко падает. Причем при разработке на всех языках.
nme>Тут дело не в типах a и b, а в том что эти типы содержат информацию о том что а < b. Поймёт ли компилятор, что A < B?
Да.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[21]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, nme, Вы писали:
nme>>
nme>>class MyType
nme>>{
nme>> public int a;
nme>> public int b;
nme>>}
nme>>
nme>>от b требуется чтобы оно было больше a. Считаем что a и b мутабельны (т.е. не опираемся на их иммутабельность). WH>Так не получится. WH>А вот если а неизменяемое тогда можно. WH>В прочем практика показывает что при переходе на функциональные языки количество изменяемых данных резко падает. Причем при разработке на всех языках.
Ну для неизменяемых типов можно и code contracts допилить до паритета по возможностям с ЗТ. Фактически code contract это тоже самое, что ЗТ. Просто описание ограничений происходит несколько по разному. В языках с ЗТ все ограничения торчат наружу, в code contracts всё спрятано во внутрь типа, но суть таже. Подход code contracts более походит на традиционны стиль написания программ, но с ЗТ гораздо легче отслеживать ограничения.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[22]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, nme, Вы писали:
nme>Ну для неизменяемых типов можно и code contracts допилить до паритета по возможностям с ЗТ.
Мы же уже выяснили что нельзя. http://rsdn.ru/forum/flame.comp/3547371.1.aspx
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, nme, Вы писали:
nme>>Ну для неизменяемых типов можно и code contracts допилить до паритета по возможностям с ЗТ. WH>Мы же уже выяснили что нельзя. WH>http://rsdn.ru/forum/flame.comp/3547371.1.aspx
На данный момень code contracts не понимают иммутабельности и то что я там написал справедливо на данный момент.
nme>>Фактически code contract это тоже самое, что ЗТ. WH>Ничего не тоже самое.
WH>2Народ: А давайте вы прежде чем спорить предмет изучите. А?
Может ты для начала сам посмотришь code contracts? В текущем состоянии, понятно что они до ЗТ не дотягивают, но сама идея аналогична ЗТ, отличаются только способы описания. В ЗТ например ты явно получаешь из функции uintLimited, а в code contracts будет возвращён обычный uint и только компилятор будет знать, что это на самом деле uintLimited (он вполне может это вывести из контракта внутри функции и этот uintLimited будет присутствовать в коде неявно), это неудобно для программиста, но компенсируется частично подсказками компилятора.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[23]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, WolfHound, Вы писали:
WH>2Народ: А давайте вы прежде чем спорить предмет изучите. А?
В каком виде у ЗТ указывается объект в качестве generic параметра? Т.е. у меня есть функция, например, и мне нужно указать тип её аргумента пусть это будет uintLimited[x]. В данном случае всё просто в качестве x можно записать любое целое число, но что делать если x это сложный тип?
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[24]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, nme, Вы писали:
nme>В каком виде у ЗТ указывается объект в качестве generic параметра? Т.е. у меня есть функция, например, и мне нужно указать тип её аргумента пусть это будет uintLimited[x]. В данном случае всё просто в качестве x можно записать любое целое число, но что делать если x это сложный тип?
То же самое.
На досуге подумай, чем сложный тип отличается от простого и где между ними граница.
А еще лучше пойди и почитай статьи. Ссылки я уже приводил. И пересказывать эти статьи у меня нет ну никакого желания.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[25]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, WolfHound, Вы писали:
WH>А еще лучше пойди и почитай статьи. Ссылки я уже приводил. И пересказывать эти статьи у меня нет ну никакого желания.
А кстати, зря. Ты тут давича очень умную мысль сказал. Ты сказал, что ученый люд любит все заформализовать.
Это дико мешает изучению этого нового. Я вот про тот же Ur читал-читал, но так и не понял механизма работы его метааппарата. Если кто-то (например, ты) взялся бы и описал все тоже самое, но на пальцах (для людей которым голову высшей математикой не отдавило) — это было бы в сто раз полезнее, чем проводить сутки на пролет споря с теми кто попросту не может или не хочет осилить эти заформализованные тексты.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, VladD2, Вы писали:
VD>А кстати, зря. Ты тут давича очень умную мысль сказал. Ты сказал, что ученый люд любит все заформализовать.
Вот по этой ссылке http://lsc.fie.umich.mx/~sadit/Clases/lenguajesprogramacion/unreal.pdf
Все написано так что даже разработчики игр понимают. И там написано разработчиком игр.
Там собственно написано нахрена оно вообще надо и как в общих чертах оно вообще работает.
А это как раз тот самый формализм который все влом читать.
ЗЫ
В общем, могу пожелать тебе и дальше счастливых баталий на форумах с теми кто тебя даже не понимает. Но надо четко понимать, что ты не только не докажешь кому-то хоть что-нибудь но и бездарно убьешь время.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: Модульные тесты и "безопасные" языки - хорошо.
Здравствуйте, WolfHound, Вы писали:
WH>Вот по этой ссылке http://lsc.fie.umich.mx/~sadit/Clases/lenguajesprogramacion/unreal.pdf WH>Все написано так что даже разработчики игр понимают. И там написано разработчиком игр. WH>Там собственно написано нахрена оно вообще надо и как в общих чертах оно вообще работает.
Кстати, о предсказаниях. В этой презентахе есть замечательный слайд:
By 2009, game developers will face…
§ CPU‛s with:
– 20+ cores
– 80+ hardware threads
– >1 TFLOP of computing power
§
Где мои 16 процессоров? Я уже молчу о моих 76 аппоратных потоках...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.