Что с повторимостью последовательности? Что с предсказуемостью последовательности?

Что с производительностью?

да вроде они все так работают) даже сишный ранд

Мерсен твистер - тяжёлый, его сложно инициализировать с помощью обычного seed; Будет один стейт на все потоки, или в каждом потоке свой стейт? Какое изначальное значение?

да я видел

Внезапно, никто не идкт на яндексоивент?

Я могу съекономить время: в джаве несколько классов для рандома (читай С++ных RBG), в ней нужно создать RBG чтобы генерировать число. RBG варьируются по секурности и дефолтному значению и проч параметрам... Тоесть выглядит очень похоже на то, что сейчас в С++

отменяет это тем, что в разных проектах абсолютно разные требования и нет возможности сделать rand(min, max) который бы подходил более 66% пользователей

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

srand(time(0)); это вообще секьюрити дыра

это ты горе-программистам скажи

Плохое решение - не значит что получилось

в этом случае да

ну сделай свой враппер тогда, 2 строчки

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

доку никто не будет читать

Давай я пару примеров приведу, где нужны абсолютно разные подходы: * бенчмарки - нужна повторимость результатов, при том между платформами и ОС * сервера игровой механики - нужна производительность, средняя стойкость и можно немного потратить время на старте. Повторимось либо нужна, либо противопоказана * эмбедед - нужны низкие затраты по памяти и производительности, части апаратных решений нет * финансы - повторимость противопоказана, крайне высокая стойкость, пользоваться просто генератором без подбрасывания энтропии нельзя * интерфейсные штуки - srand(time(0)) и ОК :) + нужно помножить это всё на многопоточно/однопоточно Я не знаю ни одного решения, которое бы удовлетворяло большинству пунктов

и вот уже где-то нужна повторимость, а где-то нет

ага и пишут min + rand() % max

Ну, в предыдущем проекте эта функция давала неравномерный рандом например. Был написан комментарий, но ее не трогали.

Ну вот split было бы круто иметь.

«Подключите boost за 5 минуток» так себе решение, если честно.

Компиляется он быстро щас.

10 минут это ок.

Для такой громадины.

ИМХО.

Рабочий проект за час собирается

Еще contains для std::map очень хочется.

Еще contains для std::map очень хочется.

Плюсую.

Я бы за, но не я рулю проектом...

Еще contains для std::map очень хочется.

сделал, работает, как free function )

Ну, блин, функцию я и сам напишу

сделал, работает, как free function )

Ну да. Так всегда. «Сделайте за пять минуточек свой велосипедик».

Чо вам, сложно что ле.

И из проекта в проект пишутся/тащатся свои велосипеды для мелких таких задач.

Да, я понимаю, что нужно писать пропозал.

А не бухтеть.)

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

ну, тогда чем конкретно ты недоволен?

пропазалы есть, они обсуждаются

/offtop просто в погоне за универсальностью можно упустить элементарное удобство offtop/

да, бюрократия, дело такое

ну так пропозал то где?

rand(min, max) не появится из воздуха

Есть эти пропозалы, насколько я знаю. Но они не считаютcя приоритетными.

http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0458r0.html

Есть эти пропозалы, насколько я знаю. Но они не считаютcя приоритетными.

И так всегда(

Ну давайте тогда и распределение Уишарта запихнем, чо?

Якобы это добавление избыточности в интерфейс

Якобы это добавление избыточности в интерфейс

Давайте писать две строчки вместо одной...

никакой, делаешь либу - суешь туда свое распределение, пользуешься

лучше сделайте open classes и будет найс

А я предлагаю добавить в язык зависимые типы.

И паттерн матчинг.

Плюсую!

Яростно плюсую!

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

А я предлагаю добавить в язык зависимые типы.

отличная идея, добавляй!)

вопрос о полноте самый непростой

Еще contains для std::map очень хочется.

myMap.count(value) > 0 уже не работает?

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

И паттерн матчинг.

я за, хотя он уже есть в std::variant

ну, понятно, "за все хорошое, против всего плохого", я тоже с тобой согласен

только когда остановится? где грань?

myMap.count(value) > 0 уже не работает?

Это не сильно отличается от myMap.find(v) != myMap.end()

Это не сильно отличается от myMap.find(v) != myMap.end()

Довольно сильно на самом деле.

я за, хотя он уже есть в std::variant

Такой себе. Но формально да.

Это не сильно отличается от myMap.find(v) != myMap.end()

ээ, довольно сильно? count() менее эффективен же

ээ, довольно сильно? count() менее эффективен же

Да вроде не должен. Логарифм так же.

в мультимапе больше считать

ээ, довольно сильно? count() менее эффективен же

На секундочку они генерируют идентичный код.

Для std::map

https://godbolt.org/g/7GHA4f

На секундочку они генерируют идентичный код.

Для map да, для multimap действительно вплоть до линии, если все одинаковые

Оригинальный вопрос был про map :)

http://en.cppreference.com/w/cpp/experimental/randint

а где randfloat?

std::default_random_engine - вот от этой штуки у меня пригорает :)

а что делать-то надо?