а мне нужно сортировать по времени создания

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

компаратор указал, контейнер низя другой

std::map<uint256, XBridgeTransactionDescrPtr, MyCompare>

третим аргументом задаётся свой компаратор

auto cmp = [timestamp](const TransactionPair &a, const TransactionPair &b) { return timestamp(a.second->created) < timestamp(b.second->created); }; std::sort(trList.begin(), trList.end(), cmp);

но это не лист

у мапы нельзя брать разность итераторов

std::sort неприменим для std::map.

т.к. не существует distance(it1, it2) в мапе

std::sort неприменим для std::map.

Она и так всегда отсортирована.

auto cmp = [timestamp](const TransactionPair &a, const TransactionPair &b) { return timestamp(a.second->created) < timestamp(b.second->created); }; std::sort(trList.begin(), trList.end(), cmp);

^

все, спасбо, перемудрил

Товарищи, а никто не пользовался srcML? http://www.srcml.org

Существуют ли серьёзные имплементации "green thread'ов" на C++? грубо говоря что-то на подобии Golang Goroutines?

После написания вебсервера на Go писать аналогичный софт на C++ просто жутко. Non-blocking concurrent code намного сложнее писать на традиционных потоках нежели на goroutine'ах, которые можно спокойно блокировать писать в асинхронном стиле с использованием Event Loop'а тоже не особо

boost::asio, coroutines.

нашёл лишь https://github.com/nifigase/greeny но на серьёзное решение не похоже

Эээ, сервер например? Это самая многопоточная среда

Нахрена для сервера именно зелёные потоки?

Для того, чтобы писать в синхронном стиле, в стандарт как раз тащат coroutines.

Кроме того, зелёные потоки без GC работают через задницу.

Rust пытался их протащить в начале своего развития, потом выбросили всю концепцию напрочь.

Нахрена для сервера именно зелёные потоки?

потому-что это не усложняет код. Потоки обрабатывающие запросы имеют свойство блокироваться, например при работе с БД, FS и подобным IO. Блокировать основные потоки очень нехорошо, а green потоки блокировать не страшно

У тебя твои green потоки будут всё так же через какой-то scheduler работать.

boost::asio предоставляет как раз его, и coroutines уже поддерживает.

Так что при желании можно писать уже сейчас.

boost::asio предоставляет как раз его, и coroutines уже поддерживает.

можно ссылочку пож?

можно ссылочку пож?

Не могу, тут администраторы что=то намудрили и ссылки не вставляются.

Кроме того, зелёные потоки без GC работают через задницу.

А в чём возникают проблемы?

Зелёные они потому, что стэк маленький.

Особенно непонятно, чем в этом месте корутины отличаются от обычных потоков, с которыми вполне можно работать без GC

Зелёные они потому, что стэк маленький.

И?

И. Если ему надо расти, удачи в перемещении объектов.

Зелёные они потому, что стэк маленький.

context switching менее затратный, плюс зелёные потоки работают поверх in-process scheduler'а, а не системного scheduler'а

Copying or segmented stacks. In Go, there is no need to provide a maximum stack size for the goroutine. The stack grows incrementally as needed. One consequence is a goroutine does not require much memory (4KB-8KB), so a huge number of them can be happily spawned. Goroutine usage can therefore be pervasive. В Go так.

[rust-dev] Abandoning segmented stacks in Rust — искать по этим ключевым словам, почему не пошло.

Ну реализуй мне green threads without stacks. Не stackless coroutines, а именно зелёные потоки с userspace scheduling.

С того перепугу когда увидишь и сравнишь код на C++ и Go)) на Go реально намного проще и чище конкуррентный, асинхронный, неблокирующий код.

Ну реализуй мне green threads without stacks. Не stackless coroutines, а именно зелёные потоки с userspace scheduling.

А потом прикрути туда какую-нибудь стороннюю библиотеку, которая про твой scheduler ничего не знает, и просто использует, допустим, стандартный мьютекс для синхронизации ресурсов. Что заблокирует OS thread.

А потом прикрути туда какую-нибудь стороннюю библиотеку, которая про твой scheduler ничего не знает, и просто использует, допустим, стандартный мьютекс для синхронизации ресурсов. Что заблокирует OS thread.

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

я же тебе написал. Они нужны тогда, когда у тебя много конкуррентных/параллельных процессов, и тебе нельзя блокировать системные потоки работой с IO, и когда event loop - не вариант

И почему event loop не вариант?

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

И почему event loop не вариант?

по нескольким причинам, спонтанно могу назвать: - потому-что это 1 поток логики, и чтоб его слишком не нагружать - часть кода нужно реализовывать отдельными thread pool'ами, что сложнее и код становится менее однородным - потому-что программировать придётся в асинхронном стиле (аля JavaScript), не синхронном как на Go

И errno не использует никогда?

Это thread-local объект, внезапно.

по нескольким причинам, спонтанно могу назвать: - потому-что это 1 поток логики, и чтоб его слишком не нагружать - часть кода нужно реализовывать отдельными thread pool'ами, что сложнее и код становится менее однородным - потому-что программировать придётся в асинхронном стиле (аля JavaScript), не синхронном как на Go

Поэтому я и написал, что coroutines в стандарт тащат. Чтобы не было лапши из callbacks.

мы не можем использовать стандартные системные потоки. Ибо иначе мы либо будем их блокировать что вообще не гут, либо создавать их тоннами, что ещё более не гут

ну так правильно, я же перечислил benefit'ы, почему я так привык думать после Go просто тупо легче, на написание non-block async concr. кода уходит куда меньше времени и усилий

OS thread

ну так правильно, я же перечислил benefit'ы, почему я так привык думать после Go просто тупо легче, на написание non-block async concr. кода уходит куда меньше времени и усилий

Есть C++ Actor Framework. Активно пилится.

для меня самый идеальный вариант для решения данной проблемы на данный момент это Go просто Go это как-бы Google, и как-бы GC, и как-бы довольно специфический язык (язык конечно не плох, но отсутствие generic'ов всё-таки сказывается) и хотелось бы видеть что-то подобноее для C++

user-space scheduling, non-blocking asynchronous code in a synchronous manner

event loop'ов мне из JavaScript Node.js и Qt хватило

ок, и ты ничего не нашёл?

Thanks to co_await, the blocking calls can now be suspended and resumed. Acceptor acceptor{443}; while (true){ Socket socket= co_await acceptor.accept(); auto request= co_await socket.read(); auto response= handleRequest(request); co_await socket.write(responste); }

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

ок, и ты ничего не нашёл?

ничего сравнимого с Go по крайней мере

Thanks to co_await, the blocking calls can now be suspended and resumed. Acceptor acceptor{443}; while (true){ Socket socket= co_await acceptor.accept(); auto request= co_await socket.read(); auto response= handleRequest(request); co_await socket.write(responste); }

Вот это планируют в С++20.

Не вижу, куда ещё синхроннее.

Thanks to co_await, the blocking calls can now be suspended and resumed. Acceptor acceptor{443}; while (true){ Socket socket= co_await acceptor.accept(); auto request= co_await socket.read(); auto response= handleRequest(request); co_await socket.write(responste); }

как эта тематика конкретно называется? что гуглить?

ничего сравнимого с Go по крайней мере

при чём здесь Go? Я не очень понимаю, почему это должно быть на уровне языка

как эта тематика конкретно называется? что гуглить?

Coroutines proposal.

корутины, файберы...

при чём здесь Go? Я не очень понимаю, почему это должно быть на уровне языка

почитай выше плиз, переписывать не охота

с WinAPI не работал, не знаю

почитай выше плиз, переписывать не охота

так чем плохи корутины и файберы?

так чем плохи корутины и файберы?

пока затрудняюсь ответить на данный вопрос

надо лучше изучить тематику

Если ивентлуп - это проблема, то проблема надуманная

"почти" это как понять? какова разница?

Если ивентлуп - это проблема, то проблема надуманная

это асинхронный, НЕ синхронный стиль программирования, думаю после многолетнего опыта с Node.js и Qt понимаю о чём говорю

но ведь под капотом у го ивентлуп)

Go после Node и Qt это чудо))

но ведь под капотом у го ивентлуп)

неважно что там под капотом, важен стиль написания кода

Go: func doBlockingStuff() error { fileContents, err := file.read() // blocking if err != nil { // file read failed err = database.write(emergencyData) // blocking if err != nil { // emergency database write failed return err } return err } err = database.write(fileContents) // blocking if err != nil { // database write failed return err } return nil } JS (Promises) function doBlockingStuff() { return new Promise((resolve, reject) => { file.read() .then(fileContents => { return database.write(fileContents) }) .then(() => { resolve() }) .catch(err => { switch err.name { case FileReadFailed: database.write(emergencyData) .then(() => { resolve() }) .catch(err => { reject(err) }) break default: reject(err) } }) }) }

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

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

в смысле? синхронный код легче читается нежели код в асинхронном декларативном стиле

и это я ещё не писал на callback'ах (ибо лютый ад получится)