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

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

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

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

Я тоже не являюсь специалистом в этой области. И знаком лишь с 50% литературы приведённой в boost документации, а самостоятельно читал и того меньше. Тем не менее вывод обоснован. Несмотря на то, что каждый алгоритм используемый в boost::random генераторах имеет под собой достаточно солидную теоритическую базу и в этом смысле они не являются "велосипедами", исполнение подкачало. Вы помните как раньше нельзя было использовать библиотеки без const? Сейчас есть такиеже проблемы с библиотеками без throw(). Кроме того, наивное использование ЛЮБЫХ генераторов случайных чисел плохая идея при написании программ высокой надёжности. Увы, ограниченность наших знаний о мире и недетерминированный характер некоторых процессов не позволяют нам обойтись без них. В boost документации в разделе мотивации об этом немного написано.
В программно-аппаратных комплексах высокой надёжности (и реального времени) практически всегда происходит не меннее чем трёхкратное дублирование вычислений и аппаратное сравнение результатов с автоматическим отключением сбойной ветки и подачей сигнала тревоги. Но это часто считается недостаточным и тогда требуется формальное доказательство правильности(и финитности) всех используемых алгоритмов. Классическим примером также является отказ от использования вырождающихся в O(N*N) вариантов сортировки Хоара.
Надёжность реализации boost-генераторов проверялась(?) лишь тестированием. Я не думаю, что авторы сознательно удалили assert-ы являющиеся продуктом доказательства правильности. А общеизвестно, что тестирование лишь позволяет обнаружить некоторые ошибки, а вовсе не гарантирует их отсутствие. Наличие возможности деления на ноль в boost::uniform_on_sphere::operator() и возможности генерации одинаковых последовательностей разными boost::lagged_fibonacci яркое тому подтверждение. Практически невозможно не зная заранее об этих ошибках написать тестирующую программу, которая их обнаружит. А выявить ошибку путём попытки доказательства правильности, возможно. Я же выявил. Кроме того, программы написаны довольно небрежно, о чём свидетельствует разное число пробелов при вводе выводе. Есть ещё несколько не рассмотренных здесь причин. Другие поучительные примеры к вышеизложенному находятся http://citforum.ru/programming/digest/scofdebug/t_cont.shtml (Изучение знаменитых (и не очень знаменитых) ошибок_ Глава из книги Наука отладки). Хотя к некоторым утверждениями оттуда (например, к совету комментировать старый код) нужно относиться с осторожностью.
P.S.
Надеюсь, я достаточно подробно раскрыл тезис, но в дальнейшем делать этого вероятно не буду. Сейчас я это сделал потому, что чувствую себя слегка виноватым перед Вами за недоразумение возникшее в ветке compile-time вычислений.