Я иногда кое-что пишу или отлаживаю на Delphi или FreePascal (не только на них и вообще это не так важно). Сегодня отлаживал одну ошибку, программа почему-то падала. Выяснил, что падение возникает из-за ошибок в некоторых данных (это другая история), которые программа забывала проверить на корректность. Добавил проверку. Можно было бы успокоиться, что все заработало, но решил выяснить, из-за чего она все-таки падала при неправильных данных.

Это меня ошарашило. Я несмотря на то, что казалось бы имею давний опыт программирования на Delphi еще с 90-х годов и иногда периодически что-то писал, не знал, что exit внутри try...finally вызывает не немедленный выход из функции, а переход к блоку finally. Думал, что этот блок исполняется только в нормальном случае или при исключениях, а exit немедленно завершает функцию. Ошибался. Теперь удивляюсь, как же я умудрился раньше не нарваться на ошибки в этом месте (дважды вызов Free например из-за этого)

Мораль в качестве выводов:

1) Если есть ошибка полезно докопаться до ее истоков, а не просто избавиться от нее.
2) Можно обнаружить что-то для себя новое в казалось бы давно и хорошо известном.

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

M>Это меня ошарашило. Я несмотря на то, что казалось бы имею давний опыт программирования на Delphi еще с 90-х годов и иногда периодически что-то писал, не знал, что exit внутри try...finally вызывает не немедленный выход из функции, а переход к блоку finally. Думал, что этот блок исполняется только в нормальном случае или при исключениях, а exit немедленно завершает функцию.

Не в качестве сарказма, а действительно любопытно — 2ALL: а где нибудь есть иное поведение?
И можно как нибудь вывернуться и это переопределить, скажем, на Java?

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

M>Delphi еще с 90-х годов ... exit внутри try...finally

объясните идиоту, пожалуйста,
как можно использовать try...finally и не знать как оно работает?
Вы ведь где-то прочитали об исключениях, примеры учебные писали наверняка..
как так?
книжек под делфе не читали, в справку не заглядывали, а писали так же как на Turbo Pascal 7.0?
обработку исключений подсмотрели у соседа?


я не понимаю, правда....
это вне моего мировоззрения.

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

M>Это меня ошарашило. Я несмотря на то, что казалось бы имею давний опыт программирования на Delphi еще с 90-х годов и иногда периодически что-то писал, не знал, что exit внутри try...finally вызывает не немедленный выход из функции, а переход к блоку finally.


программисты на дельфи — это всегда очень печальное зрелище. хуже только программисты на 1С

сорри, ниче личного, но это реально факт.

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

я както во фрискейле работал — так у них там с одной игрушкой типа волка ловящего яйца,
гдето на 14 часу игры проскакивал глюк .

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

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

M>>Delphi еще с 90-х годов ... exit внутри try...finally

CL>объясните идиоту, пожалуйста,
CL>как можно использовать try...finally и не знать как оно работает?

Можно, как выяснил на своем опыте. В том и мораль, что можно оказывается чего-то не знать там, где давным давно, казалось бы все знал.

CL>Вы ведь где-то прочитали об исключениях, примеры учебные писали наверняка..
CL>как так?

Конечно. И это даже работает успешно, в конце-концов, не так часто exit использовал, кроме того, дублирование блока перед exit-ом далеко не всегда приводило к ошибкам. Анекдот, но так и есть.

CL>книжек под делфе не читали, в справку не заглядывали, а писали так же как на Turbo Pascal 7.0?
CL>обработку исключений подсмотрели у соседа?

В книжке подробно описывалось как работают исключения, а вот о таком нюансе работы exit в старой еще 90-х годов книжке не было. Просто пропущен этот момент, а exit я знал еще действительно со времен турбо-паскаля. Затем казалось естественным, что он вызывает мгновенный выход.

Если бы я изучал Delphi с нуля и в 2000-х, возможно, что не оказался в заблуждении.

CL>я не понимаю, правда....
CL>это вне моего мировоззрения.

Я тоже не понимаю, теперь надо свой код везде пересмотреть

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

C>я както во фрискейле работал — так у них там с одной игрушкой типа волка ловящего яйца,
C>гдето на 14 часу игры проскакивал глюк .

И?

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

C>я както во фрискейле работал — так у них там с одной игрушкой типа волка ловящего яйца,
C>гдето на 14 часу игры проскакивал глюк .

вы все наверняка знаете что в микроокнтроллерных приложениях это рядовое явление, и отфиксить железку стоит серьезных трудозатрат

D>программисты на дельфи — это всегда очень печальное зрелище. хуже только программисты на 1С

хотел поправить, но потом посмотрел сообщения — и не стал. не хочется бороться с такой страстью к обобщениям.

D>сорри, ниче личного, но это реально факт.

продолжайте плиз. человечество замерло в ожидании новых откровений.

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

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

M>>Это меня ошарашило. Я несмотря на то, что казалось бы имею давний опыт программирования на Delphi еще с 90-х годов и иногда периодически что-то писал, не знал, что exit внутри try...finally вызывает не немедленный выход из функции, а переход к блоку finally. Думал, что этот блок исполняется только в нормальном случае или при исключениях, а exit немедленно завершает функцию.

_>Не в качестве сарказма, а действительно любопытно — 2ALL: а где нибудь есть иное поведение?
_>И можно как нибудь вывернуться и это переопределить, скажем, на Java?

Да, можно. Написать System.exit(...);

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

D>программисты на дельфи — это всегда очень печальное зрелище. хуже только программисты на 1С

ещё c#

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

M>Я иногда кое-что пишу или отлаживаю на Delphi или FreePascal (не только на них и вообще это не так важно). Сегодня отлаживал одну ошибку, программа почему-то падала. Выяснил, что падение возникает из-за ошибок в некоторых данных (это другая история), которые программа забывала проверить на корректность.

Вот чтобы подобной ерундой не заниматься, и были придуманы юнит-тесты.

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

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

M>>Это меня ошарашило. Я несмотря на то, что казалось бы имею давний опыт программирования на Delphi еще с 90-х годов и иногда периодически что-то писал, не знал, что exit внутри try...finally вызывает не немедленный выход из функции, а переход к блоку finally.

D>программисты на дельфи — это всегда очень печальное зрелище. хуже только программисты на 1С
D>сорри, ниче личного, но это реально факт.

Знаете, ничего личного, но, например, я, с высоты 11+-летнего опыта промышленной разработки на целой куче императивных языков, не вижу принципиальной разницы между дельфи, крестиками, джавой, шарпом, и чем-бы то ни было ещё императивным. В разных языках есть разные плюшки и фичи, иногда кажущиеся ненужными, но при этом, на самом деле, являющиеся весьма важными. Суть и стиль разработки всё равно не меняется. Не хочу начинать холивар, но дельфи — вполне нормальный императивный объектно-ориентированный язык. И довольно эффективный, учитывая мощь VCL, лёгкость клепания формочек, и офигенский RTTI. Другим компилируемым языкам до этого RTTI -- пахать и сеять. Другой вопрос, что сам факт использования exit() не говорит в пользу автора. Это, имхо, примерно как goto.

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

L>Вот чтобы подобной ерундой не заниматься, и были придуманы юнит-тесты.

правильно, они придуманы чтоб другой ерундой заниматься.
обсуждалось не раз.

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

M>Это меня ошарашило. Я несмотря на то, что казалось бы имею давний опыт программирования на Delphi еще с 90-х годов и иногда периодически что-то писал, не знал, что exit внутри try...finally вызывает не немедленный выход из функции, а переход к блоку finally. Думал, что этот блок исполняется только в нормальном случае или при исключениях, а exit немедленно завершает функцию. Ошибался. Теперь удивляюсь, как же я умудрился раньше не нарваться на ошибки в этом месте (дважды вызов Free например из-за этого)

после второго курса любая прога на делфи начиналась у меня с {$O-}. Раз потратил вечер на понимание как в коде

for i:=0 to 7 do
 ...

i принимает значение 8, 9 и только потом выходит. А ответ прост как сало без хлеба: баг оптимизации.

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

L>>Вот чтобы подобной ерундой не заниматься, и были придуманы юнит-тесты.

CL>правильно, они придуманы чтоб другой ерундой заниматься.

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

C>я както во фрискейле работал — так у них там с одной игрушкой типа волка ловящего яйца,
C>гдето на 14 часу игры проскакивал глюк .
мультик?

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

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

L> для кого юнит-тесты эквивалентны занятию ерундой, срочно сменить профессию.
L> Других мнений по этому поводу быть не может.
а вы тесты писали? насколько серьезно подходили к процессу их разработки? у вас была формальная модель, доказывающая корректность, непротиворечивость и полноту теста? сомнительно. и какая польза от теста, который что-то тестирует? конечно, польза есть, но если вы углубитесь в теорию и практику тестирования, то очень быстро убедитесь, что существуют и другие пути.

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

в чем принципиальная разница:
а) программу запустили и она вроде как работает;
б) программа прошла все тесты, которые вы написали.

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

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

если вы не согласны и уверены в себе и своих знаниях -- плз, напишите функцию факториала вместе с тестом.

Если никто не знает как это должно работать, ничего не поможет. Юниттесты скорее для другого: ловить случаи когда все работало и вдруг бац — сломалось.

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

L>Если никто не знает как это должно работать, ничего не поможет. Юниттесты скорее для другого: ловить случаи когда все работало и вдруг бац — сломалось.
ок. factorial = gamma(n) + 1. если гамма считается приближенно, то factorial = gamma(n), но при этом 0! выдаст очень странный результат. допустим, в оригинале было factorial = gamma(n) + 1, кто-то убрал '+1'. юнит тест не проверял факторил нуля. и все типа работает. а потом -- бац! и кто-то передал в функцию ноль. чем поможет юнит-тест? а ничем.

или вот классический случай вычисления факториала через рекрусию:

int factorial(int n) {
return n == 0 ? 1 : n * factorial(n — 1);
}


передайте функции -1 и посмотрите, что произойдет.

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

/> хотел поправить, но потом посмотрел сообщения — и не стал. не хочется бороться с такой страстью к обобщениям.

Это проходит обычно, позже.

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

l> Тем, для кого юнит-тесты эквивалентны занятию ерундой, срочно рекомендуется сменить профессию. На сантехника или там развозчика пиццы.
l> Других мнений по этому поводу быть не может.

Интересно за что сантехников обидели ) Думаете так просто сантехником работать или там думать не надо? )

ЗЫ. Я не сантехник

Здравствуйте, мыщъх, Вы писали:

L>> для кого юнит-тесты эквивалентны занятию ерундой, срочно сменить профессию.
L>> Других мнений по этому поводу быть не может.
М>а вы тесты писали? насколько серьезно подходили к процессу их разработки?

Почему в прошедшем времени?

Остальное поскипано как очередная история очередного ниасилинга с кучей оправданий одно другого убедительнее. Обсуждения не заслуживает.

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

W>Интересно за что сантехников обидели ) Думаете так просто сантехником работать или там думать не надо? )

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

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


N>после второго курса любая прога на делфи начиналась у меня с {$O-}. Раз потратил вечер на понимание как в коде

N>

N>for i:=0 to 7 do
N> ...
N>

N>i принимает значение 8, 9 и только потом выходит. А ответ прост как сало без хлеба: баг оптимизации.

Не нарывался на именно такой баг. Это в какой версии он был?
В любом случае, в моей ситуации оптимизация не причем и бага не было, было очень неприятно меня удивившее не точное знание как работают исключения или вернее, как работает exit.

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

> Другой вопрос, что сам факт использования exit() не говорит в пользу автора. Это, имхо, примерно как goto.

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

Здравствуйте, мыщъх, Вы писали:

М>int factorial(int n) {
М> return n == 0 ? 1 : n * factorial(n — 1);
М>}


М>передайте функции -1 и посмотрите, что произойдет.

кстати!
хороший принцип для DoS.
и как я раньше об этом не подумал...

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

M>Не нарывался на именно такой баг. Это в какой версии он был?
7я кажется, может 6я. Думаю воспроизвести будет непросто, надо какое-то стечение случайных факторов

M>В любом случае, в моей ситуации оптимизация не причем и бага не было, было очень неприятно меня удивившее не точное знание как работают исключения или вернее, как работает exit.
дык на то он и finally

Здравствуйте, мыщъх, Вы писали:
М> программист, который писал функцию факториала был не в курсе что такое факториал вообще и очень сильно удивился, когда _все_ калькуляторы считали факториалы дробных чисел. программист сказал, что они все идиоты и едут по встречной, а он находится в своем ряду.
А можно для тупых поподробней. Я всегда считал, что факториал определён только для целых неотрицательных чисел. Гамма функция это какбы не совсем факториал.

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

D>>программисты на дельфи — это всегда очень печальное зрелище. хуже только программисты на 1С
D>>сорри, ниче личного, но это реально факт.

HS>Знаете, ничего личного, но, например, я, с высоты 11+-летнего опыта промышленной разработки на целой куче императивных языков, не вижу принципиальной разницы между дельфи, крестиками, джавой, шарпом, и чем-бы то ни было ещё императивным.

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

лет 10 назад мне довелось отсмотреть кучу (больше сотни) мелких проектов, сделанных разными людьми; больше половины из них на дельфи.
статистика однозначная — сделанное на дельфи очень сильно проигрывает тому же С++.

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

M>>Это меня ошарашило. Я несмотря на то, что казалось бы имею давний опыт программирования на Delphi еще с 90-х годов и иногда периодически что-то писал, не знал, что exit внутри try...finally вызывает не немедленный выход из функции, а переход к блоку finally. Думал, что этот блок исполняется только в нормальном случае или при исключениях, а exit немедленно завершает функцию.

_>Не в качестве сарказма, а действительно любопытно — 2ALL: а где нибудь есть иное поведение?
В Java также (exit — читай return). И это, кстати, это довольно стандартный вопрос на собеседованиях и во всяких тестах.

_>И можно как нибудь вывернуться и это переопределить, скажем, на Java?
System.exit()

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

D>Здравствуйте, мыщъх, Вы писали:
М>> программист, который писал функцию факториала был не в курсе что такое факториал вообще и очень сильно удивился, когда _все_ калькуляторы считали факториалы дробных чисел. программист сказал, что они все идиоты и едут по встречной, а он находится в своем ряду.
D>А можно для тупых поподробней. Я всегда считал, что факториал определён только для целых неотрицательных чисел. Гамма функция это какбы не совсем факториал.

У Кнута, буквально чютьли не на первых страницах есть непрерывный график факториала.

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

M>Это меня ошарашило. Я несмотря на то, что казалось бы имею давний опыт программирования на Delphi еще с 90-х годов и иногда периодически что-то писал, не знал, что exit внутри try...finally вызывает не немедленный выход из функции, а переход к блоку finally. Думал, что этот блок исполняется только в нормальном случае или при исключениях, а exit немедленно завершает функцию. Ошибался. Теперь удивляюсь, как же я умудрился раньше не нарваться на ошибки в этом месте (дважды вызов Free например из-за этого)
Всегда вспоминай этот случай, прежде чем создавать темы, подобные этой

Автор: Michael7
Дата: 14.06.12

.

Здравствуйте, мыщъх, Вы писали:

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

L>>Если никто не знает как это должно работать, ничего не поможет. Юниттесты скорее для другого: ловить случаи когда все работало и вдруг бац — сломалось.
М>ок. factorial = gamma(n) + 1. если гамма считается приближенно, то factorial = gamma(n), но при этом 0! выдаст очень странный результат. допустим, в оригинале было factorial = gamma(n) + 1, кто-то убрал '+1'. юнит тест не проверял факторил нуля. и все типа работает. а потом -- бац! и кто-то передал в функцию ноль. чем поможет юнит-тест? а ничем.
Я вам про фому, а вы мне про ерему. Вы как раз про тот случай когда автор кода толком не понимает чего он от своего кода хочет. А я про то, что юниттесты нужны чтобы не отвалилось что-то что раньше точно работало.

М>или вот классический случай вычисления факториала через рекрусию:

М>int factorial(int n) {
М> return n == 0 ? 1 : n * factorial(n — 1);
М>}

Мой вариант будет таким:

unsigned long factorial(int n)
{
    static const unsigned long fact_tab[13] = {
        1, 1, 2, 6, 24, 120, 720, 5040, 40320, 362880, 3628800, 39916800, 479001600
    };
    if (n < 0 || n >= _countof(fact_tab)) throw std::invalid_argument("invalid factorial arg");    
    return fact_tab[n];
}

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

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

M>И exit и goto в определенных обстоятельствах очень удобны. Например, чтобы быстро выйти из вложенного цикла. Как раз потому что я редко пользовался exit-ом, такое непонимание его работы долго оставалось незамеченным. Ну и плюс, оказывается, в реальных программах функции работы с памятью могут чаще, чем кажется, прощать ошибки.
Это знаешь, как на красный иногда можно проехать. Можно, конечно. И временами действительно удобно. Но именно из-за таких решений в свою пользу и появляются ошибки. Решил ты, что здесь goto удобен, Вася Пупкин тоже решил в свою очередь, а потом и Баба Марья написала такую фигню в другом месте. И оба-на! Теперь у вас куча goto в проекте, написанные разными людьми. Потому и говорят: не пиши goto. Вот просто не пиши и всё.

Здравствуйте, LLIMblrA, Вы писали:
LLI>У Кнута, буквально чютьли не на первых страницах есть непрерывный график факториала.
Факториала? Я не спорю, что есть функции, которые проходят через все точки, в которых определен факториал (гамма-функция). Но сам факториал определен только для целых неотрицательных чисел. Педивикия со мной согласна.

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

N>после второго курса любая прога на делфи начиналась у меня с {$O-}. Раз потратил вечер на понимание как в коде

for i:=0 to 7 do
 ...

N>i принимает значение 8, 9 и только потом выходит. А ответ прост как сало без хлеба: баг оптимизации.

Если i нигде не используется, то какая разница какое значение i принимает?

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

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

M>>И exit и goto в определенных обстоятельствах очень удобны. Например, чтобы быстро выйти из вложенного цикла. Как раз потому что я редко пользовался exit-ом, такое непонимание его работы долго оставалось незамеченным. Ну и плюс, оказывается, в реальных программах функции работы с памятью могут чаще, чем кажется, прощать ошибки.
MM>Это знаешь, как на красный иногда можно проехать. Можно, конечно. И временами действительно удобно. Но именно из-за таких решений в свою пользу и появляются ошибки. Решил ты, что здесь goto удобен, Вася Пупкин тоже решил в свою очередь, а потом и Баба Марья написала такую фигню в другом месте. И оба-на! Теперь у вас куча goto в проекте, написанные разными людьми. Потому и говорят: не пиши goto. Вот просто не пиши и всё.
Если всех ровнять под одну гребенку и огульно запрещать всё что может привести к ошибкам, то получим бредовый и неадекватный coding style. Я видел как goto-ненавистники лепили мега-монстра с кучей хитровложенных ифов, do-while и свитчей только для того чтобы правильно выйти из нескольких циклов. Там без бутылки не поймешь когда и куда оно выходит, лучше бы написали goto.

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

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

N>>после второго курса любая прога на делфи начиналась у меня с {$O-}. Раз потратил вечер на понимание как в коде
D>

D>for i:=0 to 7 do
D> ...

N>>i принимает значение 8, 9 и только потом выходит. А ответ прост как сало без хлеба: баг оптимизации.

D>Если i нигде не используется, то какая разница какое значение i принимает?

Многоточие может означать не только глубину и полет мысли, но и какой-то код, который можно скипнуть в моем случае это был проход по графу, потому зашкаливание i играет таки большую роль

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


M>Мораль в качестве выводов:

M>1) Если есть ошибка полезно докопаться до ее истоков, а не просто избавиться от нее.
M>2) Можно обнаружить что-то для себя новое в казалось бы давно и хорошо известном.

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

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

_>Не в качестве сарказма, а действительно любопытно — 2ALL: а где нибудь есть иное поведение?

Нигде не видел. Да и какой тогда смысл в finally? Этот конструкция специально придумана для того, чтобы гарантированно выполнить определенные действия, что бы ни случилось внутри блока.

_>И можно как нибудь вывернуться и это переопределить, скажем, на Java?

Именно в java на уровне языка и компилятора — никак. Можно изменить скомпиленный байткод, но это грязный хак.

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

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

C>>я както во фрискейле работал — так у них там с одной игрушкой типа волка ловящего яйца,
C>>гдето на 14 часу игры проскакивал глюк .

не все ошибки проверяемы до конца

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

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

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

C>>>я както во фрискейле работал — так у них там с одной игрушкой типа волка ловящего яйца,
C>>>гдето на 14 часу игры проскакивал глюк .

C>не все ошибки проверяемы до конца
Если пользователь не обнаружил ошибки, то можно считать, что её и нет.

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

L>Здравствуйте, мыщъх, Вы писали:

L>>> для кого юнит-тесты эквивалентны занятию ерундой, срочно сменить профессию.
L>>> Других мнений по этому поводу быть не может.
М>>а вы тесты писали? насколько серьезно подходили к процессу их разработки?
L>Почему в прошедшем времени?
потому что русский язык такой. в английском было бы Present Perfect Tense --> опыт есть: да/нет

L>Остальное поскипано как очередная история очередного ниасилинга
L>с кучей оправданий одно другого убедительнее. Обсуждения не заслуживает.
а вы осилите тест факториала? хотя бы на уровне псевдокода? если да, то почему вы не миллионер?

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

D>Здравствуйте, мыщъх, Вы писали:
М>> программист, который писал функцию факториала был не в курсе что такое факториал вообще и очень сильно удивился, когда _все_ калькуляторы считали факториалы дробных чисел. программист сказал, что они все идиоты и едут по встречной, а он находится в своем ряду.
D>А можно для тупых поподробней. Я всегда считал, что факториал определён только для целых неотрицательных чисел. Гамма функция это какбы не совсем факториал.

русскую вику не читал, английская не только говорит, что факториал определен для дробных, но даже объясняет как его считать. если писать в одну строчку и наплевать на точность, то будет примерно так:

#define E 2.71828182845904523536
#define PI 3.14159265358979323846

// stirling's formula
double gamma_fun(double x) { return sqrt(2.0 * PI/x) * pow(x/E, x); }
double factorial(double x) { return gamma_fun( x + 1); }

возьмите факториал от дроби и сравните с виндовым калькулятором. ну или с любым он-лайн калькулятором (вдруг это ошибка виндового калькулятора), вот первая ссылка в гугле: http://www.calculator-tab.com/

факториал часто используется в статистике и там он часто бывает дробным. факториал для целых чисел это школьный курс. школьный курс + факультатив -- там задачки взять факториал дробного числа.

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

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

M>Я иногда кое-что пишу или отлаживаю на Delphi или FreePascal (не только на них и вообще это не так важно). Сегодня отлаживал одну ошибку, программа почему-то падала. Выяснил, что падение возникает из-за ошибок в некоторых данных (это другая история), которые программа забывала проверить на корректность. Добавил проверку. Можно было бы успокоиться, что все заработало, но решил выяснить, из-за чего она все-таки падала при неправильных данных.

M>Это меня ошарашило. Я несмотря на то, что казалось бы имею давний опыт программирования на Delphi еще с 90-х годов и иногда периодически что-то писал, не знал, что exit внутри try...finally вызывает не немедленный выход из функции, а переход к блоку finally. Думал, что этот блок исполняется только в нормальном случае или при исключениях, а exit немедленно завершает функцию. Ошибался. Теперь удивляюсь, как же я умудрился раньше не нарваться на ошибки в этом месте (дважды вызов Free например из-за этого)

M>Мораль в качестве выводов:

M>1) Если есть ошибка полезно докопаться до ее истоков, а не просто избавиться от нее.
M>2) Можно обнаружить что-то для себя новое в казалось бы давно и хорошо известном.

Из своего опыта:
Если был глюк, и после не понятных телодвижений он исчез, жди глюка снова.
Если был глюк, и понятно откуда у него ноги растут, то ноги отрываем и наслаждаем отсутствием глюка.

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

L>Здравствуйте, мыщъх, Вы писали:

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

L>Я вам про фому, а вы мне про ерему. Вы как раз про тот случай когда автор кода толком не понимает чего он от своего кода хочет. А я про то, что юниттесты нужны чтобы не отвалилось что-то что раньше точно работало.

так ведь отвалится. и сейчас я объясню почему.

L>unsigned long factorial(int n)
L>{
L> static const unsigned long fact_tab[13] = {
L> 1, 1, 2, 6, 24, 120, 720, 5040, 40320, 362880, 3628800, 39916800, 479001600
L> };
L>Вариант безглючный и самотестирующийся.

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

но даже если исходить из допущения, что оптимизация не влечет потерю точности, то у вас таблица все равно не правильная. ну ладно, заполняли от балды. бывает. меня вот что интересует -- с каких это пор размер int'а стал строго определенным? или вы никогда не писали программу под 2+ платформы сразу? если int у нас 64 бита (а такое возможно), то тут нужно сначала посмотреть какой у нас int на данной конкретной платформе, а уже потом выбирать под него таблицу. а если int 16 бит (такое тоже бывает), то ваш тест снова выстрелит мимо.

писать тест, который работает только в паре с определенным компилятором и под определенную платформу с определенными опциями компиляции -- на фига? вот перекомпилировали код и ваш тест показал ошибку. а ошибка не в коде, а в тесте. крысота.

> Если понадобится факториал дабла, отрицательных чисел, натуральных дробей, и.т.д,
> то буду делать по учебнику, применяя подходящие к случаю типы данных.
пытаюсь объяснить еще раз. в реальной жизни куча функций типа факториала считается приближенно, ибо точный результат зачастую менее важен, чем скорость вычислений. проблема даже не в том, чтобы вычислить 100000! (можно и по таблице), проблема в том -- как хранить такой большой bignum и что с ним делать.

а приближенные вычисления это такая область, в которой очень трудно что либо тестировать, ибо нужен эталон, а эталона нету, но есть (скажем) библиотечная функция, которая так же считает приближенно. сравнивать два приближенных значения -- нельзя, ибо мы не знаем в какую сторону у нас отклоение в каждом конкретном случае.

да, и еще. совсем забыл. время вычислений -- вполне себе метрика. нормальный тест должен проверять -- не впадает ли функция в нирвану глубокой задумчивости минут на полчаса. возьме тот же винкалк. при всей его простоте он предлагает остановится или считать дальше, т.к. в противном случае в однопоточных приложениях нельзя даже закрыть окно -- все повисло нахрен. у вас есть такая проверка? а она нужна. потому что после изменений программа может впасть в дурной цикл и никогда не завершится. элементарно, ватсон, кто-то напишет while(1); и привет обкому. вы же не руками запускаете каждый тест, верно? у вас же это автоматизировано. вот вы запустили тесты и пошли курить. вернулись и... балин. оно повисло. логи-то есть? а если есть, то был ли сброшен дисковый буффер перед входом в цикл?

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

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

Здравствуйте, мыщъх, Вы писали:

М>>>а вы тесты писали? насколько серьезно подходили к процессу их разработки?
L>>Почему в прошедшем времени?
М>потому что русский язык такой. в английском было бы Present Perfect Tense --> опыт есть: да/нет

Двойка тебе. Как по русскому, так и по английскому. В контексте обсуждения на русском нужно использовать настоящее "вы тесте пишете?", а на английском present continous "are you writing unit tests (at all)?".

L>>Остальное поскипано как очередная история очередного ниасилинга
L>>с кучей оправданий одно другого убедительнее. Обсуждения не заслуживает.
М>а вы осилите тест факториала? хотя бы на уровне псевдокода? если да, то почему вы не миллионер?

При всем уважении, ты пытаешься лезть в область, в которой нихрена не понимаешь. Это я про тестирование. Я даже не знаю, с чего начать, чтобы объяснить глубину твоего заблуждения, и считаю, что будет просто честным предложить оставаться тебе в своем хакерском R&D мире и не лезть в инженерные задачи в своих латексных перчатках. У нас требуются сертифицированные перчатки другой системы, и несоблюдение техники безопасности бывает фатальным.

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

Далее, факториал, точнее, то, что принято называть факториалом, на C++ вычисляется в compile time. Его можно тестировать, но смысла особого нет. Но и твою притянутую за уши реализацию гамма-функции я тоже протестирую, но при одном условии — если ты асилишь обозначить четкие критерии ее использования в программе, ее предназначение, ограничения и ожидаемое поведение. Если этого нет, то разочарую тебя — прикладной аналитикой занимаются на другом этаже.

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

CL>объясните идиоту, пожалуйста,
CL>как можно использовать try...finally и не знать как оно работает?

Можно знать как работает finally, можно знать как работает exit. Но можно не знать как они работают вместе. У кого, так сказать, приоритет.

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


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

Тогда немного опишу, что же именно некорректного было в данных. У меня функция заносит в БД извлеченное и обработанное содержимое некоторых файлов внутри *.zip -файлов, при этом естественно проверяет на корректность и само содержимое обрабатываемых файлов и формат и тд. При этом в редких случаях внутри *.zip-файла может быть еще вложенные *.zip-файлы и их тоже надо распаковать и в свою очередь проверить, что внутри. Вложенный файл я обрабатывал просто рекурсивным вызовом.

Тесты (просто набор разных исходных данных) есть, все ситуации с ошибками тестировали и они обрабатывались, программа не падала.

Но забыли протестировать случай, когда такая ошибка возникает при работе с содержимым внутри вложенного файла. То есть, неправильная работа с exit не приводила почему-то к падениям, пока работа шла на первом уровне вложенности. Я и говорю, что диспетчер памяти оказался склонным прощать некоторые ошибки в работе с ней. Падать стало внутри рекурсии.

Программу я уже не трогал с год, просто все это время не случалось такого редкого сочетания с ошибкой.

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

L>Здравствуйте, мыщъх, Вы писали:

М>>потому что русский язык такой. в английском было бы Present Perfect Tense --> опыт есть: да/нет
L>Двойка тебе. Как по русскому, так и по английскому. В контексте обсуждения на русском нужно
L>использовать настоящее "вы тесте пишете?", а на английском present continous
L>"are you writing unit tests (at all)?".
единица вам. "are you writing..." вы пишите тест _одновременно_ с чтением форума. вы юлий цезарь?
Present Perfect Tense переводится как "вы _когда_ _либо_ писали тесты?". по аналогии I've been in London. это отличается от I was in London. в первом случае это "у меня есть жизненный опыт и я знаю что такое Лондон не только по картинкам", во втором случае вы просто там были. например, вас спрашивают -- какого хрена вас вчера не было на рабочем месте. а вы отвечаете: I was in London.

L> При всем уважении, ты пытаешься лезть в область, в которой нихрена не понимаешь.
L> Это я про тестирование. Я даже не знаю, с чего начать, чтобы объяснить глубину
с критическими инфраструктурами я не сталкивался и как там тестируют по — хз, но энерпрайз и военка -- это для меня ежедневная рутина. показывать им юнит тесты все равно что показывать палец. юмора не поймут и слив защитан.

повторяю еще раз -- тест должен _доказать_ полноту и непротиворечивость. преобразование программы в диаграмму типа flow chart с последующей верификацией позволяет _доказать_, что она корректна (тут кажется кто-то упоминал светофор в качестве примера, кажется в контексте дракона. существуют системы верификации по, доказывающие, что два зеленых света гореть не могут. а доказать это можно если перевести ваш юнит в fsm, но это не юнит тест, это _совсем_ другое).

> У нас требуются сертифицированные перчатки другой системы
> и несоблюдение техники безопасности бывает фатальным.
ваша пися больше моей? хорошо, давайте возьмем линейку, какими ISO вы руководствуетесь? понимаете, юнит-тест это сугубо ваше личное (можно даже сказать интимное) дело. никому кроме вас он на хрен не нужен и не интересен. когда будете сдавать продукт серьезному заказчику (банку, скажем) от вас потребуют совсем других тестов. какая там техника безопасности, о чем вы? есть формальные требования, вы им следуете. строите формальные модели.

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

L> Списывание отсутствия тестов на недостаточность ресурсов — это безоговорочное
L> признание в собственной некомпетентности и прямая путевка за кассу в Макдональдс.
пытаюсь объяснить еще раз -- сложность _полного_ теста намного превышает сложность того, что мы тестируем. откроейте глаза и посмотрите на то, что вас окружает. начиная с программного обеспечения и заканчивая медикаментами. далеко не все это тестируется, а если и тестируется, то неполно и поверхностно. ракетно-космическая техника тестируется лучше, чем гражданская авиация, а гражданская авиация тестируется лучше, чем бытовой софт. а если бытовой софт тестировать по полной программе, то это все равно не гарантирует отсутствие ошибок, но цена ms office перевалит за миллиард баксов за одну лицензию. что вы курили?

> Сколько у него там на отладку ушло времени? Вот то-то и оно.
был бы отладочная печать -- было бы видно, где оно падает. но отладочной печати у него нету. а что мне делать если я аппаратно-программный комплекс разрабатываю? концепция интерактивной отладки к нему вообще не применима. даже логгировать нельзя в силу определенных ограничений (требования к сертификации -- отсутствие винта, а память не резиновая, ее и так мало и в случае краха системы в памяти ничего не будет, а если бы и было...)

L> Далее, факториал, точнее, то, что принято называть факториалом, на C++ вычисляется в compile time.
см. определение из вики. см. функцию факториала из гну либы на gcc.

L> Его можно тестировать, но смысла особого нет.
поздравляю. вы произнесли заветные слова. "тестировать можно, но на хрена?". то есть по факту вы со мной согласны, но при этом делаете вид, что один из нас дурак, хотя мы оба говорим, что юнит-тест написать можно, но смысла в этом нет.

L> Но и твою притянутую за уши реализацию гамма-функции я тоже протестирую,
она не моя. она из 18 века вообще-то. а сейчас 21 век. столько не живут ИМХО.

L> но при одном условии — если ты асилишь обозначить четкие критерии ее использования в программе,
лопата! вот у вас есть библиотечная гамма-функция. а она у вас есть (если под никсы пишите). и у вас возникает вопрос -- как быстро она работает? насколько сильно ошибается? вы хотите знать подходит ли она вам или нет. у вас есть требования по точности и времени. известны и целевые платформы. дело за малым -- убедиться, что все воркается. и вот тут выясняется, что тестирование функции которая заведово работает выливается в сложную инженерную задачу...

L> Если этого нет, то разочарую тебя — прикладной аналитикой занимаются на другом этаже.
вот он -- момент просветления. на уровне юнит-теста вы не можете сказать какие у вас требования к данной функции. допустим, время отклика системы должно быть не хуже 15 ms на таком-то железе. это во всей совокупности.

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

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

CL>>объясните идиоту, пожалуйста,
CL>>как можно использовать try...finally и не знать как оно работает?
A>Можно знать как работает finally, можно знать как работает exit. Но можно не знать как они работают вместе. У кого, так сказать, приоритет.
проблема несколько глубже. результаты уже на лице -- в жабе стало нельзя легально прибивать потоки без участия с их стороны. допустим, мы вызвали скрипт манагер из жабы, который вызывает жаба-скрипт, контролируемый юзером/хакером. допустим, в жаба-скрипте while(1); -- в результате поток висит. легально снять -- нельзя. нелегально можно, но это уже хак.

так же есть расширения для руби и питона, позволяющие вызывать движок google v8. и у большинства нет легальных механизмов отвалиться по тайм-ауту. как ни странно у фокса этот муханизм есть. точнее был. сейчас к нему прикрутили JIT и оно перестало работать (раньше интерпретатор байт-кода тупо считал итерации).

если брать обработку исключений в венде, то там можно обнаружить два уровня. первый уровень -- это когда стек уже кончился, но запас по прочности еще есть. в этом момент выбрасывается нормальное исключение о том, что стека нет (на самом деле есть, но мало). фишка в том, что повторно это исключение уже не вызываается и когда стек заканчивается, то он заканчивается, а обработчик исключений требует стека для себя любимого, а стека у нас нет. в XP в этом случае винда вела себя... мягко говоря не совсем так, как описано в документации. процесс умирал в ядре без освобождения ресурсов (точнее, с негарантированным их освобождением). в семерке уже пофиксили это и добавили (грубо говоря) еще один уровень "finally" (в кавычках, потому что finally пришел из плюсов, но его концепция намного шире) и теперь у нас есть (грубо говоря) процедура аварийного завершения процесса (ядерная) и процедура аврального аварийного завершения процесса. разница между ними в том, что одна из них _гарантирует_ выполнение finally, а другая всего лишь намеревается это сделать.

как бы наивно предполгать, что try...finally работает. оно не работает. оно лишь предполагает. а бог располгает. библиотечные функции, родные для данной системы, скорее всего, придерживаются try...finally (если в спецификации не оговорено обратное), но как поведет себя произвольная функция -- сказать нельзя, особенно если эта функция древняя и оставлена только для совместимости.

короче, лучше не использовать конструкции языка, которых не знаешь.

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

L>Здравствуйте, мыщъх, Вы писали:

L>При всем уважении, ты пытаешься лезть в область, в которой нихрена не понимаешь. Это я про тестирование. Я даже не знаю, с чего начать, чтобы объяснить глубину твоего заблуждения, и считаю, что будет просто честным предложить оставаться тебе в своем хакерском R&D мире и не лезть в инженерные задачи в своих латексных перчатках. У нас требуются сертифицированные перчатки другой системы, и несоблюдение техники безопасности бывает фатальным.

Мне, на самом деле, давно интересно собрать статистику, сколько раз regression unit tests вылавливало ошибки, сколько раз после успешного тестирования ошибки все равно обнаруживались и сколько раз test failures ловили ошибки кода, а не теста.

Потому что в теории это классная вещь — написали тесты и теперь никто не изменит так, что оно перестанет работать. В практике я ни разу еще не видел, чтобы это работало. Создание хороших тестов работа более трудозатратная, сложная и высококвалифицированная нежели создание самого кода для бизнес логики. Но даже с хорошими тестами все равно ошибки возможны. И затраты на поддержание онных достаточно велики.

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

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

Это наблюдения из практики как она есть — никаких теорий.

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

D>>>программисты на дельфи — это всегда очень печальное зрелище. хуже только программисты на 1С
D>>>сорри, ниче личного, но это реально факт.

HS>>Знаете, ничего личного, но, например, я, с высоты 11+-летнего опыта промышленной разработки на целой куче императивных языков, не вижу принципиальной разницы между дельфи, крестиками, джавой, шарпом, и чем-бы то ни было ещё императивным.

D>между тем она есть. и даже не в самом языке дело.

Вот видите! Не в языке.

D>дельфи создает иллюзию простоты,

Там не иллюзия простоты, там (на момент конца 90-х и начала нулевых) -- неиллюзорная простота разработки нативных оконных приложений под Windows.
Microsoft к такой простоте формоклепания пришёл значительно позже. Значительно. Если вообще пришёл.

То, что в системе язык-библиотека-среда программирования есть простота -- это плохо?

D>там низкий порог вхождения,

1. Это плохо?
2. Там, между тем, гораздо проще выстрелить себе в ногу, чем, например, в C#. Не в этом дело.

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

В самом верху не ваша ли цитата? У вас там квантор всеобщности стоит.

D>лет 10 назад мне довелось отсмотреть кучу (больше сотни) мелких проектов, сделанных разными людьми; больше половины из них на дельфи.

Я тоже как раз 10 лет назад поддерживал кучу дельфийского говнокода. Качество кода говорит только о его авторе, но не об использованых средствах разработки.

D>статистика однозначная — сделанное на дельфи очень сильно проигрывает тому же С++.

О дааа. Предлагаю сравнить VCL, сделанную людьми и для людей на дельфи, и MFC, которую, видимо, завезли с Марса. Такое о ней, во всяком случае, сложилось впечатление.
Впрочем, нет. Не предлагаю. Холивар уже разгорается, а в спец. олимпиадах мне участвовать неинтересно.

Сама IDE Delphi написана на Delphi, и уж что-что, а формочки клепать на ней куда как удобнее, чем в VS. То есть, по крайней мере по параметру удобства клепания формочек (==проектированию и программированию оконного интерфейса), дельфи впереди VS. И что теперь?

Впрочем, должен сказать, что Delphi я не видел уже лет шесть. Говорят, там есть новые плюшки типа дженериков и перегрузки операторов, но это я не в курсе. Ибо если ты работаешь с железом и пишешь дрова, выбора, на чём писать, у тебя нет.

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

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

N>

N>for i:=0 to 7 do
N> ...
N>

N>i принимает значение 8, 9 и только потом выходит. А ответ прост как сало без хлеба: баг оптимизации.

Т.е. цикл итерируется больше 8-ми раз? Такого не встречал.. А вот по поводу "i" после цикла, помню что в таком коде в турбо-паскале она бы равнялась 7-ми, что исключало возможность использовать её значение. В Delphi, вроде как, ситуацию исправили, но при попытке использования выдаётся warning...

Здравствуйте, linuz, Вы писали:
L> Я видел как goto-ненавистники лепили мега-монстра с кучей хитровложенных ифов, do-while и свитчей только для того чтобы правильно выйти из нескольких циклов. Там без бутылки не поймешь когда и куда оно выходит, лучше бы написали goto.

А нечего было так глубоко залазить

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

SUA>Здравствуйте, linuz, Вы писали:
L>> Я видел как goto-ненавистники лепили мега-монстра с кучей хитровложенных ифов, do-while и свитчей только для того чтобы правильно выйти из нескольких циклов. Там без бутылки не поймешь когда и куда оно выходит, лучше бы написали goto.

SUA>А нечего было так глубоко залазить

То есть, чтобы не использовать goto теперь надо еще и от вложенных циклов отказаться?

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


CL>>объясните идиоту, пожалуйста,
CL>>как можно использовать try...finally и не знать как оно работает?

A>Можно знать как работает finally, можно знать как работает exit. Но можно не знать как они работают вместе. У кого, так сказать, приоритет.

Ну, в доках явы, скажем, все описано в паре строчек:

The finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. But finally is useful for more than just exception handling — it allows the programmer to avoid having cleanup code accidentally bypassed by a return, continue, or break. Putting cleanup code in a finally block is always a good practice, even when no exceptions are anticipated.

http://docs.oracle.com/javase/tutorial/essential/exceptions/finally.html

И эта ссылка первая по запросу "java finally". Так что можно прочитать только два первых предложения, чтобы понять суть.

Случаи с прерыванием потока или всего предложения описаны еще двумя предложениями ниже.

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

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

L>>Здравствуйте, мыщъх, Вы писали:

F> Мне, на самом деле, давно интересно собрать статистику, сколько раз regression unit tests вылавливало ошибки,
F> сколько раз после успешного тестирования ошибки все равно обнаруживались и сколько раз test failures
F> ловили ошибки кода, а не теста.
зачем ее собирать, когда она и так есть? http://www.cvedetails.com/ -- пища для размышлений. и ведь во всех этих компаниях есть целые подразделения, занимающиеся исключительно тестированием с нехилым таким бюджетом. а что на выходе? _абсолютно_ _ничего_ работающего хотя бы на 90%. это не значит, что тесты бесполезны. это значит, что на практике ошибки приходится фиксить _после_ релиза на стадии пуско-наладки. причем, эта вполне законная стадия, которой не избежал ни один проект.

F> В практике я ни разу еще не видел, чтобы это работало.
+500. товарищ привел тест, неявно подразумевающий, что у него int 32 бита. очень "полезный" тест, да.
даже если не брать факториал ( это все-таки матчасть ), а взять функцию сортировки, то даже в этом случае трудоемкость написания теста и его объем раз в сто больше. следовательно, в сто раз больше вероятность допустить ошибку в тесте.

при этом далеко не все поддается тестированию. если модуль работает с железом, то все. кранты. даже если железо -- проц. на блоге ms можно найти инфу о том, как проц генерил ошибку доступа к памяти в инструкции типа mov eax, ebx. в ms долго курили очень хорошую траву пока их не торкнуло, что крэш дамп памяти извлекается из памяти. а исключение генерит уже декодированная инструкция глубоко в недрах ЦП, который разогнан сцука и потому там совсем не то, что ожидалось.

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

> Создание хороших тестов работа более трудозатратная, сложная и высококвалифицированная
> нежели создание самого кода для бизнес логики. Но даже с хорошими тестами все равно
> ошибки возможны. И затраты на поддержание онных достаточно велики.
в том-то и дело, что написать парсер, скажем, XML раз в 100500 раз проще, чем написать тест этого парсера. в обоих случаях требуются глубокие знания XML. если их нет, то парсер написать еще можно и он будет как бы работать, а вот написать для него тест и _доказать_ полноту теста -- это высший пилотаж. и на практике применяется другой подход. берут "живые" данные и смотрят на реакцию парсера. если на каком-то файле парсер падает -- юзер сабмитит этот файл в саппорт и там уже разбираются. это -- реальная жизнь.

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

F> Но даже в более менее обычных бизнес-приложениях грамотный QA по фактору
F> количество пойманных багов и количеству затраченных ресурсов работает
F> значительно эффективней юнит тестов.
кстати, огромное кол-во ошибок вылезает на стыке разных модулей. интеграционные тесты рулят. и не только тесты. я уже писал про формальные модели и разные диаграммы состояний, наличие которых зачастую обязательное требование к проекту. без диаграмм состояний его просто не примут.

так же я писал про файл-бомбы нового поколения, где архиватор распаковывает архив с циклическими симлинками. а вот попытка архивации/бэкапа этой директории приводит к бесконечному рекурсивному спуску и краху. протестировав большое кол-во архиваторов и программ бэкапа, а так же утилит и программ пакетной обработки файлов я удивился -- в среднем из 100 программ только 1 проходит этот простой и банальный тест из чего я делаю вывод, что функцию обхода дерева каталогов вообще не тестировали, а если и тестировали, то в сферических условиях.

F>Это наблюдения из практики как она есть — никаких теорий.
в том-то и дело, что тесты -- не панацея. а юнит тесты это как целые числа на фоне всех прочих. и гордится тем, что у нас есть юнит тесты это все равно, что говорить "а я умею считать до ста тысяч миллионов".

чтобы что-то тестировать нужно иметь формальную модель этого самого того, что мы тестируем. а ее обычно нет. даже на примере парсера XML. ну есть спецификации разных версий, а есть ПО, генерирующее XML. часто бывает так, что ПО, генерирующее XML, являющийся нашими входными данными, противоречит спецификациям, но это ПО нам неподконтрольно. а заказчику класть на спецификации. ему нужно, чтобы две программы работали вместе, понимая друг друга.

тут кончается теория и начинается реальная жизнь. тест XML парсера, написанный по науке -- бесполезен, ибо парсер падает на "живых" данных, о которых тест и не подозревает. и в чем ценность такого теста? а если взять программу на JavaScript, то как ее тестировать юнит-тестами, если нам нужно, чтобы она нормально работала на всех браузерах? тестировать -- нужно. но не юнит тестами.

в реальной жизни основная нагрузка ложится на QA. они, в частности, проверяют, что в коде нет ошибок типа SQL-injection и вообще тестируют все, что только можно протестировать. а если у нас есть QA, то зачем вкладываться в юнит-тесты? да, конечно, юнит тесты бывают полезны местами, чтобы отлавливать наиболее грубые ошибки. но тут главное не перестараться и не вложить в юнит тест больше времени и сил чем нужно.

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


SUA>>Здравствуйте, linuz, Вы писали:
L>>> Я видел как goto-ненавистники лепили мега-монстра с кучей хитровложенных ифов, do-while и свитчей только для того чтобы правильно выйти из нескольких циклов. Там без бутылки не поймешь когда и куда оно выходит, лучше бы написали goto.

SUA>>А нечего было так глубоко залазить

M>То есть, чтобы не использовать goto теперь надо еще и от вложенных циклов отказаться?

Ну, вообще-то, желательно. Вложенные циклы без вынесения внутреннего в отдельную функцию, весьма трудночитаемы.

Здравствуйте, мыщъх, Вы писали:

М>проблема несколько глубже. результаты уже на лице -- в жабе стало нельзя легально прибивать потоки без участия с их стороны. допустим, мы вызвали скрипт манагер из жабы, который вызывает жаба-скрипт, контролируемый юзером/хакером. допустим, в жаба-скрипте while(1); -- в результате поток висит. легально снять -- нельзя. нелегально можно, но это уже хак.

Что в данном случае означает "вызвали скрипт манагер из джавы"? Ну, то есть, что есть скрипт манагер? Если это жабовкий класс, и он не имеет штатных методов остановки, то это не скрипт-манагер, а кусок говна. Если это внешний процесс, то остановить его очень легко.


М>если брать обработку исключений в венде, то там можно обнаружить два уровня. первый уровень -- это когда стек уже кончился, но запас по прочности еще есть. в этом момент выбрасывается нормальное исключение о том, что стека нет (на самом деле есть, но мало). фишка в том, что повторно это исключение уже не вызываается и когда стек заканчивается, то он заканчивается, а обработчик исключений требует стека для себя любимого, а стека у нас нет. в XP в этом случае винда вела себя... мягко говоря не совсем так, как описано в документации. процесс умирал в ядре без освобождения ресурсов (точнее, с негарантированным их освобождением). в семерке уже пофиксили это и добавили (грубо говоря) еще один уровень "finally" (в кавычках, потому что finally пришел из плюсов, но его концепция намного шире) и теперь у нас есть (грубо говоря) процедура аварийного завершения процесса (ядерная) и процедура аврального аварийного завершения процесса. разница между ними в том, что одна из них _гарантирует_ выполнение finally, а другая всего лишь намеревается это сделать.

М>как бы наивно предполгать, что try...finally работает. оно не работает. оно лишь предполагает. а бог располгает. библиотечные функции, родные для данной системы, скорее всего, придерживаются try...finally (если в спецификации не оговорено обратное), но как поведет себя произвольная функция -- сказать нельзя, особенно если эта функция древняя и оставлена только для совместимости.

В жабе проще. Там стек-то не нативный, и исключение полетит и обработается в любом случае(не тобой, так штатным обработчиком, установленным для этого потока, по умолчанию это вывод трейса в stderr). Потому можно не париться техническими трудностями: для исключения стека всегда хватит.

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

D>дельфи создает иллюзию простоты, там низкий порог вхождения, типичный дельфист — это формошлеп, слабо представляющий внутреннее устройство системы со всеми отсюда вытекающими последствиями.
Однажды, очень давно, довелось мне написать это:

function ClipperCRC(const Stream: TStream): Cardinal;
label
  ReadLoop, DataLoop, ProcEnd;
var
  CPU: packed record
    SI, DI, BP: Word;
    DS: array[1..512] of Byte;
  case Byte of
    0: (AL, AH, DL, DH, BL, BH, CL, CH: Byte);
    1: (AX, DX, BX, CX: Word);
    2: (AXDX, BXCX: Cardinal);
  end;
begin
  Stream.Position:= 0;
  with CPU do
    begin
      BP:= 0;
      DI:= 0;
      ReadLoop:
      CX:= SizeOf(DS);
      AX:= Stream.Read(DS, CX);
      if AX = 0 then goto ProcEnd;
      DI:= DI+AX;
      CX:= AX-1;
      SI:= 1;
      AX:= 0;
      DataLoop:
      AX:= AX+PWord(@DS[SI])^; // add AX, [DS:SI]
      Inc(SI);
      if CX > 1 then // loop DataLoop
        begin
          Dec(CX);
          goto DataLoop;
        end
      else
        CX:= 0;
      BP:= BP+AX;
      AL:= DS[SI];
      AH:= DS[SI];
      Inc(SI);
      BP:= BP+AX;
      AX:= BP;
      DX:= DI;
      AXDX:= AX*DX; // mul DX
      BP:= BP+AX;
      if BP = 0 then Inc(BP);
      goto ReadLoop;
      ProcEnd:
      DX:= DI;
      AX:= BP;
    end;
  Result:= CPU.AXDX;
end;

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

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

E__>Здравствуйте, мыщъх, Вы писали:

E__>Что в данном случае означает "вызвали скрипт манагер из джавы"?
я пытался решить эту проблему и тут одно из двух -- или я туплю или проблема не имеет решения в рамках норм приличия.

берем код вида:

ScriptEngine js = new ScriptEngineManager().getEngineByName("js");
FileReader f = new FileReader(args[0]); js.eval(f); f.close();

считаем, что в файле может быть 'while(1);' или какие другие подлянки. наша задача -- выполнить скрипт или спустя 500 ms послать скрипт на юг и вернуть ошибку, освободив все ресурсы.

> Если это внешний процесс, то остановить его очень легко.
это ScriptEngineManager из JRE. его можно остановить без ругательств со стороны компилятора? я пробовал и так, и сяк -- компилятор выдает предупреждение, что и то, и се уже давно как deprecated и потому такое решение не пропускает QA (и правильно делает).

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

и потому я вполне могу вообразить ситуацию, когда вызов super_lib.super_exit(0) вызовет API оси, а ось не знает, что мы должны выполнить какой-то код перед завершением. вся надежда на автора библиотеки super_lib. надежда, как вы понимаете, слабая. пример тому -- ошибки переполнения нативного стека в штатных библиотеках. если авторы java так косячат, чего ожидать от каких-то студентов, пишуших библиотеки в гараже у которых даже QA нет.

> Потому можно не париться техническими трудностями: для исключения стека всегда хватит.
лень вспоминать cve номер ошибки переполнения стека. нативного. кажется в 2008 или в 2009 году нашли. там короче когда вызывается апплет и создается поток и переполняется стек, то выскакивает исключение, которое ловится и подавляется. затем стек переполняется еще раз. на этот раз винда уже убрала сторожевую страницу и выскакивает или исключение доступа или мы врезаемся в стек другого потока. так из одного потока можно воздействовать на стек другого. а к чему это приводит... теоритически можно лихо подменять практически любые данные. практически хакеры не ушли дальше крэша. но это потому что на тот момент в хакерскую индустрию еще не хлынули миллионы криминальных долларов и никому было не интересно реализовать атаку на банк клиент, например.

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

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

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

Q>Откуда взялся этот код и почему он выглядит именно так, должно быть понятно любому здесь.
Q>Расскажите неграмотному дельфисту что-нибудь про формошлепство и непонимание внутреннего устройства компьютера.
извините, но у вас ноги из попы растут. код непортабельный. мрак. по нормальному должен быть тормозной портабельный код на паскале и асм-модули под разные платформы. кстати, код на паскале если писать по уму не такой уж и тормозной даже с учетом отсутствия оптимизации у компилятора.

программы на дельфи я узнаю сразу. в них хронически не работает tab или скачет между полями не в том порядке в котором они на экране. дельфисты не читают гайдлайнов. когда я такое увидел на webmoney, то с этой конторой мне сразу стало все ясно. это октябрята, которых не взяли в пионеры. удивительно, но в среде того же ms vs такое встречается значительно реже и tab'ы работают как надо. не потому что это среда обеспечивает (не обеспечивает она этого), а потому что порог вхождения выше.

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

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


E__>The finally block always executes when the try block exits.
см. выделенное. вы не анализировали малварь на java. там хорошая традиция -- не выполнять finally, перепрыгивая через него. кстати, делается легально средствами самой java без всяких там хаков. декомпиляторы с ума сходят -- control flow хрен построишь.

Здравствуйте, мыщъх, Вы писали:

Q>>Откуда взялся этот код и почему он выглядит именно так, должно быть понятно любому здесь.
Q>>Расскажите неграмотному дельфисту что-нибудь про формошлепство и непонимание внутреннего устройства компьютера.
М>извините, но у вас ноги из попы растут.
Ваше мнение озвучено, но отвергнуто как несостоятельное. До свидания.

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

Q>Здравствуйте, мыщъх, Вы писали:

Q>>>Откуда взялся этот код и почему он выглядит именно так, должно быть понятно любому здесь.
Q>>>Расскажите неграмотному дельфисту что-нибудь про формошлепство и непонимание внутреннего устройства компьютера.
М>>извините, но у вас ноги из попы растут.
Q>Ваше мнение озвучено, но отвергнуто как несостоятельное. До свидания.
обосновать сможете? ну или давайте письками меряться. если мой код на паскале будет работать сильно медленнее вашего асма -- считайте, что у вас длинеее. и, соответственно, наоборот. код тот же что и у вас (по функционалу), компилятор -- аналогично. незнание матчасти, незнание принципов построения осей и компиляторов и прочего фундаментализма не позволяет вам решать задачи на паскале без тормозов.

Здравствуйте, мыщъх, Вы писали:

М>>>извините, но у вас ноги из попы растут.
Q>>Ваше мнение озвучено, но отвергнуто как несостоятельное. До свидания.
М>обосновать сможете?
Весь ваш пост построен на эмоциях, а не на здравом смысле. Вы не поняли ни задачи, породившей данный код, ни его назначения. Вы сделали необоcнованные заявления. И вообще, вы сильно разочаровали, Николай. Похоже вы больше пиарщик, чем айтишник.

Я не собираюсь ни с кем меряться пиписьками и соревноваться в скорости программ, результаты моего давнего кодинга есть мой сегодняшний доход, и он меня полностью устраивает.

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

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


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

M>Тогда немного опишу, что же именно некорректного было в данных. У меня функция заносит в БД извлеченное и обработанное содержимое некоторых файлов внутри *.zip -файлов, при этом естественно проверяет на корректность и само содержимое обрабатываемых файлов и формат и тд. При этом в редких случаях внутри *.zip-файла может быть еще вложенные *.zip-файлы и их тоже надо распаковать и в свою очередь проверить, что внутри. Вложенный файл я обрабатывал просто рекурсивным вызовом.

Ой, уже звучит страшно. Не слишком ли много для одной функции? Хотя, если она внутри выглядит примерно так

binaryStream Unpacked = ZipTools::Unpack(PackedData);
m_dbProvider->UpdateMyCoolDataSet(ExtractData(Unpacked));

то все еще пучком.

M>Тесты (просто набор разных исходных данных) есть, все ситуации с ошибками тестировали и они обрабатывались, программа не падала.

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


M> Но забыли протестировать случай, когда такая ошибка возникает при работе с содержимым внутри вложенного файла. То есть, неправильная работа с exit не приводила почему-то к падениям, пока работа шла на первом уровне вложенности. Я и говорю, что диспетчер памяти оказался склонным прощать некоторые ошибки в работе с ней. Падать стало внутри рекурсии.

привычка писать юнит-тесты доводит до того, что программист органически становится неспособным "забыть" протестировать такие. То есть написать тест, покрывающий подобную ситуацию воспринимается как нечто само собой разумеющееся и никаких вопросов не вызывает.
Кроме того, написать юнит-тест, проверяющий корректность работы и непадучесть этой функции, примерно в 10 тысяч раз легче, нежели тестировать ее корректное поведение на этапе QA. И выгоднее.

M>Программу я уже не трогал с год, просто все это время не случалось такого редкого сочетания с ошибкой.

А сколько еще подобных мест в вашем коде?

Здравствуйте, мыщъх, Вы писали:


М>единица вам. "are you writing..." вы пишите тест _одновременно_ с чтением форума. вы юлий цезарь?
М>Present Perfect Tense переводится как "вы _когда_ _либо_ писали тесты?". по аналогии I've been in London. это отличается от I was in London. в первом случае это "у меня есть жизненный опыт и я знаю что такое Лондон не только по картинкам", во втором случае вы просто там были. например, вас спрашивают -- какого хрена вас вчера не было на рабочем месте. а вы отвечаете: I was in London.

здесь. Дальше распространяться на эту тему не буду, но даже по-русски будет корректнее спросить "а пишете ли вы вообще тесты", потому что любое прошедшее время подразумевает, что тесты писали, и, возможно, прекратили.

L>> При всем уважении, ты пытаешься лезть в область, в которой нихрена не понимаешь.
L>> Это я про тестирование. Я даже не знаю, с чего начать, чтобы объяснить глубину
М>с критическими инфраструктурами я не сталкивался и как там тестируют по — хз, но энерпрайз и военка -- это для меня ежедневная рутина. показывать им юнит тесты все равно что показывать палец. юмора не поймут и слив защитан.

Еще раз — ты пытаешься рассуждать на тему, в которой нихрена не понимаешь. Юнит-тест — это инструмент разработки. Его клиентам не показывают. Игнорирование этого мощного инструмента разработки привело к тому, что ТС пришлось убить кучу времени на пошаговую отладку. Я бы вообще отбирал у программистов отладчик на время разработки.

М>повторяю еще раз -- тест должен _доказать_ полноту и непротиворечивость. преобразование программы в диаграмму типа flow chart с последующей верификацией позволяет _доказать_, что она корректна (тут кажется кто-то упоминал светофор в качестве примера, кажется в контексте дракона. существуют системы верификации по, доказывающие, что два зеленых света гореть не могут. а доказать это можно если перевести ваш юнит в fsm, но это не юнит тест, это _совсем_ другое).

Это ты сейчас с кем разговариал? И, пожалуйста, не упоминай конечные автоматы в суе и особенно в разговорах со мной. Порву на лоскуты размером в атом, а из того, что осталось, вызову цепную ядерную реакцию.

>> У нас требуются сертифицированные перчатки другой системы
>> и несоблюдение техники безопасности бывает фатальным.
М>ваша пися больше моей? хорошо, давайте возьмем линейку, какими ISO вы руководствуетесь? понимаете, юнит-тест это сугубо ваше личное (можно даже сказать интимное) дело. никому кроме вас он на хрен не нужен и не интересен. когда будете сдавать продукт серьезному заказчику (банку, скажем) от вас потребуют совсем других тестов. какая там техника безопасности, о чем вы? есть формальные требования, вы им следуете. строите формальные модели.

К счастью, никакое ISO не регламентирует, как именно должны тестироваться элементы ПО. И опять же, не путай UAT и FAT c тестированием во время разработки. Ты можешь построить хоть стопицот формальных моделей, потратить полгода на FAT и успешно пройти его, и все равно можешь жидко обосраться на второй день после запуска в эксплуатацию. Доказательство элементарно — твой софт состоит сплошь из функций, которые принимают какие-то входные значения, что-то с ними делают и выдают результат. Утрировано, конечно, но это так. Каждая их таких функций имеет следующие подмножества входных параметров — корректные, некорректные и граничные. Тебе, помимо функционального тестирования (проверить, что функция делает именно то, что должна), нужно проверить корректность поведения этой функции на этих наборах параметров. То есть на каждую функцию нужно еще три теста (три набора тестов, если быть точным, но в данном контексте это неважно). Соответственно, если у тебя 1000 функций, то тебе понадобится 3000 тестов, по грубой оценке.
Но! Если ты забъешь на юнит-тестирование, и будешь пытаться тестировать всю систему целиком как чОрный йащег (с), то тебе для достижения того же уровня покрытия, критериев этих и собственно, тест кейсов, понадобится минимум 3^1000. Удачи, как говорится, и заодно слив защитан.

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

Дорогой, ты только что привел примеры двух индустрий, где юнит-тестирование проводится практически везде. Изготовление электронных компонентов, например. Каждый из них тестируется на сходе с конвеера. Каждая плата проходит электрический тест. Каждая собранная плата проходит как минимум базовый функциональный тест до установки ее в систему. Тестирование осуществляется на каждом этапе, где это только возможно автоматизировать. Там, где автоматизировать поленились или ошиблись с определением критериев, отрастают проблемы. То, что все равно есть ошибки — это всего лишь результат сложности системы. Если бы производители резисторов не тестировали их, то никакой ракетной техники бы не было вообще.

L>> Списывание отсутствия тестов на недостаточность ресурсов — это безоговорочное
L>> признание в собственной некомпетентности и прямая путевка за кассу в Макдональдс.
М>пытаюсь объяснить еще раз -- сложность _полного_ теста намного превышает сложность того, что мы тестируем. откроейте глаза и посмотрите на то, что вас окружает. начиная с программного обеспечения и заканчивая медикаментами. далеко не все это тестируется, а если и тестируется, то неполно и поверхностно. ракетно-космическая техника тестируется лучше, чем гражданская авиация, а гражданская авиация тестируется лучше, чем бытовой софт. а если бытовой софт тестировать по полной программе, то это все равно не гарантирует отсутствие ошибок, но цена ms office перевалит за миллиард баксов за одну лицензию. что вы курили?

Уважаемый, ты заговариваешься. Военная ракетная техника изначально тестировалась исключительно на полигоне. Но все очень быстро поняли, что, во-первых, восстанавливать полигон после каждого неудачного запуска не хватит ни одного военного бюджета, а, во-вторых, выяснять, что именно пошло не так, имея в наличии лишь оплавленный и спекшийся песок полигона, не очень продуктивно. Именно поэтому ракетные двигатели тестируются на стендах. И вся их обвязка тоже. Это и есть юнит-тестирование. Это, конечно, не узбавляет от катастроф на 100%, но уменьшает их вероятность на много порядков.

>> Сколько у него там на отладку ушло времени? Вот то-то и оно.
М>был бы отладочная печать -- было бы видно, где оно падает. но отладочной печати у него нету. а что мне делать если я аппаратно-программный комплекс разрабатываю? концепция интерактивной отладки к нему вообще не применима.

Я тебе посоветую не разрабатывать программно-аппаратный комплекс, так как из твоих слов понятно, что ты в этой теме ни бум-бум.

L>> Далее, факториал, точнее, то, что принято называть факториалом, на C++ вычисляется в compile time.
М>см. определение из вики. см. функцию факториала из гну либы на gcc.

L>> Его можно тестировать, но смысла особого нет.
М>поздравляю. вы произнесли заветные слова. "тестировать можно, но на хрена?". то есть по факту вы со мной согласны, но при этом делаете вид, что один из нас дурак, хотя мы оба говорим, что юнит-тест написать можно, но смысла в этом нет.

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

L>> Но и твою притянутую за уши реализацию гамма-функции я тоже протестирую,
М>она не моя. она из 18 века вообще-то. а сейчас 21 век. столько не живут ИМХО.

L>> но при одном условии — если ты асилишь обозначить четкие критерии ее использования в программе,
М>лопата! вот у вас есть библиотечная гамма-функция. а она у вас есть (если под никсы пишите). и у вас возникает вопрос -- как быстро она работает? насколько сильно ошибается? вы хотите знать подходит ли она вам или нет. у вас есть требования по точности и времени. известны и целевые платформы. дело за малым -- убедиться, что все воркается. и вот тут выясняется, что тестирование функции которая заведово работает выливается в сложную инженерную задачу...

Тебе про Фому, а ты про Ерему.

L>> Если этого нет, то разочарую тебя — прикладной аналитикой занимаются на другом этаже.
М>вот он -- момент просветления. на уровне юнит-теста вы не можете сказать какие у вас требования к данной функции. допустим, время отклика системы должно быть не хуже 15 ms на таком-то железе. это во всей совокупности.

Сейчас ты лезешь в розетку с амперметром.

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


L>>При всем уважении, ты пытаешься лезть в область, в которой нихрена не понимаешь. Это я про тестирование. Я даже не знаю, с чего начать, чтобы объяснить глубину твоего заблуждения, и считаю, что будет просто честным предложить оставаться тебе в своем хакерском R&D мире и не лезть в инженерные задачи в своих латексных перчатках. У нас требуются сертифицированные перчатки другой системы, и несоблюдение техники безопасности бывает фатальным.

F> Мне, на самом деле, давно интересно собрать статистику, сколько раз regression unit tests вылавливало ошибки, сколько раз после успешного тестирования ошибки все равно обнаруживались и сколько раз test failures ловили ошибки кода, а не теста.

Такой статистики не существует. Потому что, с одной стороны, есть группы, умеющие правильно использовать юнит-тестирование, и с другой стороны, если ниасилившие. А базиса и методологии для сравнения результатов их работы не существует по очевидным причинам.

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

F> Потому что в теории это классная вещь — написали тесты и теперь никто не изменит так, что оно перестанет работать. В практике я ни разу еще не видел, чтобы это работало. Создание хороших тестов работа более трудозатратная, сложная и высококвалифицированная нежели создание самого кода для бизнес логики. Но даже с хорошими тестами все равно ошибки возможны. И затраты на поддержание онных достаточно велики.

Нет никаких затрат на поддержание тестов. Если они есть, вы что-то делаете неправильно. Это мое профессиональное мнение, основанное на десятках коммерческих проектов.

F> Там где высокая надежность важна, применяются совем другие методы тестирования. Обычно этим занимается отдельная группа людей.

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

F> Но даже в более менее обычных бизнес-приложениях грамотный QA по фактору количество пойманных багов и количеству затраченных ресурсов работает значительно эффективней юнит тестов.

Никогда не путай QA и юнит-тестирование. Их задачи разные. Использовать QA для отлова того, что должно было быть протестировано юнит-тестом равносильно стрельбе из пушки по комарам.

F>Это наблюдения из практики как она есть — никаких теорий.

Моя наблюдения из практики почему-то своершенно другие.
Вот моги главные замеченные отличие проектов, написанных в стиле "тесты писать некогда, нужно копать" от тех, где тесты, и много, были написаны:

1. проекты, где юнит-тестирование применялось првильно и в полный рост, чаще всего оказываются code complete и feature complete еще до дедлайна, в то время, как проекты без юнит-тестирования без исключений залезают крепко за дедлайн
2. Ошибки, найденные во время QA на проектах, покрытых юнит-тестами, разительно отличаются от ошибок, найденных на классических проектах. Обычно они лежат в плоскости "а мы считаем, что здесь спеки требуют другого поведения" и "поведение соответствует спекам, но заказчик понял, что ошибся в спеках и поэтому поведение нужно изменить", в то время как багрепорты от QA на классических проектах пестрят "упало", "не работает вообще", "сожрало всю память и опять упало" и прочими WTF.
3. Проекты, покрытые юнит-тестами, намного более гибкие в смысле дальшейшего развития и обеспечивают возможность легкого рефакторинга.
4. Из юнит-тестов можно вычленять автоматические функциональные тесты, облегчая работу QA

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

L>Здравствуйте, мыщъх, Вы писали:

L>здесь. Дальше распространяться на эту тему не буду,
и что там по ссылке? и где я там не прав?

L> но даже по-русски будет корректнее спросить "а пишете ли вы вообще тесты",
"вы тесты писали" --> "занимались ли вы когда либо написанием тестов". что не так?

L> потому что любое прошедшее время подразумевает, что тесты писали, и, возможно, прекратили.
возможно и прекратили. возможно и нет. но если писали, то опыт остался даже если прекратили.

L> Еще раз — ты пытаешься рассуждать на тему, в которой нихрена не понимаешь.
это не аргумент. тоже самое я могу сказать о вас.

L> Юнит-тест — это инструмент разработки. Его клиентам не показывают.
привести примеры когда показывают? из того, что доступно в иннете? так кто из нас двоих ни хрена не понимает?

L> Игнорирование этого мощного инструмента разработки привело к тому,
L> что ТС пришлось убить кучу времени на пошаговую отладку. Я бы вообще
L> отбирал у программистов отладчик на время разработки.
согласен на счет отладчика. не согласен на счет теста. отладочная печть и логи -- чем не вариант?

L> И, пожалуйста, не упоминай конечные автоматы в суе и особенно в разговорах со мной.
L> Порву на лоскуты размером в атом, а из того, что осталось, вызову цепную ядерную реакцию.
стадию перехода на личности мы уже миновали и вот уже добрались до прямых угроз. давайте, рвите. мне и правда интересно

L> К счастью, никакое ISO не регламентирует, как именно должны тестироваться элементы ПО.
у него еще и номер круглый. если вы хоть однажды в него заглядывали, то должны помнить.

L> Доказательство элементарно — твой софт состоит сплошь из функций,
кто-то обещал порвать меня на автоматы. интересно, сколько у нас функций в DFA-дереве?

L> которые принимают какие-то входные значения, что-то с ними делают и выдают результат.
L> Утрировано, конечно, но это так. Каждая их таких функций имеет следующие подмножества
L> входных параметров — корректные, некорректные и граничные.
_каждая_ ?! вы в этом уверены?! функций без аргументов уже не бывает? my_pi() — какие тут аргументы? даже утрированно? какие некорректные аргументы у функции abs?!

L> То есть на каждую функцию нужно еще три теста (три набора тестов, если быть точным,
L> но в данном контексте это неважно). Соответственно, если у тебя 1000 функций,
L> то тебе понадобится 3000 тестов, по грубой оценке.
вы снова соглашаетесь со мной, что исчерпывающий тест намного больше по объему кода и по трудоемкости написания, чем то, что он тестирут. модели для других целей строят. например, если это пульт управления микроволновой печи -- модель _доказывает_, что нельзя войти в меню из которого потом не выйти. именно, что _доказывает_, причем верификация осуществляется автоматически.

L>Дорогой, ты только что привел примеры двух индустрий,
L>где юнит-тестирование проводится практически везде.
и обе индустрии вбухивают в тестирование мегабабло. потому что цена ошибки дороже.

М>>был бы отладочная печать -- было бы видно, где оно падает. но отладочной печати у него нету. а что мне делать если я аппаратно-программный комплекс разрабатываю? концепция интерактивной отладки к нему вообще не применима.

L>Я тебе посоветую не разрабатывать программно-аппаратный комплекс,
L>так как из твоих слов понятно, что ты в этой теме ни бум-бум.
кто-то грозился отобрать отладчик...

L> Сейчас ты лезешь в розетку с амперметром.
сколько слов, наездов, самоуверенности и при этом никаких возражений по существу. вы говорите, что юнит тесты нужны. ок, допустим это так. осталось только оценить расходы на их разработку и заложить их в бюджет.

вы так и не ответили на вопрос -- как убедиться в том, что в тесте нет ошибок?

Здравствуйте, мыщъх, Вы писали:

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

L>>Здравствуйте, мыщъх, Вы писали:

L>>здесь. Дальше распространяться на эту тему не буду,
М>и что там по ссылке? и где я там не прав?

Пункт 2.

L>> но даже по-русски будет корректнее спросить "а пишете ли вы вообще тесты",
М>"вы тесты писали" --> "занимались ли вы когда либо написанием тестов". что не так?

Не так. Изначально не тот посыл. Некрасивый и заставляет оправдывться. Вроде "вы уже перестали бить свою жену по выходным".

L>> потому что любое прошедшее время подразумевает, что тесты писали, и, возможно, прекратили.
М>возможно и прекратили. возможно и нет. но если писали, то опыт остался даже если прекратили.

У 80% тех, у кого опыт остался, но прекратили, опыт этот сугубо отрицательный. Потому что писали из-под палки и только потому, что заставлял менеджер.

L>> Еще раз — ты пытаешься рассуждать на тему, в которой нихрена не понимаешь.
М>это не аргумент. тоже самое я могу сказать о вас.

Все приведенные тобой примеры не имеют никакого отношения к прадигме и предназначению юнит-тестирования.

L>> Юнит-тест — это инструмент разработки. Его клиентам не показывают.
М>привести примеры когда показывают? из того, что доступно в иннете? так кто из нас двоих ни хрена не понимает?

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

L>> Игнорирование этого мощного инструмента разработки привело к тому,
L>> что ТС пришлось убить кучу времени на пошаговую отладку. Я бы вообще
L>> отбирал у программистов отладчик на время разработки.
М>согласен на счет отладчика. не согласен на счет теста. отладочная печть и логи -- чем не вариант?

Сравниваешь теплое с мягким. Тесты выполяются автоматически во время каждого билда, и отладочная печать и логи по сравнению с ними находятся в одином ряду с каменным топором по сравнению с современным станком с ЧПУ.

L>> И, пожалуйста, не упоминай конечные автоматы в суе и особенно в разговорах со мной.
L>> Порву на лоскуты размером в атом, а из того, что осталось, вызову цепную ядерную реакцию.
М>стадию перехода на личности мы уже миновали и вот уже добрались до прямых угроз. давайте, рвите. мне и правда интересно

А вот не надо было соскользывать с темы и приплетать FSM куда не надо.

L>> К счастью, никакое ISO не регламентирует, как именно должны тестироваться элементы ПО.
М>у него еще и номер круглый. если вы хоть однажды в него заглядывали, то должны помнить.

Этот ISO — он для менеджеров. Которые программировать не умеют.

L>> Доказательство элементарно — твой софт состоит сплошь из функций,
М>кто-то обещал порвать меня на автоматы. интересно, сколько у нас функций в DFA-дереве?

Я нигде не говорил, что я телепат.

L>> которые принимают какие-то входные значения, что-то с ними делают и выдают результат.
L>> Утрировано, конечно, но это так. Каждая их таких функций имеет следующие подмножества
L>> входных параметров — корректные, некорректные и граничные.
М>_каждая_ ?! вы в этом уверены?! функций без аргументов уже не бывает? my_pi() — какие тут аргументы? даже утрированно? какие некорректные аргументы у функции abs?!

Хорошо, какой-то процент функций явных аргументов иметь не будет. Зато половина из них будет иметь контекст (глобальный или своего объекта), и зависимости от него тоже нужно тестировать.

А про abs(float) можешь начинать считать лоскуты. Граничные и специальные условия:

1) Проверка поведения при -0
2) проверка поведения при обоих NaN
3) Проверка, что никакой чертовщины с потерей точности не происходит

Это то, что пришло мне в голову за одну секунду.



L>> То есть на каждую функцию нужно еще три теста (три набора тестов, если быть точным,
L>> но в данном контексте это неважно). Соответственно, если у тебя 1000 функций,
L>> то тебе понадобится 3000 тестов, по грубой оценке.
М>вы снова соглашаетесь со мной, что исчерпывающий тест намного больше по объему кода и по трудоемкости написания, чем то, что он тестирут. модели для других целей строят.

Цитату можно, где я соглашался?
Эти 3000 тестов будут состоять из трех-четырех строчек каждый; трудоемкость их написания на фоне затрат на разработку основного кода незаметна, а объем — вообще странная метрика. Более того, факт написания тестов оказывает положительный эффект на разработку собственно кода, поскольку тестируемый код должен удовлетворять критериям тестируемости, которые магическим образом совпадают с обобщенными критериями "хорошести" и "поддерживаемости" кода. Выполнение этих тестов занимает несколько секунд.
Трудоемкость такого подхода совершенно ничтожна по сравнению с затратами, которые потребовались бы на орагнизацию аналогичного по покрытию набора функциональных black-box тестов.

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

А вот тут я, как и обещал, порву тебя на лоскуты. Пульт управления микроволновки — это типичный пример state machine. То, что в ней нет тупиков, доказывается в первую очередь диаграммой состояний вашей машины и таблицей переходов. Верифицируется ручками, глазками, и девайсом /dev/brain. Как и все подобные конечные автоматы. А вот после реализации можно и нужно написать функциональный тест, который в том числе проверит, что из каждого меню можно выйти в $HOME.


L>>Дорогой, ты только что привел примеры двух индустрий,
L>>где юнит-тестирование проводится практически везде.
М>и обе индустрии вбухивают в тестирование мегабабло. потому что цена ошибки дороже.

Знаем мы, куда они мегабабло вбухивают. На бонусы непричастным и сетрификацию некомпетентными.

М>>>был бы отладочная печать -- было бы видно, где оно падает. но отладочной печати у него нету. а что мне делать если я аппаратно-программный комплекс разрабатываю? концепция интерактивной отладки к нему вообще не применима.

L>>Я тебе посоветую не разрабатывать программно-аппаратный комплекс,
L>>так как из твоих слов понятно, что ты в этой теме ни бум-бум.
М>кто-то грозился отобрать отладчик...

... компилятор тоже надо отобрать. А то ногу себе прострелишь.

Ты имей в виду, я на тебя не наезжаю. Более того, по этому форуму я тебя весьма уважаю, как минимум потому, что для меня то, чем ты занимаешься — это такой темный лес, что я туда даже заглядывать боюсь. Но в данном случае ты залез в ту область, где я уже сожрал почти всех собак. А ты время от времени несешь такую чушь, что я даже не могу найти слов, чтобы ответить.

L>> Сейчас ты лезешь в розетку с амперметром.
М>сколько слов, наездов, самоуверенности и при этом никаких возражений по существу. вы говорите, что юнит тесты нужны. ок, допустим это так. осталось только оценить расходы на их разработку и заложить их в бюджет.

Нет никаких особых расходов на разработку этих тестов. Вообще, когда спрашивают о расходах на разработку тестов, это является признаком полного непонимания подхода TDD и использования юнит-тестов в разработке. Этот процесс не разделим на составные части.

Как только разработчик становится адептом церкви TDD на своем опыте узнает преимущество юнит-тестирования, для него юнит-тесты перестают существовать как отдельная сущность. Для нас процесс разработки есть процесс написания собственно кода и кода, его тестирующего. Они неотделимы друг от друга, как неотделимы и наши собственные оценки затрат и как результат, бюджет. Кроме того, наши оценки временных затрат зачастую являются гораздо более точными, так как, прежде чем приступить к estimations, мы должны не только ответить на вопрос "а что мы будем писать", но и "а как мы это будем автоматически тестировать".

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

М>вы так и не ответили на вопрос -- как убедиться в том, что в тесте нет ошибок?

Ошибки в тестах, как правило, ортогональны ошибкам в коде, который они призваны проверять. Опять же, если ошибка в тесте приводит к тому, что тест не проходит, просто вернись и пофикси ее. От ошибок, приводящих к false positive, помогает практика писать negative test cases.

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

L>здесь. Дальше распространяться на эту тему не буду, но даже по-русски будет корректнее спросить "а пишете ли вы вообще тесты", потому что любое прошедшее время подразумевает, что тесты писали,
давно Present Perfect стало прошедшим? Present как переводится?

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

b-3>Здравствуйте, landerhigh, Вы писали:

L>>здесь. Дальше распространяться на эту тему не буду, но даже по-русски будет корректнее спросить "а пишете ли вы вообще тесты", потому что любое прошедшее время подразумевает, что тесты писали,
b-3>давно Present Perfect стало прошедшим? Present как переводится?
Рассказать, как переводится Perfect?

Это время используется для обозначения действия, завершенного к настоящему моменту без указания конкретного периода в прошлом. То есть "have you done any unit testing at all?" == "писали ли вы тесты когда-либо?". Посыл ложный, о чем я и говорю.

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

Q>Однажды, очень давно, довелось мне написать это:
Q>Откуда взялся этот код и почему он выглядит именно так, должно быть понятно любому здесь. Расскажите неграмотному дельфисту что-нибудь про формошлепство и непонимание внутреннего устройства компьютера.

кстати да, абсолютно чудовищный код.

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

SUA>А нечего было так глубоко залазить

Попал мне как-то древний исходник на xBase (не помню, Fox или Clipper). Автор того кода передачу управления вверх организовывал как раз, запихивая определенные участки кода в WHILE и выставляя в условии хитрые комбинации флажков. И столько этих циклов нагородил, что я тогда впервые пожалел, что goto в xBase предназначен для прыжков по записям в таблице, а не по коду программы. Я раньше прочитал пару строк на Фортране 4, так что макаронами меня запутать было сложнее, чем их эмуляцией.

Здравствуйте, мыщъх, Вы писали:

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

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

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

Перефразируя известную фразу: юнит-тесты только потому писать надо, что они код в порядок приводят. Во-первых для того чтобы покрыть юнит тестами какую-то систему, нужно ее сначало хорошенько структурировать, а это уже плюс. Во-вторых, имхо, юнит тесты не нацелены на отлов всех ошибок. Первоначально они используются для того чтобы убедиться хоть в какой-то работоспособности данного модуля, потом, в случае выявления ошибок, тесты используются для закрепления баг фикса, и дают гарантию, что при последующем изменении кода, данная проблема не вернется незамеченной. Конечно в реальности бывают различные случаи: нет времени, денег, мотивации, нужно чтобы уже вчера работало, тогда конечно можно и без юнит тестов, но это уже не относится к тому как правильно писать код.

М>если вы не согласны и уверены в себе и своих знаниях -- плз, напишите функцию факториала вместе с тестом.

Факториал писать не приходилось, но приходилось писать много других алгоритмов из вычислительной математики и computer science. Без юнит тестов там вообще невозможно написать, хоть какой-то более менее сложный алгоритм.

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

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


SUA>>>Здравствуйте, linuz, Вы писали:
L>>>> Я видел как goto-ненавистники лепили мега-монстра с кучей хитровложенных ифов, do-while и свитчей только для того чтобы правильно выйти из нескольких циклов. Там без бутылки не поймешь когда и куда оно выходит, лучше бы написали goto.

SUA>>>А нечего было так глубоко залазить

M>>То есть, чтобы не использовать goto теперь надо еще и от вложенных циклов отказаться?

E__>Ну, вообще-то, желательно. Вложенные циклы без вынесения внутреннего в отдельную функцию, весьма трудночитаемы.

Мда, то есть там, где можно было бы написать понятный и обозримый код из десятка строчек с допустим тремя вложенными циклами и элементарными выходами с помощью goto, надо в итоге нагородить или кучи if-ов и флагов для проверки или выносить циклы в отдельные функции, чтобы можно было выходить по exit. А если выходить надо и со второго уровня и с третьего? Отдельные функции и на все это? Хотя exit тоже некошерен

Такая боязнь goto уже на какое-то сектантство в программировании начинает походить.

Здравствуйте, мыщъх, Вы писали:

М>чтобы что-то тестировать нужно иметь формальную модель этого самого того, что мы тестируем. а ее обычно нет. даже на примере парсера XML. ну есть спецификации разных версий, а есть ПО, генерирующее XML. часто бывает так, что ПО, генерирующее XML, являющийся нашими входными данными, противоречит спецификациям, но это ПО нам неподконтрольно. а заказчику класть на спецификации. ему нужно, чтобы две программы работали вместе, понимая друг друга.

О, кстати, да. Буквально месяц назад пришлось разбираться с подобной хренью. Есть крутая система, которая выдает по запросам к ней данные в XML-формате. Не знаю, что там курили программисты, которые писали выдачу, но в некоторых случаях XML не то, что валидацию на соответствие DTD не проходят, а они и вовсе некорректные как XML из-за того, что во-первых, там банально знаки < > и & (спецсимволы) в данных представлены как есть. На чем падает извлечение данных стандартными средствами. В итоге пришлось извращаться и делать предобработку, заменяя в нужных местах эти знаки. Причем я заведомо не смог это сделать совершенно безглючным, потому что я не написал полностью свой парсер даже не XML, а того псевдоXML, что приходится обрабатывать. Просто на примерно том наборе данных, что выдается, замена происходит корректно. Тьфу-тьфу Во вторых, иногда этот XML и вовсе имеет пересекающиеся теги. Хорошо еще, что все такие случаи пока что строго определенные — иногда корневой элемент почему-то закрывается раньше предыдущего вложенного. Других вариантов еще не встретилось.

При этом такие глюки примерно в одном XML-файле из 5000 и пока тестировали и принимали в эксплуатацию на некотором множестве опытных все работало без сбоев. Все замечательно.

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

M>>Тогда немного опишу, что же именно некорректного было в данных. У меня функция заносит в БД извлеченное и обработанное содержимое некоторых файлов внутри *.zip -файлов, при этом естественно проверяет на корректность и само содержимое обрабатываемых файлов и формат и тд. При этом в редких случаях внутри *.zip-файла может быть еще вложенные *.zip-файлы и их тоже надо распаковать и в свою очередь проверить, что внутри. Вложенный файл я обрабатывал просто рекурсивным вызовом.

L>Ой, уже звучит страшно. Не слишком ли много для одной функции? Хотя, если она внутри выглядит примерно так

Это не одна функция — это одна программка, которая написано мной полностью и никем, кроме меня же не протестирована


L>

L>binaryStream Unpacked = ZipTools::Unpack(PackedData);
L>m_dbProvider->UpdateMyCoolDataSet(ExtractData(Unpacked));
L>

L>то все еще пучком.

M>>Тесты (просто набор разных исходных данных) есть, все ситуации с ошибками тестировали и они обрабатывались, программа не падала.

L>Не все. Не удивлюсь, если знаменитая mail-бомба в зипе также способна свалить вашу программу. Да тут еще и рекурсия, подуснет какой дятел поврежденный или специально подготовленный зип с тучей уровней вложенности и привет переполнение стека.

Не проверял на mail-бомбы, собственно если внешняя либа ей подвержена то будет плохо, если нет — просто ошибка вернется. Но это все-таки, утилита для внутренней автоматизации, которую я быстро написал и с год не прикасался к ней, а не серьезный программный продукт.

M>> Но забыли протестировать случай, когда такая ошибка возникает при работе с содержимым внутри вложенного файла. То есть, неправильная работа с exit не приводила почему-то к падениям, пока работа шла на первом уровне вложенности. Я и говорю, что диспетчер памяти оказался склонным прощать некоторые ошибки в работе с ней. Падать стало внутри рекурсии.

L>привычка писать юнит-тесты доводит до того, что программист органически становится неспособным "забыть" протестировать такие. То есть написать тест, покрывающий подобную ситуацию воспринимается как нечто само собой разумеющееся и никаких вопросов не вызывает.
L>Кроме того, написать юнит-тест, проверяющий корректность работы и непадучесть этой функции, примерно в 10 тысяч раз легче, нежели тестировать ее корректное поведение на этапе QA. И выгоднее.

Кхм, но вот я ее проверил на обработку ошибок в данных, на обработку вложенных zip-ов, а вот на комплекс, когда и ошибка в данных и данные внутри вложенного zip-а — не догадался, не подумал. По отдельности-то все работало. Более того, ошибки в данных и вообще очень редко встречаются, а такое их сочетание и вовсе вылезло только через год.

M>>Программу я уже не трогал с год, просто все это время не случалось такого редкого сочетания с ошибкой.

L>А сколько еще подобных мест в вашем коде?

Да наверное хватает Просто цели по качеству сверх минимально необходимого не ставилось. Собственно, если бы не мое же заблуждение насчет exit() ошибки бы в итоге и не возникло.

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

Q>>Однажды, очень давно, довелось мне написать это:
Q>>Откуда взялся этот код и почему он выглядит именно так, должно быть понятно любому здесь. Расскажите неграмотному дельфисту что-нибудь про формошлепство и непонимание внутреннего устройства компьютера.
D>кстати да, абсолютно чудовищный код.
Еще один. Ладно, объясняю для тех, кто глухо в танке.
1. Этот код выдернут мной из клипперовского exe-шника.
2. Этот код является дословным переложением ассемблерного листинга на Delphi.
3. Сделано именно так для того, чтобы банковские крысы не придрались к реализации.
4. Где тут формошлепство, не подскажете?

И да, этот код, хоть и должен работать только в винде, но тем не менее он совершенно портабелен.

D>программисты на дельфи — это всегда очень печальное зрелище. хуже только программисты на 1С
D>сорри, ниче личного, но это реально факт.

Статья 29 Конституции Российской Федерации гласит, что

Не допускаются пропаганда или агитация, возбуждающие социальную, расовую, национальную или религиозную ненависть или вражду. Запрещается пропаганда социального, расового, национального, религиозного или языкового превосходства.

Здравствуйте, мыщъх, Вы писали:


М>так ведь отвалится. и сейчас я объясню почему.

L>>unsigned long factorial(int n)
L>>{
L>> static const unsigned long fact_tab[13] = {
L>> 1, 1, 2, 6, 24, 120, 720, 5040, 40320, 362880, 3628800, 39916800, 479001600
L>> };
L>>Вариант безглючный и самотестирующийся.

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

А ты еретик. Когда будете считать приближенный факториал, не забудь предупредить, чтобы мы спрятаться успели. А то забрызгает еще ненароком.

М>но даже если исходить из допущения, что оптимизация не влечет потерю точности, то у вас таблица все равно не правильная. ну ладно, заполняли от балды. бывает. меня вот что интересует -- с каких это пор размер int'а стал строго определенным? или вы никогда не писали программу под 2+ платформы сразу? если int у нас 64 бита (а такое возможно), то тут нужно сначала посмотреть какой у нас int на данной конкретной платформе, а уже потом выбирать под него таблицу. а если int 16 бит (такое тоже бывает), то ваш тест снова выстрелит мимо.

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

М>писать тест, который работает только в паре с определенным компилятором и под определенную платформу с определенными опциями компиляции -- на фига? вот перекомпилировали код и ваш тест показал ошибку. а ошибка не в коде, а в тесте. крысота.

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


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

Еще раз — так говорят только некомпетентные товарищи. Хватит позориться.

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

L>Здравствуйте, b-3, Вы писали:

b-3>>Здравствуйте, landerhigh, Вы писали:

L>>>здесь. Дальше распространяться на эту тему не буду, но даже по-русски будет корректнее спросить "а пишете ли вы вообще тесты", потому что любое прошедшее время подразумевает, что тесты писали,
b-3>>давно Present Perfect стало прошедшим? Present как переводится?
L>Рассказать, как переводится Perfect?

L>Это время используется для обозначения действия, завершенного к настоящему моменту без указания конкретного периода в прошлом. То есть "have you done any unit testing at all?" == "писали ли вы тесты когда-либо?". Посыл ложный, о чем я и говорю.

И всё же вы неправы — ваше present continious тоже не вполне корректно. Вот страница из очень авторитетной оксфордской грамматики, CGEL.

	Cкан страницы

Цитирую:

Habitual progressive.
The professor types his own letters [The habit is permanent]
The professor is typing his own letters while his secretary is ill [The habit is temporary]

Поэтому "I'm writing unit tests" — это означает либо "я пишу в нынешнем проекте, а обычно не пишу" (a temporary habit), или "я прямо сейчас пишу тесты" (the current action).

Обратите также внимание на примечание внизу страницы(!) Там сказано, что наречие вроде always или all the time меняет смысл, поэтому "Are you always writing UT?" — будет понято правильно, а без always — не будет. Как и "Have you always been writing UT" имеет другой смысл, нежели "Have you been writing UT?". По сути, этот нюанс и разрешает ваш спор в пользу Касперского.

"Are you writing unit tests?" может в контексте иметь смысл habitual — например вопрос к подчинённому — "а юнит-тесты на свой код (который ты ещё не не закоммитил), ты пишешь-то?", но это довольно фамильярно. Вне контекста are you writing unit tests будет воспринято как event, т.е. вопрос о состоянии (ты сейчас что делаешь, пишешь юнит-тесты?) или о state, т.е. об должностных обязанностях (какова твоя роль в проекте, тесты пишешь?) — короче говоря, не поймут.

И надо помнить, что мыщъх вообще-то живёт в США и с native-ами общается изрядно, так что предлагаю постановку "единиц по инглишу" друг другу прекратить.

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

D>программисты на дельфи — это всегда очень печальное зрелище. хуже только программисты на 1С

Боюсь, что хуже только программисты на AutoHotkey.

	Скрытый текст
	Сам я не программист, но скрипты иногда здорово выручают. Недавно случайно обнаружил в AutoHotkey_L забавный глюк, о существовании которого даже не подозревал. Мне надо было копировать короткие текстовые строки, состоящие из 1-2 слов, одновременно преобразуя их так, чтобы первая буква в строке становилась заглавной, а все остальные — строчными. Думал использовать банальное решение: вырезаем первый символ и делаем его заглавным, а к нему присоединяем остальные символы, сделанные строчными. Не тут-то было! Как выяснилось, при конкатенации двух строк между ними почему-то вставляется лишний пробел. Пришлось добавить в конец скрипта операцию замены, чтобы убирать этот пробел.

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

L>Тем, для кого юнит-тесты эквивалентны занятию ерундой, срочно рекомендуется сменить профессию. На сантехника или там развозчика пиццы.
L>Других мнений по этому поводу быть не может.

От задачи таки зависит...

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

L>Почему же обидел? Просто за пропущенное юнит-тестирование (убедиться в отсутствии протечек) сантехник, в отличие от криворучки-программиста, может вполне получить неиллюзорных люлей непосредственно от заказчика и порой прямо не доходя до кассы. Отделаться сдавленными матами от коллег, которые потом придут это поддерживать, не выйдет.

при таком взгляде на работу сантехника мотивация смены специальности с программиста на сантехника как-то не просматривается? Или речь о мазохистах?

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


L>>Это время используется для обозначения действия, завершенного к настоящему моменту без указания конкретного периода в прошлом. То есть "have you done any unit testing at all?" == "писали ли вы тесты когда-либо?". Посыл ложный, о чем я и говорю.

b-3>И всё же вы неправы — ваше present continious тоже не вполне корректно. Вот страница из очень авторитетной оксфордской грамматики, CGEL.

В разговорной речи в оксфордский словарь заглядывать некогда. Именно в разговорной речи present continous зачастую заменяет простое настоящее время самым причудливым образом.

b-3>И надо помнить, что мыщъх вообще-то живёт в США и с native-ами общается изрядно, так что предлагаю постановку "единиц по инглишу" друг другу прекратить.

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

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

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

L>>Тем, для кого юнит-тесты эквивалентны занятию ерундой, срочно рекомендуется сменить профессию. На сантехника или там развозчика пиццы.
L>>Других мнений по этому поводу быть не может.

E>От задачи таки зависит...

Абсолютно согласен. Если стоит задача написать очередной "превед мир", то юнит-тесты можно не писать.

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

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

L>>Почему же обидел? Просто за пропущенное юнит-тестирование (убедиться в отсутствии протечек) сантехник, в отличие от криворучки-программиста, может вполне получить неиллюзорных люлей непосредственно от заказчика и порой прямо не доходя до кассы. Отделаться сдавленными матами от коллег, которые потом придут это поддерживать, не выйдет.

E>при таком взгляде на работу сантехника мотивация смены специальности с программиста на сантехника как-то не просматривается? Или речь о мазохистах?

Позиция сантехника предлагается тем, кто еще не безнадежен и может учиться. Пару раз огребет, глядишь, и научится чему. Остальным же разучивать "свободная касса!"

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

L>Абсолютно согласен. Если стоит задача написать очередной "превед мир", то юнит-тесты можно не писать.

Есть задачи, где юнит тесты фиг напишешь. Например, это все задачи, в которых правильное поведение системы заранее неизвестно. Например, таким свойством обладают многие программы в AI...

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

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

L>>Абсолютно согласен. Если стоит задача написать очередной "превед мир", то юнит-тесты можно не писать.

E>Есть задачи, где юнит тесты фиг напишешь. Например, это все задачи, в которых правильное поведение системы заранее неизвестно. Например, таким свойством обладают многие программы в AI...

Налицо непонимание концепции и предназначения юнит-тестирования. Объяснить или сам догадаешься?

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

E>Есть задачи, где юнит тесты фиг напишешь. Например, это все задачи, в которых правильное поведение системы заранее неизвестно. Например, таким свойством обладают многие программы в AI...

Можно конкретный пример, когда правильное поведение системы неизвестно?

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

L>Налицо непонимание концепции и предназначения юнит-тестирования. Объяснить или сам догадаешься?
Зачем догадываться до общеизвестных вещей?
Есть разные подходы к этому делу, но та секта, к которой принадлежишь ты, просто не умеет программировать иначе, чем с юнит-тестами. Просто адептом твоего направления для того, что бы спроектировать нормальный класс, нужно сначала написать для него тест, типа такая вот спецификация на код. В принципе подход, как подход, не лучше и не хуже других. Но он не единственный возможный, тем не менее.

Просто далеко не во всех программах и далеко не у всех специалистов основную трудоёмкость занимает именно кодирование и проектирование кода, ещё бывает разработка алгоритмов, построение данных всяких хитрых, настройка системы и т. д... И там юнит-тестирование мало полезно. Кроме того есть довольно много программистов, которым вообще не трудно написать какой-то код, основная стоимость разработки в таких проектах вообще не в кодировании сидит, а в других формах разработки...

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


DR>Можно конкретный пример, когда правильное поведение системы неизвестно?

Ну торговля на бирже, например, или распознавание речи...

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

E>Здравствуйте, Don Reba, Вы писали:


DR>>Можно конкретный пример, когда правильное поведение системы неизвестно?

E>Ну торговля на бирже, например, или распознавание речи...

О майн готт.
Про распознование речи говорить ничего не буду, но системы для торговли можно и нужно обкладывать тестами чуть более, чем полностью.

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

DR>>Можно конкретный пример, когда правильное поведение системы неизвестно?

E>Ну торговля на бирже, например, или распознавание речи...

Это не конкретно, на таком уровне не составляют юнит тесты. Давай копнём один из этих примеров чуть глубже. Вбиваем в Google Scholar "speech recognition" и выбираем первую прикладную статью: "Minimum Prediction Residual Principle Applied to Speech Recognition". В ней реализуется распознавание слов по следующим шагам:

1. записывается слово
   
2. запись попускается через фильтр низких частот
   
3. результат дискретизируется
   
4. слово разбивается на части, и в каждой звук моделируется линейной комбинацией последовательных по времени сигналов
   
5. звучание любых двух слов сравнивается по линейным коэфициентам

Каждый шаг выполняет сторого определённую функцию, для каждого алгоритма известно правильное поведение.

• Пропускаем через фильтр тестовый сигнал: смотрим, остались ли в нём высокие частоты. Пропускаем белый шум, пропускаем нулевой сигнал, итд.
  
• Дискритизируем тестовый сигнал: смотрим, соответствует ли результат эталону.
  
• Моделируем тестовый звук, проверяем точность модели.
  
• Берём простые наборы тестовых коэффицентов, считаем дистанцию на калькуляторе, смотрим, соответствует ли алгоритм расчётам.

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

L>В разговорной речи в оксфордский словарь заглядывать некогда. Именно в разговорной речи present continous зачастую заменяет простое настоящее время самым причудливым образом.
Причудливым, т.е. непонятным вам?

L>Никто его за язык не тянул. Он сам на инглиш перепрыгнул, да и кто из нас с ним больше с нейтивыми общается, вопрос тот еще

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

L>>В разговорной речи в оксфордский словарь заглядывать некогда. Именно в разговорной речи present continous зачастую заменяет простое настоящее время самым причудливым образом.
b-3>Причудливым, т.е. непонятным вам?

Причудливым == не описанным в оксфордских словарях.

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

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

DR>>>Можно конкретный пример, когда правильное поведение системы неизвестно?

E>>Ну торговля на бирже, например, или распознавание речи...

L>О майн готт.
L>Про распознование речи говорить ничего не буду, но системы для торговли можно и нужно обкладывать тестами чуть более, чем полностью.

Речь тут шла не про юнит-тесты, а про систему, правильное поведение которой не известно...

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

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

DR>>>Можно конкретный пример, когда правильное поведение системы неизвестно?

E>>Ну торговля на бирже, например, или распознавание речи...

Ты просил пример системы, а не класса.

Если хочешь класс -- то любой классификатор, например нейросеть...

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

M>Я иногда кое-что пишу или отлаживаю на Delphi или FreePascal (не только на них и вообще это не так важно). Сегодня отлаживал одну ошибку, программа почему-то падала. Выяснил, что падение возникает из-за ошибок в некоторых данных (это другая история), которые программа забывала проверить на корректность. Добавил проверку. Можно было бы успокоиться, что все заработало, но решил выяснить, из-за чего она все-таки падала при неправильных данных.

M>Это меня ошарашило. Я несмотря на то, что казалось бы имею давний опыт программирования на Delphi еще с 90-х годов и иногда периодически что-то писал, не знал, что exit внутри try...finally вызывает не немедленный выход из функции, а переход к блоку finally. Думал, что этот блок исполняется только в нормальном случае или при исключениях, а exit немедленно завершает функцию. Ошибался. Теперь удивляюсь, как же я умудрился раньше не нарваться на ошибки в этом месте (дважды вызов Free например из-за этого)

M>Мораль в качестве выводов:

M>1) Если есть ошибка полезно докопаться до ее истоков, а не просто избавиться от нее.
M>2) Можно обнаружить что-то для себя новое в казалось бы давно и хорошо известном.

Когда-то, более 15 лет назад, в книге Тома Свана "Освоение Borland C++ 4.5" я прочитал очень толковую фразу (не дословно, но суть такая):
-Дебаггер — великий учитель!!!

В Delphi отладчик есть?
Думаю что есть (с Delphi не работал, а в C++ Builder отладчик имеется).

Что же мешало Вам, уважаемый Michael7, пройти все это по шагам в отладчике?
Тем более, что exit — это такая штука, которою пользуются — хорошо если один раз в десять лет...

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

AG>Когда-то, более 15 лет назад, в книге Тома Свана "Освоение Borland C++ 4.5" я прочитал очень толковую фразу (не дословно, но суть такая):
AG>-Дебаггер — великий учитель!!!

AG>В Delphi отладчик есть?
AG>Думаю что есть (с Delphi не работал, а в C++ Builder отладчик имеется).

Есть конечно отладчик. Причем я пользовался даже не Delphi, а Lazarus, но там тоже есть отладчик, возможно несколько проще, чем в Delphi, но это не важно.

AG>Что же мешало Вам, уважаемый Michael7, пройти все это по шагам в отладчике?
AG>Тем более, что exit — это такая штука, которою пользуются — хорошо если один раз в десять лет...

Обычно в отладчике прохожу, когда что-то не работает и из отладочных сообщений неясно почему же именно. Или если нужно в чужой программе быстро разобраться, тогда тоже, а так вроде и потребности особой не возникало. Тем более, что обычно старался не выходить exit-ом, а так или иначе переходить к блоку finally, к тому же далеко не всегда exit был внутри try, так что повода для ошибки вообще не было. В общем, такой вот парадокс, что можно было очень долго заблуждаться на счет правильной работы exit внутри try.

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

E>Ты просил пример системы, а не класса.
E>Если хочешь класс -- то любой классификатор, например нейросеть...

Но и тут поведение известно и прекрасно тестируется. Нейросеть тоже состоит из набора отдельных алгоритмов. Например, для тестирования классификации устанавливаем тестовые веса и проверяем, правильно ли классифицируются тестовые данные. Для тестирования обучения устанавливает тестовые веса и проверяем правильно ли они изменяются для тестового ввода и вывода. Когда всё так обложено тестами, гораздо приятней заниматься оптимизацией.

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

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

AG>>Когда-то, более 15 лет назад, в книге Тома Свана "Освоение Borland C++ 4.5" я прочитал очень толковую фразу (не дословно, но суть такая):
AG>>-Дебаггер — великий учитель!!!

AG>>В Delphi отладчик есть?
AG>>Думаю что есть (с Delphi не работал, а в C++ Builder отладчик имеется).

M>Есть конечно отладчик. Причем я пользовался даже не Delphi, а Lazarus, но там тоже есть отладчик, возможно несколько проще, чем в Delphi, но это не важно.

AG>>Что же мешало Вам, уважаемый Michael7, пройти все это по шагам в отладчике?
AG>>Тем более, что exit — это такая штука, которою пользуются — хорошо если один раз в десять лет...

M>Обычно в отладчике прохожу, когда что-то не работает и из отладочных сообщений неясно почему же именно. Или если нужно в чужой программе быстро разобраться, тогда тоже, а так вроде и потребности особой не возникало. Тем более, что обычно старался не выходить exit-ом, а так или иначе переходить к блоку finally, к тому же далеко не всегда exit был внутри try, так что повода для ошибки вообще не было. В общем, такой вот парадокс, что можно было очень долго заблуждаться на счет правильной работы exit внутри try.

А почему теперь понадобился этот самый exit?
В моем понимании, для Windows приложений с оконным GUI такой выход — это анахронизм.

ИМХО насколько я понимаю — это выход из приложения командной строки при нештатной ситуации...

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

AG>А почему теперь понадобился этот самый exit?
AG>В моем понимании, для Windows приложений с оконным GUI такой выход — это анахронизм.

Выход из процедуры/функции, а не программы Программы впрочем тоже, но только, если в запускающем файле записано.

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

L>2. Ошибки, найденные во время QA на проектах, покрытых юнит-тестами, разительно отличаются от ошибок, найденных на классических проектах. Обычно они лежат в плоскости "а мы считаем, что здесь спеки требуют другого поведения" и "поведение соответствует спекам, но заказчик понял, что ошибся в спеках и поэтому поведение нужно изменить", в то время как багрепорты от QA на классических проектах пестрят "упало", "не работает вообще", "сожрало всю память и опять упало" и прочими WTF.

видел я один такой проект (покрытый тестами).
пришёл ко мне на разработку багрепорт вида:
2012.06.23T7:50Z0001 Упало.... Exception*&^/№*&^
2012.06.23T7:50Z0001 Упало.... Exception*&^/*&^№
2012.06.23T7:50Z9999 Упало.... Exception*&^№"*&^
2012.06.23T7:50Z9999 Упало.... Exception*&^@;*&^
....

оказалось, после 2-х недель выяснения причин вот этого самого "упало" (код упавшего модуля я вообще впервые увидел), что виноват сторонний платный компонент, и ещё неделя ушла на придумывание теста, на котором оно гарантированно падает.

но "упало" — половина беды, а вот если повисло...

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

[...]

DR>Каждый шаг выполняет сторого определённую функцию, для каждого алгоритма известно правильное поведение.

Теоретически всё правильно, но на практике так не получится — это уже доказано опытом. (Даже Гейтс недавно высказывался на эту тему.) Все эти цифро-спектральные методы хороши только для анализа речи того, кто специально говорил для распознавателя и натренирован в таком говорении. В случае же реальной речи огромную долю выполняет контекст и семантический анализ, который ещё не научились формализовывать. Думаю, что коллега Erop имел в виду именно этот аспект.

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

DR>>Каждый шаг выполняет сторого определённую функцию, для каждого алгоритма известно правильное поведение.
N>Теоретически всё правильно, но на практике так не получится — это уже доказано опытом.

Впрочем, если речь об *юнит* тестах, то они тут таки возможны, хотя и не на всю логику.

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

b-3>>давно Present Perfect стало прошедшим? Present как переводится?
L>Рассказать, как переводится Perfect?

L>Это время используется для обозначения действия, завершенного к настоящему моменту без указания конкретного периода в прошлом. То есть "have you done any unit testing at all?" == "писали ли вы тесты когда-либо?". Посыл ложный, о чем я и говорю.

Present Perfect обозначает состояние в настоящем времени, возникшее в результате действий в прошлом и грамматически выраженное через эти самые действия. Например, "я покрасил забор" это Present Perfect. Но "я покрасил забор в равномерный серый цвет, и тут же банда панков его размалевала" — уже не может быть Present Perfect, потому что состояния уже нет, его испортили; это Past Perfect, потому что состояние было в прошлом.

Именно поэтому оно — настоящее, а не прошлое. Да, это может пугать — как это — глагольная конструкция выражает не своё действие, а состояние. Но если понять, то всё становится очень просто. Тем более что при глубоких раскопках в языке подобные переходы смысла — сплошь и рядом.

BTW, это грамматическое время сохранилось ещё с индоевропейского языка почти без изменений и в таком же виде было в древнерусском. Наше современное прошедшее время на -л, -ла... — остатки перфекта.

Возвращаясь к обсуждаемой фразе, да, "Have you done any unit testing at all?" — вполне законный Present Perfect, если подразумевается персональный опыт человека, но вполне может быть недопустимым, если речь о состоянии программы, в которую потом пришла банда быдлокодеров и всё разломала.

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

L>Сравниваешь теплое с мягким. Тесты выполяются автоматически во время каждого билда, и отладочная печать и логи по сравнению с ними находятся в одином ряду с каменным топором по сравнению с современным станком с ЧПУ.

А вот тут таки ерундите. Потому что слишком завязываетесь на юнит-тесты, в то время как реальная ситуация может требовать и другие виды функциональных тестов, включая запуск целых компонентов и подсистем в обстановке, эмулирующей реальную. Такие комплексные функциональные тесты тоже могут (и должны) запускаться автоматически, и для анализа их проблем логи и отладочная печать жизненно необходимы.

L>>> И, пожалуйста, не упоминай конечные автоматы в суе и особенно в разговорах со мной.
L>>> Порву на лоскуты размером в атом, а из того, что осталось, вызову цепную ядерную реакцию.
М>>стадию перехода на личности мы уже миновали и вот уже добрались до прямых угроз. давайте, рвите. мне и правда интересно
L>А вот не надо было соскользывать с темы и приплетать FSM куда не надо.

Всё равно не надо срываться на такое.

L>Цитату можно, где я соглашался?
L>Эти 3000 тестов будут состоять из трех-четырех строчек каждый; трудоемкость их написания на фоне затрат на разработку основного кода незаметна, а объем — вообще странная метрика. Более того, факт написания тестов оказывает положительный эффект на разработку собственно кода, поскольку тестируемый код должен удовлетворять критериям тестируемости, которые магическим образом совпадают с обобщенными критериями "хорошести" и "поддерживаемости" кода. Выполнение этих тестов занимает несколько секунд.
L>Трудоемкость такого подхода совершенно ничтожна по сравнению с затратами, которые потребовались бы на орагнизацию аналогичного по покрытию набора функциональных black-box тестов.

Их сравнивать в принципе нельзя. В реальности нужны и те, и другие.

М>>например, если это пульт управления микроволновой печи -- модель _доказывает_, что нельзя войти в меню из которого потом не выйти. именно, что _доказывает_, причем верификация осуществляется автоматически.
L>А вот тут я, как и обещал, порву тебя на лоскуты. Пульт управления микроволновки — это типичный пример state machine. То, что в ней нет тупиков, доказывается в первую очередь диаграммой состояний вашей машины и таблицей переходов. Верифицируется ручками, глазками, и девайсом /dev/brain. Как и все подобные конечные автоматы.

А у мыщъха оно верифицируется специальной тулзой, которая доказывает наличие пути из любой точки. И эта тулза точно так же может запускаться автоматически и не зависеть от того, что тот, кто в ковырнадцать тысяч ёкарнадцатый раз пролистал FSM на тему "ну чего они тут ещё натворили", случайно нажал PgDn дважды и пропустил какое-то важное изменение.

L> А вот после реализации можно и нужно написать функциональный тест, который в том числе проверит, что из каждого меню можно выйти в $HOME.

И сколько ты будешь писать этот тест?

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

Оффтопик и намёк на слив.

L>Нет никаких особых расходов на разработку этих тестов. Вообще, когда спрашивают о расходах на разработку тестов, это является признаком полного непонимания подхода TDD и использования юнит-тестов в разработке. Этот процесс не разделим на составные части.

Разделим, разделим. Как только ты начинаешь осознавать, что тех же юнит-тестов даже для простейшей функциональности можно нарисовать разумное количество, а можно — почти бесконечность, то начинается понимание, что тестирование тоже способно занять 101% времени и прочих ресурсов и его необходимо разумно ограничивать.

L>Как только разработчик становится адептом церкви TDD на своем опыте узнает преимущество юнит-тестирования, для него юнит-тесты перестают существовать как отдельная сущность.

Я давно знал, что TDD — это не методика, а религия.

L> Для нас процесс разработки есть процесс написания собственно кода и кода, его тестирующего. Они неотделимы друг от друга, как неотделимы и наши собственные оценки затрат и как результат, бюджет. Кроме того, наши оценки временных затрат зачастую являются гораздо более точными, так как, прежде чем приступить к estimations, мы должны не только ответить на вопрос "а что мы будем писать", но и "а как мы это будем автоматически тестировать".

Полностью согласен (только надо учесть ещё и ручное тестирование, хотя бы на верхних уровнях, которое всё равно обязательно).

Здравствуйте, мыщъх, Вы писали:

М>зачем ее собирать, когда она и так есть? http://www.cvedetails.com/ -- пища для размышлений. и ведь во всех этих компаниях есть целые подразделения, занимающиеся исключительно тестированием с нехилым таким бюджетом. а что на выходе? _абсолютно_ _ничего_ работающего хотя бы на 90%. это не значит, что тесты бесполезны. это значит, что на практике ошибки приходится фиксить _после_ релиза на стадии пуско-наладки. причем, эта вполне законная стадия, которой не избежал ни один проект.

Нет. Это всего лишь значит, что разработка строится так, что ТЗ содержит только требования к основному функционалу, но не к защищённости. И точно так же тесты создаются только для основного функционала. Иначе бы на любой потенциальный SQL injection был бы тест, который показывал, что недопустимое не происходит, все входные данные адекватно фильтруются, квотятся и так далее. И так же для других известных проблем.

Посмотри, например, на RFC4475. Тут народ постарался и нарисовал тестовые примеры для парсера. Мы включили требование соответствия этим тестам в ТЗ на свою реализацию (и постепенно движемся к этому — нет принципиальных проблем, но нет времени).

М>при этом далеко не все поддается тестированию. если модуль работает с железом, то все. кранты. даже если железо -- проц. на блоге ms можно найти инфу о том, как проц генерил ошибку доступа к памяти в инструкции типа mov eax, ebx. в ms долго курили очень хорошую траву пока их не торкнуло, что крэш дамп памяти извлекается из памяти. а исключение генерит уже декодированная инструкция глубоко в недрах ЦП, который разогнан сцука и потому там совсем не то, что ожидалось.

Ну так это разогнанный. Естественно, если поставить в такие условия, будет ерунда.
А так — модуль, работающий с железом, можно совмещать с эмуляцией того железа, которая будет проверять хотя бы базовые аспекты.

М>уже смешно? а если вы поставляете аппаратно-программный комплекс и он падает под нагрузкой только потому что не расчитан на такую температуру (типа флорида). вы тестируете его на аляске -- и у вас все хокей. ошибка упорно не воспроизводится. кто виноват? железо?

Ты требуешь уже совсем высокого полёта. Понятно, что идеально всё проверить и предусмотреть невозможно. Но есть вещи, которые проверить можно и дёшево, и это будет сильно дешевле альтернативных подходов.

М>в том-то и дело, что написать парсер, скажем, XML раз в 100500 раз проще, чем написать тест этого парсера. в обоих случаях требуются глубокие знания XML. если их нет, то парсер написать еще можно и он будет как бы работать, а вот написать для него тест и _доказать_ полноту теста -- это высший пилотаж.

"Полнота теста" в принципе недоказуема, если речь идёт о сколь-нибудь сложных действиях или даже обширных входных данных. Тут вспоминали сортировку — очень показательный пример. Мы в принципе не можем протестировать все варианты, их даже при малом количестве элементов (до сотни) дофига и больше. Но мы можем логически "вычислить" маргинальные случаи, проверить их и предполагать корректность работы на основании такого анализа. Более того, мы можем верифицировать алгоритм математически, для сортировки это достаточно легко; но это не исключает тестирования, потому что наше проецирование реального мира на математическую модель само по себе могло быть проблемным.

И таки да, в случае такой задачи, как парсер XML, надо при его написании думать о том, как тестировать. Как минимум это проверка парсинга элементарных лексем и нарушений структуры.

М> и на практике применяется другой подход. берут "живые" данные и смотрят на реакцию парсера. если на каком-то файле парсер падает -- юзер сабмитит этот файл в саппорт и там уже разбираются. это -- реальная жизнь.

На практике применяются оба подхода. Если бы парсер был выпущен в мир без тестирования, он сломался бы на втором же реальном примере. Поэтому всё, что могут и до тех пределов, пока есть ресурсы, тестируют локально, в предельно идеальном окружении. Нахождение ошибки в юнит-тесте одной функции дешевле в разы, чем в поведении целого модуля, того — чем в функциональном тесте подсистемы, того — чем в интеграционно-функциональном всей системы, но автоматическом, того — чем в ручном тесте собственного QA, и так далее. Квалификация программиста и тестера — в том, чтобы заранее продумать и проверить слабые точки и ключевые ситуации.

М>тесты пишутся тогда и только тогда, когда вероятная цена ошибки превышает затраты на разработку тестов.

А это случай >99.99% обычного программирования, поэтому лучше сказать, что тесты пишутся всегда, потому что их надо писать всегда.

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

Да нет тут никакой принципиальной границы между требованиями. Есть уровень ответственности, грубо говоря, Microsoft, есть — для ядерных бомбардировщиков, а есть все промежуточные уровни. Ответственность автора программы по управлению рентгеновским аппаратом (помнишь случай, когда тот гнал поток на порядки выше?) — в разы меньше ответственности автора софта для ядерного бомбардировщика, но всё равно цена ей — жизни людей. А есть управление тепловой станцией, когда вроде все будут живы, но в случае проблем — убытки на миллионы. А есть кластер, где случайный останов задачи — десятки килобаксов. Ну и так далее.

Это континуум уровней ответственности и соответственно допустимых трат на любые предварительные работы по качественной разработке. Тесты здесь — заметная, но принципиально не единственная часть.

М>так же я писал про файл-бомбы нового поколения, где архиватор распаковывает архив с циклическими симлинками. а вот попытка архивации/бэкапа этой директории приводит к бесконечному рекурсивному спуску и краху. протестировав большое кол-во архиваторов и программ бэкапа, а так же утилит и программ пакетной обработки файлов я удивился -- в среднем из 100 программ только 1 проходит этот простой и банальный тест из чего я делаю вывод, что функцию обхода дерева каталогов вообще не тестировали, а если и тестировали, то в сферических условиях.

Ты хоть в рассылки им написал?

F>>Это наблюдения из практики как она есть — никаких теорий.
М>в том-то и дело, что тесты -- не панацея. а юнит тесты это как целые числа на фоне всех прочих. и гордится тем, что у нас есть юнит тесты это все равно, что говорить "а я умею считать до ста тысяч миллионов".

Гордятся не наличием юнит-тестов. Гордятся тем, что налаженная схема разработки с их участием позволяет выявить большинство логически предполагаемых проблем до того, как они начнут всплывать на более высоком уровне.

М>чтобы что-то тестировать нужно иметь формальную модель этого самого того, что мы тестируем. а ее обычно нет. даже на примере парсера XML. ну есть спецификации разных версий, а есть ПО, генерирующее XML. часто бывает так, что ПО, генерирующее XML, являющийся нашими входными данными, противоречит спецификациям, но это ПО нам неподконтрольно. а заказчику класть на спецификации. ему нужно, чтобы две программы работали вместе, понимая друг друга.

Значит, это другая формальная модель — "понимать то, что называется XML в программе ZMMMLLL".

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

И юнит тоже. При достаточно заметном объёме (где-то как jQuery) появляется работа и для них.

М>в реальной жизни основная нагрузка ложится на QA.

В наших задачах выпускать на QA без своего тестирования это значит вообще не иметь шанса дать им продукт, который пройдёт их тесты.

М> они, в частности, проверяют, что в коде нет ошибок типа SQL-injection и вообще тестируют все, что только можно протестировать. а если у нас есть QA, то зачем вкладываться в юнит-тесты?

Затем, чтобы была ненулевая вероятность успешного прохождения QA.

М> да, конечно, юнит тесты бывают полезны местами, чтобы отлавливать наиболее грубые ошибки. но тут главное не перестараться и не вложить в юнит тест больше времени и сил чем нужно.

А слишком много и не вкладываем.

Здравствуйте, мыщъх, Вы писали:

М>проблема несколько глубже. результаты уже на лице -- в жабе стало нельзя легально прибивать потоки без участия с их стороны. допустим, мы вызвали скрипт манагер из жабы, который вызывает жаба-скрипт, контролируемый юзером/хакером. допустим, в жаба-скрипте while(1); -- в результате поток висит. легально снять -- нельзя. нелегально можно, но это уже хак.

Вот потому места, где такое требуется, надо писать на Erlang.

М>так же есть расширения для руби и питона, позволяющие вызывать движок google v8. и у большинства нет легальных механизмов отвалиться по тайм-ауту. как ни странно у фокса этот муханизм есть. точнее был. сейчас к нему прикрутили JIT и оно перестало работать (раньше интерпретатор байт-кода тупо считал итерации).

Ну это они зря. Надо внутренний аларм вводить.

а забыть про таймаут — да, элементарно. На днях лечил клиент нашего софта для оракловой базы. Если клиент послал запрос по соединению к базе, но вместо ответа или даже TCP RST с той стороны молчание, то он не в состоянии уйти по таймауту, и эта проблема где-то в недрах OCI libraries. Зато, если соединение было создано не само по себе, а взято из connection pool, можно из другого треда сделать ему drop(), тогда оно сразу выходит из ожидания.

М>если брать обработку исключений в венде, то там можно обнаружить два уровня. первый уровень -- это когда стек уже кончился, но запас по прочности еще есть. в этом момент выбрасывается нормальное исключение о том, что стека нет (на самом деле есть, но мало). фишка в том, что повторно это исключение уже не вызываается и когда стек заканчивается, то он заканчивается, а обработчик исключений требует стека для себя любимого, а стека у нас нет. в XP в этом случае винда вела себя... мягко говоря не совсем так, как описано в документации. процесс умирал в ядре без освобождения ресурсов (точнее, с негарантированным их освобождением). в семерке уже пофиксили это и добавили (грубо говоря) еще один уровень "finally" (в кавычках, потому что finally пришел из плюсов, но его концепция намного шире) и теперь у нас есть (грубо говоря) процедура аварийного завершения процесса (ядерная) и процедура аврального аварийного завершения процесса. разница между ними в том, что одна из них _гарантирует_ выполнение finally, а другая всего лишь намеревается это сделать.

Интересно, но я не понимаю, как тут вообще можно добиться переполнения стека. Имеется в виду стек ядерной фазы?

Здравствуйте, мыщъх, Вы писали:

М>повторяю еще раз -- тест должен _доказать_ полноту и непротиворечивость.

Бред, извините.
Тест ничего не должен и не может _доказать_.
Тест показывает (подтверждает) корректность работы в одном конкретном случае, который автор теста считает показательным для контроля необходимой работоспособности.

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

Искусство разработки тестов — в том, чтобы минимальным количеством тестов проверить максимальное количество возможных нарушений. Иногда этому помогают средства вроде анализа путей исполнения, но в остальном это остаётся неформализуемой задачей.

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

Дали бы URL. Это почитать действительно интересно.
А по сути — описанные ошибки это или недогляд людей (как в случае рентгена), или недостаточное покрытие ключевых точек (как во float в первопнях).

М>пытаюсь объяснить еще раз -- сложность _полного_ теста намного превышает сложность того, что мы тестируем.

Тем не менее, если делать тесты начиная с минимальных компонент (а это и есть юнит-тесты), задача получения работающего софта становится реализуемой. А без такого подхода — нет, никакие миллиарды не помогут.

М> откроейте глаза и посмотрите на то, что вас окружает. начиная с программного обеспечения и заканчивая медикаментами. далеко не все это тестируется, а если и тестируется, то неполно и поверхностно.

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

М>лопата! вот у вас есть библиотечная гамма-функция. а она у вас есть (если под никсы пишите). и у вас возникает вопрос -- как быстро она работает? насколько сильно ошибается? вы хотите знать подходит ли она вам или нет. у вас есть требования по точности и времени. известны и целевые платформы. дело за малым -- убедиться, что все воркается. и вот тут выясняется, что тестирование функции которая заведово работает выливается в сложную инженерную задачу...

Нет. Оно относительно просто. Потому что надо понимать, что именно и как тестировать.
Надо
1) взять заведомо известные случаи, нарушение которых означает, что что-то совсем принципиально неладно.
Например, lgamma(1.0) и lgamma(2.0) обе должны давать ровно 0.0, а lgamma(0.0) должно возвращать ошибку (NaN и EDOM, если в errno).
2) взять некоторое количество ключевых точек, в которых функция должна вычисляться с адекватной точностью. Например, если мы знаем, что 4! == 24, то lgamma(5.0) должно быть ln(24) == 3.1780538303479458; в зависимости от уровня требования к реализации мы допускаем какую-то погрешность или требуем точного совпадения. Точный набор ключевых точек можно оценить уже изучая реализацию.
3) регулярно проводить вместе с обычными тестами такой, при котором та же функция вычисляется другим, возможно, более тупым и кривым, но заведомо более понятным путём, и сравниваются результаты для нескольких случайно взятых аргументов. Этот тест может сработать далеко не сразу, но если есть проблема, то статистически вероятно он её когда-нибудь покажет, и, вполне возможно, это будет до жалоб юзеров.

М>вот он -- момент просветления. на уровне юнит-теста вы не можете сказать какие у вас требования к данной функции. допустим, время отклика системы должно быть не хуже 15 ms на таком-то железе. это во всей совокупности.

Они могут, если это специфицировано в ТЗ.

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

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

Ты даже не знаешь, где там "суперфункция", но уже делаешь вывод. А теперь скажи, почему ты предполагал, что результат срабатывания exit() вообще будет проверяться, если ТС предполагал, что exit() завершает всю программу включая код теста?

L>Далее, факториал, точнее, то, что принято называть факториалом, на C++ вычисляется в compile time.

Я хочу посмотреть, как ты напишешь реализацию на C++ факториала в compile time, когда аргумент станет известен только в run time. Код в студию.

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

N>Я хочу посмотреть, как ты напишешь реализацию на C++ факториала в compile time, когда аргумент станет известен только в run time. Код в студию.

Посчитать таблицу всех 12 32-битных или 20 64-битных значений факториала не так сложно.