Russian Qt Forum

https://www.linux.org.ru/forum/development/13158009?lastmod=1484810731834

Нет, не я. Мое знакомство с бустом началось когда один из контракторов сказал что нужна boost::polygon. Я подумал и разрешил - оказалось очень к месту. В прошлом году работал с либой где использовалась boost::filesystem. Не могу сказать что в восторге - не очень интуитивный сынтаксыс, приходилось гуглить. Но запрещать я бы не стал. Вот собсно и весь мой бустовский багаж. А вообще open-sources приходится привлекать довольно часто, 3-4 раза в год, но вот буста в них почему-то нет (std практически тоже). Ну может скоро придется собирать "alembic", там вроде много, вот и потренируюсь.

Не думаю что здесь много фанатов boost::filesystem. Наверное потому что и с QDir все очень неплохо

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

Либо тимлид понимает, что он как тимлид некомпетентен и таким образом старается повысить свою значимость на проекте.

Беда в том, что дуст::файлсистем в стандарт запихнули:(

а что именно в std::filesystem не интуитивно понятно?

directory_iterator который сам себе и итератор и контейнер по которому итерируется.
path который string на 1й системе и wstring на другой. прям взяли книжку "как не надо писать на плюсах" и написали

Ну вот зачем так тупо цитировать (пусть даже мои посты  :))?

Я и не подозревал о существовании std::filesystem и узнал о нем только сегодня, из Вашего вопроса. Поэтому что там (не)интуитивно - сказать не могу. Но смущает сам подход - да мало ли чего где "есть", так что, бросаться учить всякую новую "фишку"? Ну это если проектом не сильно загружен и есть время лазить там и сям.

речь не о том, нужно ли что учить или нет.
выше вы писали:
что именно не интуитивно понятно?

fs очень маленькая.
содержит только типичный набор функциональности.
просто любопытно, что там может быть не понятным?

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

а вот фраза: "сам себе и итератор и контейнер по которому итерируется" - смахивает на какой то бред.


path - платформо-зависимое явление.
очевидно жеж, что в зависимости от платформы он может быть utf-8, utf-16, ansi, etc.

к тому же, совершенно не принципиально, как именно хранит path свои буковки
принципиально, что у пользователя в распоряжении кучка методов,
которые позволяют извлечь path явно, как std::string, std::wstring, как utf-8, etc

это удобно, и логично.

и причем тут книжка "как не надо писать на плюсах"?

И часто вы можете от итератора позвать std::begin? Или всё таки от контейнера? а от dir iteratora - можете (чтобы работал for_range). for по итератору! Причем достаточно было бы поменять название.


Угу, и это превращается в код вида
Удобно. Логично. То есть даже тот факт, что WString никто не исользует просто потому, что он непереносим между платформами, их ничему не научил.


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

Upd: вот это тоже прекрасно

Ну хорошо, вот я открыл упомянутую либу и взял наугад шматок с boost::filesystem.
Чехарда с версиями - и править код сторонней либы как-то не тянет. И оказывается есть filesystem и filesystem2 - какую читать? Оператор /=, ну наверное добавляет путь, хз. Быстренько в этом убедиться (просто открыв букварь) не получится, не та система. И предположение что используется правый слеш - значит кто-то должен заботиться о нативных вызовах злосчастного Вындоуз.

Что же тут "такого уж хорошего"? Разве это интуитивно? Или может это как-то компенсируется "глубиной концепций"? По-моему вовсе нет, особенно если сравнить с QDir и QFileInfo - вот удобные классы для людей, а не так. операторы задрочить.

Igors

Очевидно, что в std::filesystem чехарды с версиями нет, а / платформозависимый.

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

Зато есть словечко "experimental" быстро охлаждающее энтузиазм  :)

Не, ну идеи/задумки там конечно интересные, но елы-палы, как "неласково" :'( Чем-то быстро попользоваться (попастись) практически нереально.  Надо вникать в концепции, потом где-то изыскивать примеры, потренироваться, ну и вот тогда.. (может быть)... Но обычно дело-то этого не стоит. Ну та же filesystem - да нафиг мне надо во что-то там "вникать", мне надо удобно выдрать список файлов каталога, и чем быстрее я это решу - тем лучше.

Макопролемы, на венде и линуксе уже есть полная поддержка с++17 без experimental::.

Просто яблоко забыло новые (с++17) хедера положить, проблема известная.

не часто.

а вот идея "итерируйся пока валиден" - очень даже правильная.
применяется повсеместно везде, кроме стандартных итераторов std



а кто вам запрещал юзать всегда std::string? или всегда std::wstring?

ваш label->setText это не поддерживает?

бывает. только fs тут причем?




это - не факт.
потому что его юзают, и ещё как.
под виндой юзают на полную катушку.
потому что там юникод во все поля.

только fs то тут причем? она заставляет вас юзать std::wstring?

другие разработчики вынудили вас написать это:

фокус в том, что разработчики пляшут от платформы.
а платформа поклала на проблемы разработчиков.


а ещё, порядок вычисления аргументов функции есть unspecified
у вас какая то проблема?

может быть аргументы плохо вычисляются?
или conversion method как то плохо работает на какой то конкретной платформе?

зачем его править? у вас что-то не работает?

впервые слышу про filesystem2
гугл кстати, тоже ничего о ней не знает.

вот видите как все интуитивно.

мне вот любопытно, а что ещё мог бы делать слэш в файловых путях?


то есть, написать:
это что-то запредельно сложное?
http://rextester.com/QYP64737


ээээ... не распарсил этот поток сознания. винде вообще пофигу: правый/левый.
причем тут fs?


я покамест не увидел примеров не интуитивности.
QDir и QFileInfo - те же яйца.
в чем принципиальное отличие?

Всегда std::string мешает юзать то, что conversion uncpecified.
Всегда std::wstring мешает юзать то, что на линуксе он 4 байта, а не 2 как на венде.
Проблемки-с.

Да я собсно ничего доказывать не собирался, Вы спросили чем мне boost::filesystem не приглянулся - я ответил. Насчет Qt реализации - ну поприятнее и побогаче, напр задать фильтры так и сяк и забрать контейнер, а не тюкать по одному тем итератором..

Принципиальной разницы - разумеется никакой, НО опять-таки: мне не нравится сам подход. Ну вот ЗАЧЕМ мне "асиливать" тот или иной std класс ? Просто так, "повышать повышаемость"?  У любого использующего Qt эта потребность давным-давно закрыта. Ах, вот если надо будет сделать консольное приложение.. ну вот тогда этот класс и открою, а так "на всякий случай" есть бездарное разбазаривание  интеллектуальных ресурсов.

каким именно образом conversion uncpecified мешает вам юзать std::string?
приведите пример.


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

сейчас ваши тезисы со стороны выглядят так:

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

я не просил никаких доказательств. я спросил: что именно не удобно? приведите пример неинтуитивности, или и неудобств?

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

но вы же вообще не привели никакой конкретики.
не очевидно: что именно не так?


приведите сравнительный пример как это удобно на qt, и как не удобно на fs.
сейчас не в полне очевидно, что мешает задать фильтр дя fs, работая с итератором.

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

где сама по себе идея: "перебрать файлы" - и есть по сути работа с итератором.



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

ответ прост и очевиден: осиливать Qt придется, если хочется состояться,
как программист Qt.

осиливать std придется, если хочется состояться,
как программист с++


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

например, нужно по быстрому создать независимый (детачнутый) тред.
в случае с qt всегда нужно помнить о нюансах: система кютешных сообщений.
которые по итогу выливаются в подобную хрень:
https://toster.ru/q/289471
https://habr.com/post/202312/
http://rsdn.org/forum/cpp.qt/6946232.all

куча кода ради кода, только за ради поддержания куютешной архитектуры.

Я, может быть, неправильно читаю документацию, но это значит, что конвертации UTF16 -> UTF8 (std::string) на венде нет. Может вам сделают её, а может и нет. А может это будет cp1251 или любая другая local8bit. То есть надо ЯВНО указать, как конвертировать (QString::fromWChar(path.wstring()).toUtf8()).


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

Не разделяю этого мнения (к сожалению, популярного). Бездумное пожирание std ничего не дает ни уму ни сердцу, зато изрядно калечит молодых ребят.

Может я чего-то не понял, поясните зачем такое чудо (независимая нитка) нужно? Не вижу как это связано с линками ниже. И что плохого в Qt сообщениях? По-моему только хорошее. Пример

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

Сделать это пуляя Qt сигналами - не вопрос, а вот на std - придется изрядно попыхтеть. Конечно std::thread - это хорошо, избавляет от походов в нативняк всякий раз когда нет фреймворка. Но упиваться std решениями опрометчиво, стандартная библиотека и не должна быть "лучшей", она всего лишь должна "обеспечивать достойную конкуренцию".

вы не правильно понимаете понятие "uncpecified".
в плюсах есть два понятия: "undefined behavior" и "uncpecified behavior"
первое означает: "поведение не определенно, но все плохо".
второе - "поведение не определено, но все хорошо".

вам не нужно думать,
как именно fs выполнит преобразования для std::string на конкретной платформе.
раз оно "uncpecified", значит каким бы оно ни было - все будет хорошо.

uppsss...
std::filesystem::path::generic_u8string


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

хотите UTF16?
о боже!
std::filesystem::path::generic_u16string

или может быть UTF32? ну вы понэли.







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

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

и почему я каждый раз вынужден задавать вам один и тот же вопрос: "почему вы так думаете? приведите пример"
вы в состоянии сразу аргументировать свои тезисы?



по-первых, в реальности int реально плавающий.
а во вторых, для basic_string<char_type> определены операции, дающие определенный результат

это что за бред?
пример "различий" вы конечно привести не в состоянии.

зачем вообщще нужны нитки вы в курсе?
чем более они независимые в контексте решаемой задачи - тем лучше.
это как бе азбука "фри-лок" алгоритмов.



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

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



тормозные. неудобные. не интуитивные.

попыхтеть?


это конечно неиллюзорно трудно!


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

кутешный тред - прожорливая скатина.
стандартный - тупо оч тонкая обертка над системным апи.

Очень удобно называть аргументы бредом:)

Я, если честно, так и не понял, чем generic отличается от native. До того, как вы о нем сказали, я даже не знал. Вот я читаю документацию и вижу копипасту с заменой native/generic. И чо?

Не нужно. До какой-то версии QThread::run был вообще pure virtual.

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

ваши "аргументы" - это бред,
потому что итерация по wstring абсолюбтно точно такая же,
как итерация по string,
или итерация по какому нибудь basic_string<custom_type>

привести пример различий итераций для string и wstring вы не сможете.
потому что их не существует.





и то, вы как то странно смотрите.

нет там никакой копипасты.
есть кучка конвертеров,  и один единственный метод 'native'

приведите пример "не нужности"
я сам помниццо, наступил на эти грабли, и пинал вручную евент-луп.

1. http://doc.qt.io/qt-5/qthread.html#create
2. берете и переопреляете run() и не нужен никакой эвентлуп из 7 залуп

и этот новый тред не получает сигналов.

а что бы получал, придется мало мало залупиццо.

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

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

вместо одной простоq строки: std::thread(threadFunction).detach();

сама по себе технология слотов-сигналов - ущербное унылое г.

если я захочу послать объектам сообщение, я сделаю:


разруливается времени компиляции. и для этого мне не нужны никакие моки.

А что делает этот detach? Теперь нитка не может быть joined - зачем? И что это дает? Да ничего, наоборот, добавляет проблем

Ну а lock-free то здесь причем? И что это за (не)зависимость такая? Разве команды не выполняются параллельно (simultaneously как говорят буржуи) при наличии 2 и более ядер?

На всякий случай повторю задачку
Прошу исполнить на чудесном std

детачит тред. внезапно, да?

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




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

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

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

структуры данных и алгоритмы, которые обеспечивают безопасную работу в условиях многопоточности,
без использования примитивов синхронизации,
в простонорадье называют "lock-free"



я же уше выше показал как это можно сделать:

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

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

И что  ??? Как это поможет? Напр "печатающей" нитке нужно знать что символ "готов" и его можно печатать. В Qt c помощью тех самых "дураццких" сигналов это легко сделать и новичку (кстати и перекрывать ничего не надо). А вот как на std - покажите

Вы сами себе противоречите, то вам нужны сигнал-слоты и приходится чо-то там делать с эвентлупом, то не нужны. Какие слоты в std::thread??

печатающая нитка сама знает, когда готовы её данные
потому что она отвечает за их подготовку.

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


std::function<type> должно хватить всем.
для особых ценителей есть boost::signals2

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

но на практике в 99% за глаза хватает std::function<type>

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

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


ну ок. тогда так:

По меньшей мере трижды было сказано "сделать 2 нитки" - а Вы лепите пул, это совсем не одно и то же. И разве tools::thread_pool - штатное средство std? Где же богатырская сила если для студенческой лабы "производитель-потребитель" уже приходится привлекать сторонние зависимости?

Профессионал не спрашивает отчего да почему и не критикует задачу, он просто ее делает. А умельцев типа "как не делать (и обосновать)" всегда было и будет с избытком и без нас  :)

Грубость ни к чему

вы можете хоть 10 раз сказать: "мне нужны именно нитки",
но лично я не полезу на первый этаж через чердак,
если могу зайти через парадные двери.

tools::thread_pool - тонкая обертка над std::thread и std::conditional_variable.

если вам хочется глянуть, что там под капотом:
https://en.cppreference.com/w/cpp/thread/condition_variable



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


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

"написать код не сложно. сложно понять какую на самом деле задачу нужно решить"
(ц) Макконелл. "Идеальный код"


бред - неадекватное, не соответствующее (либо противоречиещее объективной реальности)
виденье положения вещей.

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

правильно ваша задача решается так:

подождали, распечатали. ждем дальше

При работе с пользователями чердак - еще не худший вариант  :)

По-моему этот пример так же неверен как и этот (http://www.prog.org.ru/index.php?topic=32189.msg237374#msg237374)

Допустим thread стартует с солидной задержкой и главная нитка успела выполнить  cv.notify_one() - но на мутексе еще никто не ждет. Или worker был вытеснен и не успел с cv.wait, Тогда побудка notify_one не имеет эффекта. А когда worker наконец получит управление и отдастся на мутекс - его будет некому будить.

Ну это как я знаю - а может в std это уже не так? Глянул доку

С собсно переводом - проблем нет, но смысл доходит плохо. Хреново сформулировано (язык ни при чем)

Или я где-то ошибаюсь?

В код особо не вчитывался, но навскидку возможно тут надо два cv а с одним могут быть баги\дедлоки.

Вы так и не разобрались как работают условные переменные? Мы же это несколько раз разбирали. :)

Ничего не будет из-за того, что главная нитка успеет выполнить cv.notify_one(), когда его никто не ждет. Если это произойдет, воркер даже не станет на wait, а сразу пойдет дальше.

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

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

В теме предлагается рассмотреть академическую задачу Producer/Consumer, имеющую большое прикладное значение. Количество способов реализации с учетом всяких частных случаев огромно.

Представленное решение на std использует глобальные переменные и жесткую взаимосвязь между Producer и Consumer. Для решения конкретной задачи подойдет, почему бы и нет. Но практически также можно всё написать и на Qt.

Реализация Producer/Consumer с помощью механизма signal/slot преследует цель - исключить зависимости между Producer и Consumer, для возможности их независимого повторного использования в любом сочетании.
Можно, конечно, отметить, что реализация механизма signal/slot в Qt кособокая - требует наследование, нарушает принципы инкапсуляции, использует генерацию кода, потоко зависимая и т.п.
Но порог вхождения в Qt достаточно низкий, функционал богатый, поэтому инструмент имеет большое распространение.

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

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

Я про тоже самое.  ;D Сигнал/слот, очереди, подписки, последовательный/параллельный, пул потоков/один поток, синхронный/асинхронный, блокированный/неблокированный и т.п. Алгоритмов реализации много.
Чтобы адекватно сравнить два инструмента, их нужно рассматривать в одинаковом алгоритме. Иначе будет "битва подходов", где сами инструменты почти ни при чем.

А накидайте - ка что-нить реально рабочее, а не наколенное.. Мож пригодится. :)

ошибаетесь. код безупречен.

Очередь событий называется ;)

Ну это очень общее название. Я бы это скорее назвал очередью задач. :)

всегда думал - что обычный тред-пул.

В тред пуле, как раз, потоки из очереди задач задачи и достают. Очередь задач как бы часть пула потоков.

Да, тоже не заметил  :)

Схема одна и та же, другой нет, ее надо просто зазубрить

Реализация std (вернее выбранный примитив) пожалуй самая сложная/трудная. Попробуйте напр сделать то же но в цикле - и уже придется чесать репу. В то же время слот/сигналом не составляет труда, а если хочется на примитивах - есть прекрасный (Q)Semaphore

Что это за мода появилась хаять Qt, причем "в самых общих чертах"?  :) Даже если согласиться с "кособокостью" - это невысокая цена за удобство использования. Даже знать базовые примитивы синхронизации необязательно, есть средства удобнее/приятнее

Ну это вам придется чесать репу, а человеку знающему как работают условные переменные - не придется. Потому, что эта конструкция для циклов как раз и приспособлена. :)

дык. о том и речь.

Вот не надо тут "ляля" про условные переменные. То, что в стд засунули лямбду как проверку предусловия, конечно, удобно и избавляет от ошибок, но лямбды появились только в 11х плюсах, а для "человека, знающего, как работают условные перменные" горааааздо дольше примером были QWaitCondition или pthread_cond_wait где никаких лямбд не было и прекондишн надо было проверять руками. На что мы с Igors и напоролись - не увидели малюсенький вызов лямбды.

На самом деле бесят апологеты стд которым НАКОНЕЦ-то дали какое-то АПИ которым они везде тыкают как будто это омагад какое изобретение.
Ну да, std::vector лучше QVector из-за мув-семантики, которой не было когда писался QVector, а поменять теперь QVector нельзя из-за совместимости (как и сделать в std::vector signed size_t для индекса или сделать struct {key, value} вместо богомерзкой пары в std::map). Я же не троллю вас тем что у вас для строки надо писать std::string::npos вместо банальной -1.
Стд тоже далеко не идеально, взять те же футуры или строки или регэкспы или... Но чертова совместимость мешает это всё исправить.

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

Не могу с Вами согласиться.
Да, первый вариант экономит строку, но ценой "запоминания". И вот за что я не люблю std - он весь прямо-таки засыпан таким калом. Немногие нужные полезные вещи просто тонут в таких "экономиях 1-2 строк" на которые и уходит > 90% энергии изучающего. Впрочем есть люди которые стремятся запомнить как можно больше, им это в кайф.

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

C++ (Qt)
#include <QtWidgets>
 
QString data; 
QSemaphore semWork(0), semMain(1);
 
class MyThread : public QThread {
	void run( void )
	{
		while (true) {
			semWork.acquire();
			if (!data.size()) 
				break;
			data += " proccesed";
			qDebug() << data;
			semMain.release();
		}
	}
};
 
int main()
{
	MyThread worker;
	worker.start();
 
	const int numTest = 5;
	for (int i = 0; i < numTest + 1; ++i) {
		semMain.acquire();
		if (i == numTest) 
			data.clear();
		else
			data = "data " + QString::number(i + 1);
		semWork.release();
	}
    worker.wait();
}
 

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

Класс. :)
Очередное одноразовое решение, которое уже завтра пойдет в корзину... :)
Завтра мы поняли, что нам нужно маштабировать решение и у нас теперь 10 производителей и 20 потребителей. Все перепишем? :)

Или не нужно будет масштабировать:)

Но тут от подхода зависит. Можно один раз написать нормально и через какое то время просто изменить значения пары констант, а можно написать одноразово и надеятся что поток кто то перепишет нормально. :)

#define нормально. С моей колокольни кажется, что вы предлагаете заниматься оверинженирингом ради premature optimisation.
Далеко не факт что именно это место будет узким местом.
Но да, какая-нибудь универсальная очередь может и решит задачу (эвентлуп с блокирующим ожиданием, наверное, решит). Но это если кто-то добрый написал эту очередь; писать её только под эту задачу с мыслью "когда-нибудь мы ее замасштабируем и переюзаем" - ну такое, похоже у вас оч много свободного времени:)

Авварон, эта очередь пишется за 10 минут (это несколько десятков строк кода). Я сейчас с телефона, поищите тему про самодельные очереди, там это все обсуждалось. И было еще несколько тем, в одной я такую очередь выкладывал полностью. Не найдете я выложу универсальную.

Ну, очевидно, что очередь в десяток строк кода не имеет всей полноты функционала, который можно придумать:)
Как например то, что в случае очереди событий одно событие может обрабатываться по разному разными объектами, очередь задач этого не умеет.
Чейнить задачи - тоже весьма полезная фича (чего, например, не умеют QFuture/std::future, а дустовые, вроде, умеют).

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

std::mutex? не, не слышал.
если заменить им ваш семафор, будет ровно тоже самое.

тут какой то фейл.

"очередь событий" это и есть "очередь задач".
задача сама знает как себя исполнять.

"события" которые по разному обрабатывают разные "объекты" - не нужны.

Скажите это любой гуи-библиотеке или игровому движку:)

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

Какой мудрый ответ! И главное - оригинальный и остроумный :) Про мухи и котлеты никто еще не додумался! Но вернемся к (сопливой) задачке
Задача поставлена конкретно - 2 нитки. Чего базарить? Сказано для 2 - делайте для 2. Сказано для N - делайте для N. Разумеется это уже до задача, и заказчик обязан сформулировать внятные требования - а кто кого тогда должен печатать. А Вы обязаны снять с него за это еще бабло. Не надо лезть с решениями "на все случаи жизни" - можно (мягко) предложить -и быстренько заткнуться если нет понимания. Тише едешь - дальше будешь

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

Write-only code detected.

Как вы ловко в воздухе переобуваетесь. :)
Вы же сами в большинстве своих тем рассказываете, что заказчик ничего не знает и сформулировать ничего не может. Нужно самим дорабатывать. :)
Не всегда заказчик с разработчиком могут оценить нагрузки. На примере интернет проектов, заказчик планировал что посещаемость сайта будет 100 человек в день, а через месяц она выросла до 10000 человек в день. Что ему делать, закрывать проект и приглашать нормальных программистов? :)

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

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

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

вот так и рождаеццо говнокод.

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

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

Ну изначально претензия была что кутред слишком СЛОЖНА он эвентлуп крутит

нет. тред-пул - это не просто пул тредов.
потому что просто пул тредов никому не нужен.
точно так же, как никому не нужны просто треды.

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

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

и я различаю очередь задач (банальный стек из std::function),
и пул (механизм управления временем сна и жизни своих тредов)

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

Кутред тоже говно, именно из-за этого эвентлупа.
Это поведение абсолютно неочевидно и приводит к кривому коду и багам.

Я на предыдущей странице распинался про обратную совместимость.
Уж извините, на момен написания QThread не было ни лябд, ни сраной std::function,  а мелкософтный компилятор не умел даже в шаблоные мембер функции.

Мммм, как ведет себя класс написано в документации.
Если кутред сабкласснуть, но никакого эвентлупа не будет.
Как он может мешать если его нет?
А если вы не сабклассили кутред, то что вы ожидали?

Мое мнение совершенно противоположное. QThread - прекрасный механизм. Единственное что можно поставить ему в упрек - он разлагает пользователя Qt, настолько просто и удобно все делать на QThread что и знать/понимать особо ничего не надо. Впрочем есть и QThreadPool и QtConcurrent

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

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

Ну это у вас. Весь остальной мир по прежнему их использует. :)

Вы не знаете как остановить выполнение потока? :)
А пауза, не смотря на свою полную бесполезность (ну может в GUI программах можно придумать хоть какое-то применение), легко делается на тех же условных переменных.

с тех много воды утекло. плюсы шагнули далеко в будущие.
а кутред как был г. так им и остался.

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

кстати, что будет с кутешным сокетом,
если запихать его в обычный std::tread,
и попробовать читать/писать ?

внезапно окажется, что знать/понимать нужно,
что бы не поиметь нежданчиков.


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


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

Какие тонны? Где?  ??? Давайте не скатываться в пустые пререкания, а возьмем простую задачку и сравним.  Ну вот хотя бы банальщина - копирование файла в фоне (типичный "вынос в поток"). С минимальным стервисом - показ прогресса в главной нитке (пусть в консоли) и возможность отмены. Или предложите свою, я не против.

Вы предлагает сломать весь существующий код или чо?
Ну давайте заодно в std::vector на signed перейдем, а то говно какое-то, приходится size_t богомерзкий использовать.
Или std::string наконец уже допилим до поддержки utf-8 и различных кодировок.

Ахаахах, то-то в последнем XCode забыли положить хедера из с++14))))
Я уж молчу про мелкомягких

Но кутред не нужно наследовать уже версии с 4.5.
Нужно запустить функцию - юзаете std::thread.
Нужен эвентлуп - юзаете QThread.
Ничо что они решают несколько разные задачи теперь? Ну да, до сих пор есть виртуальный run который не выкинешь потому что сломается куча старого кода. Но вас кто-то заставляет им пользоваться в новом коде?

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

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

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


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

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


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

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

вот здесь:

тут вроде по-русски написано, не?

вы там выше в этой самой теме приводили пример,
где переопределяли метод run.
и вот нафига это нужно?

Больше загадочных tools::

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

Ну по такому огрызку понять мудрено. Вот мой компилябельный пример (аттач). Файлы копируются в тот же фолдер, к имени добавляется " test_copy".  Добавлять файлы (кнопка "Add Files") можно в любой момент, по одному и пачками. Отмена одна на всех. Файл .pro писала MSVC, поэтому не уверен 100% что он рабочий.

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

Вернемся к теме. Вы утверждаете что std "тупо лучше", в Qt, мол, "многословно", а слот/сигналы вообще "г" (ну "кидаться говном все мастера" как говорил еще незабвенный Пастор). Будьте добры привести рабочий код подтверждающий Вашу точку зрения.

"главная нитка" - это к тем, кто в многопоточку не умеет.

под капотом будет что-то вроде:

> и нафиг я должен думать о каких то там эвентлупах,

Не, ну так нельзя. Qt - это фреймворк со своими правилами.

> запустил функцию. просрался QSocket.

Где? Просто надо юзать блокирующие waitForXXX(), т.к. в не-Qt-шных тредах нет евент лупа. Иначе - ССЗБ, читай доку.

PS: Можно все перевернуть с ног на голову, заявив, что, мол беру boost asio, и нифига не работает, т.к. там тоже есть луп/сервис (и его надо запускать),
а я не хочу его запускать, кочу юзать чтобы из QThread оно само работало. Мол, boost гавно, не работает в Qt.

> "главная нитка" - это к тем, кто в многопоточку не умеет.

Многопоточка для тех, кто асинхронный ввод/вывод не осилил. Пачкование тредов это не есть хороший дизайн, это костыли. Так и тредов не хватит.  :)

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

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

А что, Вы умеете обновлять UI из любой нитки (а не только главной)? Расскажите как, я так не умею  :)

Что/где и под каким капотом - никто не спрашивал. Речь идет о простейшем "выносе длинной операции в поток"(чтоб UI не замерзал) который здесь делают все кому не лень. Потому что - да, на Qt это легко и приятно. А вот как на std -хз. Ни о каком тамошнем механизме обмена инфой между нитками я не знаю. Мы увидим std реализацию этой простейшей задачки - или только понты типа
У меня давно уже стойкое подозрение - человек "ниасилил" букварь. Развейте пожалуйста, очень не хочется разочаровываться в человеке  :'(

Ну это просто Qt говно - вон, винапи же умеет.

бинго!

закономерный вопрос:
а нафига треду нужен ещё какой то костыль в придачу
в виде ниразу не очевидного эвент лупа?

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

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

четкие поцаны юзают тред-пул.
и о боже! так реализуется асинхронка.

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


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

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

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

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

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

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

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

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

Нет. Асинхронка может работать и в одном потоке.

А делать какое-то UI никто и не просил. Можете взять мое, или просто печатать в консоль. Если создается нитка, то она должна хотя бы минимально общаться с другими. Запуск "на деревню дедушке" никому не нужен, придется так или иначе "мониторить" запущенную задачу. В Qt для этого есть удобный механизм, а в std - ни кола, ни двора.

Да какой там "тезис" - так, мелочная претензия. Уже говорилось что run перекрывается только если хочется самому побаловаться с синхронизацией - пожалуйста, можно и так. Но делать это всякий раз - да кто Вам такое сказал? См мой пример в аттаче - никаких наследований от QThread там нет, нитке можно кинуть любое кол-во задач не прилагая никаких усилий. Можно просто запустить нитку без задач - и это ничем не грозит, и проц она не жрет. Можно удобно подсесть на сигналы завершения нитки и/или задачи. Вкусные плюшки. Наоборот, std-шный стиль запуска выглядит "каменным веком" - обязует заботиться обо всем самому. Ну спасибо хоть это дали, раньше вообще ничего не было.

В общем, в очередной раз убеждаюсь - изучение std отрицательно влияет на изучающего  :)

Конечно нет, она реализуется на эвентлупе (select/poll/epoll/kqueue)

И как оно узнает, когда надо дергать? Поллинг сделать? Ну-ну.

Мне кажется или вы читать не умеете? Третий раз на пишу - на момент написания QThread другого способа НЕ БЫЛО, а ваш хваленый стд ни тредов не имел, ни анордеред мапы.
Аналог std::function написать было нельзя потому что компиляторы не умели в шаблоны нормально.

Сейчас QThread нужен ТОЛЬКО для того чтобы крутить эвентлуп, НЕ НУЖНО перегружать run. Используйте для этого std::thread.
У них сейчас РАЗНЫЕ задачи.

Метод run есть ТОЛЬКО ДЛЯ СОВМЕСТИМОСТИ чтобы не сломать кучу кода.

Я как со стенкой разговариваю, ей-богу.

Кстати _Bers спалился что не опускался на уровень еполла и не писал сервак решающий "проблему 10к" ;)

вы осознаете, что противоречите здравому смыслу?

которые реализуются за счет многопоточки. Карл.

баранку гну.
механизму нужно что то дергать.
механизм знает, когда и зачем ему это нужно.
ваш Кеп.

Мне кажется или вы читать не умеете?
самолеты нужны, что бы летать.
у них у всех одинаковая задача.

с std::thread всякие кутешные сокеты начнут лагать.

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

а что там было в бородатых - не суть важно.

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

Авварон в курсе, как устроен епулл изнутри?

Эээээ, нет.

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


Правильно, потому для нормальной работы сокетов нужен epoll


Вообще-то важно. Вас пошлют на три буквы (перестанут юзать ваш фреймворк) те, кому вы сломаете код, убрав run из треда.


Ну да, лапшичный код из лямд горааздо лучше эвентлупа.

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

А вы думали там внутри эвентлуп в юзерспейсе как в азио? Ооок.

просто печать в консоль см. выше.

ещё std не умеет окошки рисовать.
вы вообще осознаете, что  и с чем сравниваете?


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

вот такой дизайн вымораживает:

перевожу на русский: "сношай меня в отдельном треде"
вот сколько всяких моделей (винапи, сдл, позикс, etc)
до такого бреда только кутя додумалась.

а ещё земля плоская, Карл.

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


глубоко фиолетовый фактор.

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




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

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



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

и о боже, это и есть многопоточка, Карл!

сам придумал - сам ответил. сам оокнул.

Пример хренового дизайна, вообще-то.

Вовсе нет. Ассинхронка не имеет ничего общего с многопоточкой. И никогда с ее помощью не реализовалась.

Юзерский поток тут один (как и процесс).

То, что ядро работает в другом процессе нас волновать как бы не должно.

Так можно сказать, что любое приложение, юзающее системный вызов (read, например), многопоточно.

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

• Асинхронно однопоточно
• Синхронно однопоточно
• Асинхронно многопоточно
• Синхронно многопоточно

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

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

Что плохого Вы видите в том что объекты имеют принадлежность к ниткам (их eventLoop'ам)? Это как-то не укладывается в Ваши теперешние понятия? Так может их-то и надо расширить? :) Ведь "детский лепет" (мягко говоря) с callback'ами просто неудобно слушать. У меня вообще впечатление что пока Вы рады "запуску нитки", а с остальными вещами еще и не сталкивались.

Не надо "оправдываться". Что изменилось что std там что-то "заимел"? Серьезные вещи не решаются цыганщиной типа std::function, нужна глубоко продуманная архитектура, взаимодействие классов. В Qt все это есть, а в std нет и не было, то так - какой ф-цией поудобнее тыцнуть, там-сям строку сэкономить. Мелкотемье/мелкочленье.

Более того и не будет никогда. Потому что std это стандартная библиотека C++, которая не должна диктовать разработчику как ему взаимодействовать между нитками. Она предоставляет ему нижний уровень, на котором разработчик может реализовать удобные для него и задачи механизмы взаимодействия.
А высокоуровневые механизмы уже реализуются в отдельных библиотеках, построенных на std. Для тех кто не может сам написать удобные и эффективные механизмы, существует множество сторонних библиотек (asio одна из них), в них есть все необходимое.

у них дизайн одинаковый.

простой вопрос:
в чем принципиальное различие между стилями программирования:
"асинхронным однопоточным" и "синхронным многопоточным"?

простой ответ:
принципиальной разницы не существует.

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

учитывая, что система, о боже! однопоточная, эвент луп у них, наверное,
в сферическом вакууме крутиццо.

А меня удивляют персонажи которые не догоняют разницу).

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

Ну если уж все свалилось в треп, то предлагаю такую темку

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

- ну конечно, Qt. Не считая мелких "жестов вежливости" позиция разработчиков ясна "чтобы духу тут std-шного не было!". Даже контейнеры свои (и с успехом)

- GStreamer - ну тут до std дело просто не нашло, суровый "С" (статУя вообще без плюсов)

- FBX  (фактически стандарт обмена данными между 3D приложениями). API никакого std не использует

Вспоминая предыдущие 5 лет - то же самое. Ну да, одна либа юзала std::string и std::vector, другая - только std::vector (впрочем и то в примерах). И это ВСЕ. Может я мало юзаю всякие либы (по мне чем меньше - тем лучше). Ну может и так. А может все проще - эта функторная срань никому не нужна? Может все хотят писать нормально, естественно, а не захлебываться итераторными соплями?

Когда я был маленький ... )))

Изначально (до C++11) конструкций std было недостаточно, чтобы покрыть большУю часть задач.
Не было atomic, thread, function, mutex, unordered_map, turple и др. Не говоря уже о самом языке (rvalue, variadic template, thread-safe static и т.п.).
Приходилось писать много чего самостоятельно. Сколько всяких велосипедов изъезжено  ;D. Зато сколько опыта и знаний получено!

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

Тем не менее sdt C++ стал заметно богаче и кое-где эффективнее, чем раньше.
В своих проектах потихоньку переползаю на std, оставляя Qt только для GUI.

Так трудно использовать то, чего нет :). До С++11 в std особо ничего и не было, вот все свои велосипеды и писали. Теперь может кутешники и рады бы на контейнеры std перейти, да кто за такой рефакторинг возьмётся? Обратная совместимость опять же. Есть ли проекты на С++, рождённые после 2015г., которые бы свои контейнеры изобретали или std принципиально не использовали? И, на всякий случай, много ли их по с равнению с теми, что std используют :).


Лично мне вот нужна. И судя по тому, что это появляется в стандарте, то это ещё кому-то нужно (вряд ли такие нововведения только ради меня одного :)). Мне с каждым новым стандартом писать становится всё нормальнее и естественнее. Выходило бы это только всё побыстрее и в компиляторах поддерживалось. Но обкатка временем тоже нужна, придётся смириться.

Ну например, из недавнего. Раньше было:
Стало


Убрались богомерзкие Q_ARG, теперь findUsages находит method в лямбде, а раньше не находил, ибо но был строкой.

О, кто-то ещё invokeMethod использует :). На такой баг (https://bugreports.qt.io/browse/QTBUG-69683) не попадали? А то складывается впечатление, что через invokeMethod никто ничего уникального(некопируемого) не передаёт. Или всем пофиг :).

ViTech
Пффф, юник_птр в QVector не положишь, а тут инвок вы хотите. Ишь чего!

А по-моему все (немногое) хорошее в std было уже лет 20 назад. Тот же вектор, мап, сет, лист и десятка 2 по-настоящему хороших ф-ций (как напр lower_bound, nth_element и др). Основа любого проекта - такие простые данные, без них-то никак не обойтись. Ну конечно что "абсолютно необходимо" - всегда спорно. Напр может шаред органически не хватало, рисовать ++refCount приходилось частенько.

Ах, да это же ну очень простые, да чего там - примитивные вещи! Нам (эстетам) нужно намного больше! Не верю. Какой-нибудь задроченый тупл никогда не сделает  "погоды" в проекте. Может быть он поможет лучше (компактнее, проще и.т.п.) что-то решить, но это было и останется мелкой технической деталью - forever. Ну а если уж так необходимо - то кто хотел давно нашел (в Qt, boost и.т.п).

Общие вещи никогда не будут "в единственном числе", альтернатива всегда найдется. И сравнение совсем не в пользу std. Тот же std::thread - он же QThread в подметки не годится. И появился всего-то  лет через 15 (?) существования std. Дошло наконец что кросс-платформенное создание нитки все-таки нужно. Ну и слава богу, "лучше поздно чем никогда"

Человек весьма уверен что он "на правильном пути" :) Я никогда не увлекался либами и использую только когда "ну вот совсем никак без нее" (жизнь заставляет). Тем не менее я привел 3 либы широко известные и доказавшие свою эффективность. Могу привести еще десяток, хотя никакой я не эрудит. А можно услышать хотя бы об одной написанной на std? Или оно больше для любительского программирования (начитаться и поумничать) ?  :) Или все еще идет "процесс обкатки" (ну да, понимаю, дело не быстрое)

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

Поэтому я на быстрый фикс и не надеялся. Хотя в QVector это родовая травма, которая не лечится, а invokeMethod вроде достаточно в некоторых местах по цепочке std::move добавить.


Вроде никто не отрицает, что в определённый момент времени развитие C++ и std затормозилось. Лет 10 проспали (2000-2010), имхо. За это время все кучу своих велосипедов и понаизобретали, с которых теперь не слезть.В Qt тоже много всего понаписали, и я бы не сказал, что это венец творения. Да, лучше чем ничего, но хуже, чем могло бы быть. А по поводу "чтобы духу тут std-шного не было!", в последних версиях Qt сделайте поиск по "std::" в исходниках, и потом расскажите, много там такого духу или мало.


Вы за мою уверенность не переживайте :). Весьма уверен. И судя по последним вестям с полей, не я один. Но ежели кому нравится в лаптях ходить, так это дело личное :). И я говорил о проектах 2015г. и позже, когда С++11 устаканился в С++14, и компиляторы таки начали эти стандарты нормально поддерживать. А не о либах начала 2000, ясное дело, никто их переписывать не будет.


Что значит "написанной на std"? Например, Catch (https://github.com/catchorg/Catch2) достаточно на std написана?

Ну абсолютно любая вещь может быть лучше, а уж за европейскую зарплату - тем более :) Но перед тем как "снисходительно судить" - может применить это к себе? "А я чего понаписал? И как оно "могло быть лучше"? Попробуйте, очень полезная процедура :)

Не навязываю своего мнения, но считаю такое вложение сил непродуктивным. У приличных людей 3/4 работы не связано с собсно "реализацией". Это может быть чтение статей/диссеров (а лучше тезисов к ним), анализ open-sources (если имеются), поиск алгоритма, разработка архитектуры классов и.т.п. А собсно "написание кода" - скорее легкая и приятная часть. Поэтому если человек сильно носится с какими-то чисто техническими подробностями - ну значит "молодой ишшо"  :) Их-то как раз блестяще знать совсем необязательно.

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

У меня другой вопрос: что там в std можно изучать, тем более "чем больше - тем лучше"? :)
Итераторы? Вы уже много раз писали, что не можете с ними разобраться. Ну так и не трогайте их. Но это совсем не означает, что итераторы надо изучать, и их кто-то изучает - это слишком примитивная конструкция.
Вектор вы вроде освоили. Адресацию по индексу тоже. Что там еще в std осталось непостижимого для вас, что требует изучения?

Ни разу так не делал, надо попробовать. Спасибо, что подсказали :).


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


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

А Вам какие улучшения в std нужны, чтоб вот сразу всё попёрло и не надо было возиться с техническими подробностями? :)

Ну вот зачем, мягко говоря, "кривить душой"? :) Да, велосипедист иной раз и перегнет палку с оптимизацией, но это грех простительный. А вот std-шнику на тормоза и ресурсы наплевать. Ведь его цель - взять готовое "и не париться". Поэтому все сосредоточено на тупеньком запоминании "что делает тот или иной вызов". Ага, подходит std::find - ну и хорошо, а то что это "брута форса" - понятия нет. А как Вы давеча залепили N вставок вместо одной? И ничего, ведь главное сделано - нужный вызов std найден! Да еще и "с итераторами" - красота! Нужно с мапой работать по индексу (!?) - так вот же std::distance/advance! (наблюдал на этом форуме)

Ну я не в комитете (и слава богу). Конечно сама идея стандартной библиотеки прекрасна, насколько мне известно, языки помоложе (шарпы всякие) с этого и начинают. Задолбали эти "игры в обобщение", хотелось бы побольше капитальных "сущностей", а то пока аж 2 (unique и shared) - не разогнаться. И может необязательно все сводить к "вумным указателям", без оператора -> я проживу.

Вон оно чо :). Оказывается реализацию std дураки пишут, в лоб. И Вы бы всяко лучше написали обобщенные алгоритмы поиска в контейнерах разного типа и вставки диапазона элементов за одно действие (кусок vector в list и наоборот). В кутешных QList/QVector поиск не брутфорсом делается? И, опять же, можно поискать "std::find" в исходниках Qt. Ещё кутешники подло поступили с Вами и не добавили вставку диапазона элементов в QList (и в QLinkedList заодно). За что они так с Вами? :) И если таки понадобится вставить кусок QVector в QList, то как вставлять будете?

Есть такая штука - QtAlgorithms. Что мы там видим:

Чего это они под std прогнулись? Даже в свои хорошие контейнеры пришлось добавлять методы для совместимости с богомерзким std.


Тут бог действительно оберегает сообщество. Славься!


Так какие "сущности" нужны? Особенно интересно в разрезе умных указателей. А то мне некоторые недавно на пальцах объясняли, что "shared_ptr хватит всем".

Хотя список (QLinkedList или std::list, не путать с QList) и не очень популярен, это интереснейший контейнер. Быстрая (практически бесплатная) вставка у него по определению. Вот с ним ота песня с итераторами вполне уместна.

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

Не злитесь  :)

Ну я точно не был одним из объяснявших  :) Вот пример что нужно (я уже его приводил)

C++ (Qt)
struct SomeClient {
...
  SomeObject * m_Object;
...
};

Типовая ситуевина - клиент не владеет m_Object, не отвечает за его создание/удаление, т.е. клиент его просто использует - и все. В принципе все вполне норм (именно вследствие своей простоты/примитивности), если бы не одно "но" - если m_Object удален, то придется бегать и обнулять его во всех клиентах. И нужно как-то сохранить SomeObject для undo, причем честно (m_Object грохнут), а не так как в Qt. Напрашивающееся решение:

C++ (Qt)
QWeakPointer<SomeObject> m_Object;

Но это вынуждает владельца объявлять его шаред, а это головняк, надо все время смотреть не зашарился ли он где еще. И почему-то автоматом предполагается "продление жизни". Чего это? Я ничего продлевать не просил. Поэтому несколько лучше смотрится

C++ (Qt)
QPointer<SomeObject> m_Object;

Но эта радость только для QObject, общности нет.
И в любом случае проблем undo это не решает - все равно надо "бегать по всем клиентам".

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

Ну так сделайте его отслеживаемым (trackable).. Помнится, это уже обсуждалось:

C++ (Qt)
#include <iostream>
#include <memory>
 
class trigger
{
public:
    trigger() : m_flag(true) {}
    bool get() const { return m_flag; }
 
    friend class trackable;
 
private:
    void set(bool flag) { m_flag = flag; }
    bool m_flag;
};
 
typedef std::shared_ptr<trigger> spy_type;
 
class trackable
{
public:
    trackable(const trackable &)
        : spy(std::make_shared<trigger>())
    {}
 
    trackable()
        : spy(std::make_shared<trigger>())
    {}
 
    trackable &operator=(const trackable &) { return *this; }
 
    ~trackable() { spy->set(false); }
    spy_type spy;
};
 
 
struct SomeObject : public trackable
{
    //...
};
 
struct SomeClient
{
    SomeObject * m_Object;
 
    bool objectIsValid() const { return (spy) ? spy->get() : false; }
 
    void setObject(SomeObject * obj)
    {
        m_Object = obj;
        spy = obj->spy;
    }
 
private:
    spy_type spy;
};
 
 
int main()
{
    SomeClient Client;
 
    std::cout << std::boolalpha << Client.objectIsValid() << std::endl;
 
    SomeObject * Object = new SomeObject();
 
    Client.setObject(Object);
 
    std::cout << Client.objectIsValid() << std::endl;
 
    delete Object;
 
    std::cout << Client.objectIsValid() << std::endl;
 
    return 0;
}
 

 
https://ideone.com/q3IbxF (https://ideone.com/q3IbxF)
Undo тоже не сложно реализовать..

Если вот это всё вместе сложить, что получится? :)

В С++20 будут добавлены Concepts (https://en.cppreference.com/w/cpp/experimental/constraints), с их помощью можно узнать, есть ли в классе определенные типы/методы/поля. В С++17 уже есть if constexpr. С этими возможностями можно сделать алгоритм:
1. В классе есть свой метод insert(pos, first, last) - используем его напрямую.
2. Есть reserve(), end() (условно) - с их помощью реализуется обобщенный алгоритм вставки диапазона.
3. Есть одиночный insert(pos, value) - вставляем в цикле по одному. Тупо и для некоторых контейнеров дико не эффективно - а шо делать, хоть как-то надо вставить.
4. Ничего подходящего нет - ошибка компиляции.

Может "встроенные" методы insert(pos, first, last) в контейнерах и есть "необходимый и достаточный набор", и с помощью "reserve(), end()" не всегда или не для всех контейнеров можно написать обобщенный алгоритм, тут я ничего точно утверждать не могу, так глубоко в тему не погружался. Но в С++20 добавятся ещё и Ranges (https://en.cppreference.com/w/cpp/experimental/ranges), и чтобы была возможность вставки Range в контейнер, что будут делать: добавлять в каждый контейнер перегрузку insert с параметром Range, или сделают внешнюю функцию (ака алгоритм), которая этот Range передаст в виде итераторов в метод insert контейнера? И будут ли у этой внешней функции перегрузки для итераторов? Делаем ставки :).


Посмотрите в исходниках, что из себя представляет этот QPointer ;).


Если "клиент не владеет m_Object, не отвечает за его создание/удаление, т.е. клиент его просто использует" и "надо все время смотреть не зашарился ли он где еще", можно ли сказать, что кто-то владеет SomeObject уникально, а SomeClient имеет "невладеющую ссылку" на него? std тогда предлагает для владения unique_ptr, и голый указатель или observer_ptr (https://en.cppreference.com/w/cpp/experimental/observer_ptr) в качестве "невладеющей ссылки". Но если unique_ptr удалится (вместе с объектом), то ни голый указатель, ни observer_ptr об этом не узнают. Это и была одной из основных причин(плюс ещё многопоточность), по которой я начал мутить свои указатели. Но некоторые (не Вы) говорят, что shared_ptr хватит для всех, чтобы он еще где-то не шарился - "так смотрите внимательнее, что пишите", а что из weak_ptr можно получить shared_ptr - "так сам дурак, раз так делаешь" :). Но чтобы shared_ptr таки нельзя было так просто шарить дальше, на пальцах показали такое решение (http://rsdn.org/forum/cpp.applied/7174004.1) , можете воспользоваться :).


Вот и я вопрошал: "Доколе?" :). Но ждать не стал, и сделал себе велик сам. Нужен ли такой в std? Не уверен, может даже скорее "нет", потому как в upl::unique присутствуют накладные расходы, в отличие от std::unique_ptr. В качестве сторонней библиотеки - каждый сам решает, для меня-то она не сторонняя :). К тому же она интегрирована с std, насколько это возможно.

Да, ясно: создадим флажок и пусть его шарят объект и клиент(ы). Объект при удалении сбрасывает флажок, и, увидев это false, клиент узнает что объект уже удален. Критика:

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

- клиент: мне кажется более естественным хранить указатель и шаред флажок в структуре, снабдив ее бесхитростным методом get(). Чтобы не дорисовывать методы если появятся еще такие "используемые" указатели

Но это все цветочки. Главное - от беготни с поиском "кто ссылается на объект" эта конструкция никак не избавляет. Можно оборачивать шаред так и сяк - но он хранит только "факт ссылки". Собсно любая "вумность" указателей на этом и заканчивается. Пример: та же запись данных для undo. Известно что SomeObject грохнут, значит надо найти клиентов - а никакой инфы о них в SomeObject нет. Приходится решать это "как-нибудь" (напр пробежкой по глобальному списку объектов, или сигналами или еще как). Но тогда зачем городить еще какие-то конструкции - ведь найдя клиента можно просто обнулить в нем указатель - и все.

Не спорю, просто "указатель с валидностью" тоже неплохо, иногда достаточно и его, но часто/обычно нет.

Igors
хз, свазок shared/weak и unique/observer достаточно ИМХО для любых нужд.
К примеру весь парент-чайлд Qt делается при помощи второй.

Вот, к примеру, ваше любимое дерево (https://github.com/ABBAPOH/textureviewer/blob/master/src/libs/textureviewcore/thumbnailsmodel_p.h#L8). Думаю завернуть в шаблон через идиому base/derived и таскать между проектами

Не нравится наследование, сделайте trackable членом класса, например..

Это решается с помощью некоторого manager'а, который знает какие клиенты подписаны/следят за SomeObject. И в деструкторе m_Object просто пинаете этого менеджера, чтоб он автоматически передавал сигналы (со всеми необходимыми данными для undo) всем подписанным клиентам. Тогда не придётся "руками" бегать по всему списку..

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

"То що це йому дало?". Расскажите чего Вы таким образом добились, observer_ptr только мельком глядел, по смыслу вроде"само то" но ни одного примера нет и experimental

В std и не должно быть решений на все случаи жизни. Она даёт концепции и инструментарий/кирпичики из которых уже можно сложить и manager и клиентов и т.д.. 

Того, что по сигатуре функции видно, кто кем владеет.

Возвращаемый указатель надо удалять? Или его вью удалит? А если я всё-таки удалю, что произойдет?
А тут?
А тут?
Чуете проблему, к каждой функции приходится писать пространные объяснения кто кем владеет или догадываться по словам add/set. Думаю, если поискать, то можно найти неочевидных контрпримеров в АПИ Qt.


Ну обычный "вумный" указатель, который не владеет и за временем жизни не следит (как делает weak/QPointer). Используется чтобы показать, что объект удалять не надо, им владеет кто-то ещё как-то ещё и что он может быть удален. Апи 1в1 как у unique_ptr или shared_ptr (operator*, ->, bool, метод get()).

Например:

Видно, что датастрим хранит указатель на объект но им не владеет.

Я юзаю его так (https://github.com/ABBAPOH/textureviewer/blob/master/include/ObserverPointer#L17)
Впрочем, мб уже и под вендой появилось

Когда-то читал отличный учебник английского языка. Там примерно так
.
Здесь немного "не вкурил", ну ладно, не все сразу. Спасибо

Ну так давайте складывать. Боюсь что реальная реализация не будет использовать никаких std концепций/кирпичиков :) Напомню чего мы хотим - имея объект уметь находить всех ссылающихся на него. Ну и, само собой, уметь добавлять/удалять эти ссылки. При этом никакого владения нет, более того, даже цикличные ссылки могут быть разрешены.

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

C++ (Qt)
CSomeObject * refTarget;    // на него ссылаемся
CAnotherObject * refНandle; // а этот ссылается на кого-то
 
... // устанавливаем связь между объектами
СReferenceManager::InstallLink(refTarget, refHandle, LINK_TYPE_DEFAULT);
..
// имея target перебираем ссылающихся 
int numLinks = СReferenceManager::GetHandleCount(refTarget); // вернет 1 (один объект ссылается)
int linkType, index = 0;
void * handle = СReferenceManager::GetIndexedHandle(refTarget, index, &linkType);
void * handle2 = СReferenceManager::GetTypedHandle(refTarget, LINK_TYPE_DEFAULT);
...
// имея ссылающегося извлекаем target
void * target = СReferenceManager::GetTarget(refНаndle, LINK_TYPE_DEFAULT);
 

Понимаю, это совсем не модно :), да и с void'ами надо подумать. Ограничения - объект(ы) должен быть неперемещаемым. И в деструкторе объект должен позвать СReferenceManager, не вижу никакой возможности это проконтролировать (да, минус). Зато в остальном - нет никаких обязательств, интерфейсов и.т.п.

Критикуем, пинаем...

Да, осталась самая малость - понять, что с этими объектами, ссылающимися на заданный, вообще можно делать :). Вот получили с помощью СReferenceManager::GetIndexedHandle(refTarget, index, &linkType) какой-то объект, что с ним можно делать?

Я вообще перестал понимать, что здесь происходит)
Если максимально упростить задачу, то в этой истории останется 3 персонажа (в моём понимании): Client (их может быть много), Object,  который используют клиенты и Manager, который контролирует время жизни Object и оповещает всех клиентов, когда тот удаляется.

Вот как пример (на коленке) иллюстрирующий это:

C++ (Qt)
#include <iostream>
#include <list>
 
class Object
{
    //...
};
 
class Client
{
public:
    Object * m_Object;
 
    void makeUndo()
    {
        // ...
        m_Object = nullptr;
    }
};
 
class Manager
{
public:
    Manager(Object * obj = nullptr)
        : m_object(obj)
    {}
 
    void addClient(Client * client)
    {
        m_subscribers.push_back(client);
    }
 
    void killObject()
    {
        for (auto c : m_subscribers)
            c->makeUndo();
 
        delete m_object;
        m_object = nullptr;
    }
 
private:
    Object * m_object;
    std::list<Client*> m_subscribers;
};
 
 
int main()
{
    Object * obj = new Object;
 
    Client client1;
    Client client2;
 
    client1.m_Object = obj;
    client2.m_Object = obj;
 
    Manager manager(obj);
 
    manager.addClient(&client1);
    manager.addClient(&client2);
 
    manager.killObject();
 
    return 0;
}
 

 

Как уже говорилось, объект "используется" клиентом, т.е. клиент просто-напросто дергает методы объекта, ну или читает/пишет его public члены. Напр в случае undo нужно записать в файл пару уникальных ID (объекта и клиента), чтобы, если дело дойдет до undo, восстановить связку. А если таких связок несколько (почему нет), то дополнительно еще и идентификатор связки (linkType). Итого: при выполнении undo (перед удалением Object) значение возвращаемое GetIndexedHandle используется для получения уникального ID этого клиента.

Изначально персонажей только 2 - клиент(ы) и (используемый) объект. Клиенты должен знать объекты, которые они используют, а объекты - всех использующих клиентов. Как это реализуется (с manager'ом или без) - дело разработчика. Также "оповещение" (типа "ссылка изменилась") - вариант возможный но совсем не единственный (см пример undo выше)

Эти клиенты/ссылающиеся одного типа (или имеют общий базовый тип)? Или могут быть несвязанными между собой типами и ссылаться на один объект?

Меня тут другой вопрос вопрос беспокоит: С какого кхм-кхм.. объекту знать о всех клиентах? :)

И все это поместить в MainWindow и композиция будет завершенной. :)

А в центре вишенку - вьюху дерева (http://www.prog.org.ru/topic_32246_0.html) с 300 методами, которая синглтон.

Ну это же идеальный MainWindow. :)

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

Ну а почему Вы спрашиваете у меня?  :) Разве "член-указатель" - глухая специфика моего проекта? И как вообще Вам удалось избежать этой проблемы которая возникает повсеместно?

Конкретно в моем проекте - да, есть общий базовый тип, который (увы) давно стал (или всегда был) god-class'ом. Каких-то других "цивильных" решений я лично не вижу, возможно их и нет. Ну на всякий случай спрошу у фанов std (ну а вдруг?  :))

Ну объявить неудобную задачу неграмотной хочется всегда  :) Но налицо по меньшей мере 3 случая когда это необходимо

1) Объект удаляется - обнулить ссылки на него
2) Сохранить данные undo перед удалением объекта
3) "Оповещение" что данные ссылки изменились

Конечно можно решить "1" напр вумным указателем, а остальные 2 напр сигналами, но... хорошо ли это? Ведь очевидно что во всех случаях нужен доступ к одним и тем же данным (ссылающиеся). Или может это нарушает какие-то прынцыпы, мол, выходит "все о всех знают". Но ведь мы же сами устанавливаем "отношение" между объектами, поэтому появление новых зависимостей - то что и должны были получить. И с какой стати эти зависимости должны быть "одно направленными"? Чем это "отношение" хуже (или лучше) того же парент-чайлд?

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

А какие идеи/мысли вы ждете? Вы все уже ответили в своем сообщение выше: нужно использовать shared_ptr/wake_ptr, которые вы использовать не хотите, придумывая всякие отговорки.
А запердролить специальный менеджер, познакомить всех со всеми - вот это решение по вам. :)
Но обдумывать и серьезно обсуждать этот трешак уже никто не хочет, не смотря на то знает человек std или нет.

Возможно, следует обратить внимание на SOLID.


Это Вы правильно подметили: от человека, который не догадается сделать View синглтоном, не стоит ожидать мыслей высокого полёта и ослепительных идей. Даже если какие и появятся, всё одно будут выглядеть бледно на фоне сего :).

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

Но увы, такие простенькие соображения почему-то не приходят в std::головы :) Им обязательно надо что-то намутить с очередным вумным указателем, обязательно использовать std::вызовы, хотя очевидно что здесь они никак не помогут. Мнение что, якобы, "std - основа" - совершенно ложно и приносит немало вреда. Это всего лишь либа предоставляющая некоторые возможности (довольно ограниченные) - и не более того. Программиста не должно смущать что в std не находится ничего подходящего - там, правду сказать, вообще мало чего хорошего  :)

Ну так и реализуйте, в чём проблема :). Контейнеры, кстати, какие будете использовать?

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

Потому что простенькие решения ничего как правило не решают, а выступают костылями.

Не обязательно брать std решения, можете написать свои умные указатели, потому что они здесь как раз подходят. :)

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

Вы нашли там vector, уже хорошо. :)

Может и std, незачем здесь завязываться только на Qt
А Вы, стало быть, в кусты :) Ну да, вот побаловаться с "семантикой", навернуть еще пяток-десяток вумных указателей, выделить/подчеркнуть "сущности" - это да, заниматься этим интересно (как впрочем и любой "общей" вещью). А вот какая-то там черновая работа типа "найти ссылающихся" - фу какая бяка, "костыль" и.т.п. Да и вообще это "не основной ф-ционал", "да мало ли кто там чего захочет" и.т.п. Ну это Ваше право.

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

Да, ну и конечно это совсем не ново - нечто подобное наблюдаю еще с 90x, последний раз в GStreamer с которым познакомился в этом году. Когда-то обсуждали здесь "а как же (де)сериализовать такой член-указатель" - и по меньшей мере 3 человека рассказали о своих великах (весьма капитальных). Так что делать это приходится если и не всем то многим.

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

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

А Вы хотите, чтобы я за Вас Вашу работу делал? :) Так у меня своих задач хватает, всегда есть над чем голову поломать.


Тогда остаётся ждать, когда у других такие планы появятся. Библиотечка-то сама себя не напишет :).

Аминь!

И их можно понять. :)
С такими рефакторингами, программа может вообще перестать работать. :)

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

А из этого ничего выжимать и не надо. Даже, при вновь всплывших, операциях сериализации/десериализации.
Есть слабый указатель, если он ссылается на валидный объект - сериализуем id этого объекта, что бы при десериализации можно было восстановить связь, если ссылается на не валидный - сериализуем null-id, и при десериализации связь не восстанавливаем. id должен позволять однозначно находить объект при десериализации.

Как раз выжать можно что угодно, концептуально есть 2 способа владения - уникальное и шаредное. Есть ещё копия, но это то же уникальное (на стеке ли, через clone() ли).
Если вы придумаете какую-то друную идиому, вперед, я послушаю.
Дерево - это уникальное владение (дерево уникально владеет всеми нодами или нода уникально владеет детьми, ноды ссылаются друг на друга через Observer).
Граф - это уникальное владение (граф владеет нодами, связи между нодами задаются через observer_ptr). Я уж молчу что граф можно тупо на индексах постоить а данные хранить в векторе.

Уникальное владение - это хорошо :). А кто-нибудь "снаружи" дерева может хранить ссылки на его узлы(через observer_ptr)? Или доступ к узлам есть только внутри дерева?

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

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

Да что вы.

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

трудно найти черную кошку в темной комнате, особенно если её там нет.


под капотом эвент лупа у вас, вестимо,
сферический ваккуум, ога.

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

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

Всегда восхищали люди, которые уверены, что у них самый правильный мозг в мире :). Заходите сюда почаще и накидывайте побольше, а то скучно тут.

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

асинхронный дизайн придумал не я.
и он никак не зависит от моих мозгов.


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

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

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

Глупости какие. :)
Я так понимаю вы под bare metal без RTOS никогда не писали?

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

Так же это работает и на обычных система. Вы крутите event loop в одном потоке, в котором проверяете доступность сетевых данных, например, используя механизмы типа select/epoll. Если данные пришли - вызываем обработчик их читающий, нет обрабатываем другие события системы.

Или вы под асинхронностью понимаете только C++ async? :)

;D Ну с этим то я полностью согласен. И это очень даже хорошо).


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

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

Понятия синхронный/асинхронный относится к логике - прямой вызов/отложенный вызов.
Понятия однопоточный/многопоточный относится к технической реализации - без синхронизации/с синхронизацией.


Да уж  ;D ;D ;D. Сразу намного веселее становится.

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

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

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



вы вообще понимаете что такое "асинхронный дизайн" ?

асинхронный дизайн: запуск на выполнение не блокирующей функции.

ваш бизнес-поток не блокируется.
инициировав команду: "старт", он продолжает выполнение своей работы.


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

здравствуйте мутексы, здравствуй, много-поточное нутро.


асинхронный дизайн невозможно реализовать в условиях single-thread.
но вы можете попытаться его проиллюстрировать хотя бы в псевдокоде.

не можете?
увы. это - невозможно.

Глупости. Данные получаются и хранятся в регистре uart, пока не будут вычитаны процедурой получения.

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

Я да, а вот вы не очень. :)

А он и не блокируется, этот поток выполнения другие операции, которые готовы к обслуживанию.

Еще раз, легко возможно и я выше расписал как.

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

сопрограммы ортогональны асинхронному программированию.
внезапно.

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





"асинхронный дизайн на одном потоке" - это что такое вообще?

покажите приме-иллюстрацию.

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



а теперь правильный отве:

нет никакого  "отложенного вызова" в контексте асинхронки.

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

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


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

1.
ася то как раз мульти-поточная.

2.
под капотом системного епула так же много-поточный дизайн.

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

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


я решил, не комментировать далее голословные бла бла бла.

Набросал вам пример с двумя таймерами, который работает в одном потоке.

C++ (Qt)
#include <boost/asio.hpp>
#include <boost/chrono.hpp>
#include <iostream>
 
using namespace std;
using namespace boost::asio;
 
void onTimeout1( const boost::system::error_code &ec, deadline_timer &timer )
{
  if( ec == error::operation_aborted )
    return;
 
  cout << "Timer1 triggered" << endl;
 
  timer.expires_from_now( boost::posix_time::seconds( 3 ) );
  timer.async_wait( [&timer]( const boost::system::error_code &ec ){ onTimeout1( ec, timer ); } );
}
 
void onTimeout2( const boost::system::error_code &ec, deadline_timer &timer )
{
  if( ec == error::operation_aborted )
    return;
 
  cout << "Timer2 triggered" << endl;
 
  timer.expires_from_now( boost::posix_time::seconds( 10 ) );
  timer.async_wait( [&timer]( const boost::system::error_code &ec ){ onTimeout2( ec, timer ); } );
}
 
int main()
{
  cout << "Run demo" << endl;
 
  io_context io;
  deadline_timer timer1( io );
  deadline_timer timer2( io );
 
  onTimeout1( boost::system::error_code(), timer1 );
  onTimeout2( boost::system::error_code(), timer2 );
 
  io.run();
 
  return 0;
}
 

asio мультипоточная, когда вам надо, а когда не надо - однопоточная. :)

Ну конечно, ядро современных ОС мультипоточны, поэтому абсолютно все программы являются мультипоточными (даже Hello world) - ну ок. :)

Это человек который не знает, как работает периферия компьютера - тупой дебил. :)
Я вам уже привел пример с uart, а еще есть прерывания, зеленые треды и т.д. :)

Ну и правильно, сложно комментировать вещи о которых вы понятия не имеете. :)

Новое поколение "специалистов", которые умеют нажать кнопочку в visual studio и дождаться появления окошка со своей прикладной программой. А что там в "компьютерах" происходит между нажатием и появлением считают магией. :)

Ну хорошо, вот простейший пример
Рано или поздно я отдам упр-е и выйду в событийный цикл. По таймеру будет что-то делаться, напр читаться файл по частям. Да, в одном потоке это выполняется последовательно, обычно чередуясь с UI операциями, и что с того? Почему это нельзя считать "асинхронкой"? Упр-е возвращается сразу, блокировки нет, момент окончания задачи неизвестен. И какая мне разница "отложенный вызов" или "отложенный факт получения" ?

Ну и вообще.. неужели программистам не о чем поговорить, свалились уже в полную фигню. Грустно   :'(

Молодец, отличная аргументация :). Сам себя отмазать не может, пущай другие этим занимаются :).

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

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


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

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

С помощью ложного утверждения можно обосновать всё что угодно. Пример: утверждение «если дважды два равно пяти, то снег красный» является истинным. Парадокс импликации (https://ru.wikipedia.org/wiki/%D0%9F%D0%B0%D1%80%D0%B0%D0%B4%D0%BE%D0%BA%D1%81_%D0%B8%D0%BC%D0%BF%D0%BB%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D0%B8).

Осталось выяснить, чья исходная посылка "более правильная". Но это скорей всего скатится в вопрос веры и принятия/непринятие чужой веры. Если человек верит, что "инициация выполнения процедуры задачи происходит сразу же" (и, скорей всего в другом потоке, хотя в его же правильном отве про потоки не упоминается), то и пускай, значит в его мире такая вот асинхронность. У нас, получается, другая. Будем устраивать крестовые походы? :)


Дело тут уже не в программистах, а в человеческой натуре. Люди разные, таков наш мир :).

Я ж говорю, молодец. Сказочный :).

потому что противоречит самой идее асинхронного дизайна:
"ты делай спокойно свои дела, а когда твой заказ будет готов, мы тебе позвоним"

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

Сопрогораммы реализуются посредством тех же футур. Только вместо wait() не засыпаем на мьютексе а делаем longjump в эвентлуп. А при наступлении события делаем longjump обратно.
Мне точно надо приводить пример юзания футуры?

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

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


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

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

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

Вот и корень заблуждений).

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

Это асинхронка, а не многопоточность, Карл.
Асинхронка и многопоточность не тождественны, Карл.

Обоже.


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

Кэп, залогинься.


бла бла бла.

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

голословные "бла бла бла" - не интересны.

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

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

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

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

если это - фрагмент реального кода,
тогда почему нет полноценного примера-иллюстрации?
где хедера, функция main,
с ссылкой на онлайн компилятор?

вот так нужно грамотно оформлять пример-иллюстрацию:

https://rextester.com/VXCE86969


и сразу становится ясно и понятно, как футур используется.

теперь по аналогии приведите пример-иллюстрацию для сопрограммы.

теперь набросайте, что под капотом могу исходники boost::asio скинуть, если нужно.

что за бред?


не знаю откуда вы взягли своё "поэтому".
что за бред?


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


слишком жирно.

это ты про себя что ли?
не понятно, к чему был этот дешевый понт.

Вы их сами посмотрите. :)
А лучше скомпилируйте и посмотрите в отладчике сколько ниток запускается.

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

Вам это кажется бредом, потому что вы не знаете что там под капотом. :)

Вот и я удивляюсь, почему вы так думаете. :)

По треду уже понятно, что у вас каша в голове. :)

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

зачем же лапотать?

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

ты там выше писал:
"asio мультипоточная, когда вам надо, а когда не надо - однопоточная"

я спрашиваю: что за бред?
это никак не связанно с тем, что там у неё под капотом.



я не давал повода так думать.
ты пьяный что ли?



оно и видно.
такое впечателние, что ты пьян.


деццкий сад.

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

кстати, о вещах, в которых ты не разбираешься.

знаешь чем вообще синхронный вызов отличается от асинхронного?

Поищите в интернете про Arduino и посмотрите как там это работает. Проще этого я даже не знаю что предложить. :)
Но если не разберетесь, то приходите... будем обсуждать асинхронность. :)

я не хочу искать в интернете про Ардуино.
я хочу видеть твоё мнение.
твой пример-иллюстрацию.

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

Там же будет имитация многопоточки, это же очевидно :).

Попробую на пальцах... :)
В asio вы сами (точнее мы сами :) ) выбираем как запускать цикл обработки событий. Можем запустить io_context::run в основном потоке, можем запустить в разных, а можем даже запустить разные контексты в разных потоках.

Да ладно, это вы здесь писали, что раз ОС многопоточная, значит вся асинхронщина в ней реализуется на ней.

К сожалению нет, но тут алкоголь не поможет, здесь нужно дунуть. :)

и? какое отношение это имеет ко мне?
ты там выше вякнул, якобы я считаю, что , цитирую:
"asio мультипоточная, когда вам надо, а когда не надо - однопоточная"

вот это что за бред?
ты зачем мне приписываешь то, чего нет?


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

на людей напраслину наводишь.

А мне не хочется набирать бесполезный текст. :)
Для чего сюда тащить примеры, коих кучи в интернете. Не хотите ардуинки, наберите пример использования select/epoll.
Вот нашел для вас первый попавшийся блог с примером epoll:

C++ (Qt)
#include <stdio.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <unistd.h>
#include <fcntl.h>
#include <strings.h>
#include <string.h>
#include <arpa/inet.h>
#include <errno.h>
#include <stdlib.h>
#include <sys/epoll.h>
#include <signal.h>
#include <iostream>
 
namespace
{
 
 int setnonblocking(int sock);
 void do_read(int fd);
 void do_write(int fd);
 void process_error(int fd);
 
}
 
int main(int argc, char* argv[])
{
 const int MAX_EPOLL_EVENTS = 100;
 const int BACK_LOG = 100;
 
 if (argc < 2)
 {
  std::cout <<  "Usage: server [port]" << std::endl;
  return 0;
 }
 
 char* p;
 int serv_port = strtol(argv[1], &p, 10);
 if (*p)
 {
  std::cout << "Invalid port number" << std::endl;
  return -1;
 }
 
 // Игнорируем сигнал ошибки работы с сокетом
 signal(SIGPIPE, SIG_IGN);
 
 // Создание дескриптора epoll
 int efd = epoll_create(MAX_EPOLL_EVENTS);
 
 int listenfd;
 listenfd = socket(AF_INET, SOCK_STREAM, 0);
 if (listenfd < 0)
 {
  perror("Socket creation");
  return -1;
 }
 
 // Неблокирующий режим
 setnonblocking(listenfd);
 
 struct sockaddr_in servaddr;
 bzero(&servaddr, sizeof(servaddr));
 servaddr.sin_family = AF_INET;
 servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
 servaddr.sin_port = htons(serv_port);
 
 if (bind(listenfd, (struct sockaddr*)&servaddr, sizeof(servaddr)) < 0)
 {
  perror("Socket bind");
  return -1;
 }
 
 if (listen(listenfd, BACK_LOG) < 0)
 {
  perror("Socket listen");
  return -1;
 }
 
 // Добавляем дескриптор в массив ожидания
 struct epoll_event listenev;
 listenev.events = EPOLLIN | EPOLLPRI | EPOLLET;
 listenev.data.fd = listenfd;
 if (epoll_ctl(efd, EPOLL_CTL_ADD, listenfd, &listenev) < 0)
 {
  perror("Epoll fd add");
  return -1;
 }
 
 socklen_t client;
 // Массив готовых дескрипторов
 struct epoll_event events[MAX_EPOLL_EVENTS];
 struct epoll_event connev;
 struct sockaddr_in cliaddr;
 
 int events_cout = 1;
 
 for (;;)
 {
  // Блокирование до готовности одно или нескольких дескрипторов
  int nfds = epoll_wait(efd, events, MAX_EPOLL_EVENTS, -1);
 
  for (int n = 0; n < nfds; ++n)
  {
   // Готов слушающий дескриптор
   if (events[n].data.fd == listenfd)
   {
    client = sizeof(cliaddr);
    int connfd = accept(listenfd, (struct sockaddr*) &cliaddr, &client);
    if (connfd < 0)
    {
     perror("accept");
     continue;
    }
 
    // Недостаточно места в массиве ожидания
    if (events_cout == MAX_EPOLL_EVENTS-1)
    {
     std::cout << "Event array is full" << std::endl;
     close(connfd);
     continue;
    }
 
    // Добавление клиентского дескриптора в массив ожидания
    setnonblocking(connfd);
    connev.data.fd = connfd;
    connev.events = EPOLLIN | EPOLLOUT | EPOLLET | EPOLLRDHUP;
    if (!epoll_ctl(efd, EPOLL_CTL_ADD, connfd, &connev) < 0)
    {
     perror("Epoll fd add");
     close(connfd);
     continue;
    }
 
    ++events_cout;
   }
   // Готов клиентский дескриптор
   else
   {
    // Выполням работу с дескриптором
    int fd = events[n].data.fd;
 
    if (events[n].events & EPOLLIN)
     do_read(fd);
 
    if (events[n].events & EPOLLOUT)
     do_write(fd);
 
    if (events[n].events & EPOLLRDHUP)
     process_error(fd);
 
    // В даннoм примере дескриптор просто закрывается и удаляется из массива ожидания.
    // В зависимости от логики работы можно не удалять дескриптор и подождать следующую порцию данных
    epoll_ctl(efd, EPOLL_CTL_DEL, fd, &connev);
    --events_cout;
    close(fd);
   }
  }
 }
 
 return 0;
}
 
namespace
{
 
 int setnonblocking(int sock)
 {
  int opts;
 
  opts = fcntl(sock,F_GETFL);
  if (opts < 0)
  {
   perror("fcntl(F_GETFL)");
   return -1;
  }
  opts = (opts | O_NONBLOCK);
  if (fcntl(sock,F_SETFL,opts) < 0)
  {
   perror("fcntl(F_SETFL)");
   return -1;
  }
 
  return 0;
 }
 
 void do_read(int fd)
 {
  std::cout << "do_read" << std::endl;
 }
 
 void do_write(int fd)
 {
  std::cout << "do_write" << std::endl;
 }
 
 void process_error(int fd)
 {
  std::cout << "process_error" << std::endl;
 }
}
 

Вот функции do_read, do_write, process_error будут вызываются асинхронно.

у вас тут бизнес-логика в вечном цикле стопориться на блокирующем вызове:


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

вы так и не ответили:
вы знаете чем различаются синхронный и асинхронный вызовы?

Вы еще и читаете плохо или понимаете?
Это вы здесь утверждали, что asio исключительно мультитредовая, я вас поправил, что это не так. asio прекрасно умеет работать в одном потоке, и даже привел компилябельный пример с таймерами. :)


Так вот же:

Вы считаете системный вызов - многопоточкой. Почему, не знаю.

И здесь:

Это первый попавшийся блог. Считайте что там вместо -1 -> 0, и в цикле обрабатываются события бизнес-логики.
К демонстрации асинхронных операций чтения/записи это отношение не имеет.

Я то знаю. :)

Можно бы еще одно умное слово добавить: Concurrency, но что-то опасаюсь. Тут с двумя категориями такая буча поднялась, а с тремя комбинаторика увеличится, может переполнение стека случиться :).

я прекрасно читаю и понимаю.


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

ты русский текст что ли читать не умеешь?

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



и?
причем тут:
"Да ладно, это вы здесь писали, что раз ОС многопоточная, значит вся асинхронщина в ней реализуется на ней."
?

с чего ты взял свои "значит" ?

Ну может это поможет).
https://codewala.net/2015/07/29/concurrency-vs-multi-threading-vs-asynchronous-programming-explained/
Больше не знаю, как ещё объяснять. Да и желания нет уже.

да не похоже, что вы знаете.

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


тут одно из двух: либо нифига он не знает, либо.. он какой то неадекват.
может пьяный? а может дебил.

Как то я уже сомневаюсь в вашей адекватности. :(


Тут и про asio и про epoll.

Выше прочитайте.

Выше ваши слова про epoll. Из нее следует, что работа с epoll в одном потоке все равно является многопоточкой.

Предлагаю переименовать тему в "_Bers, это ты?"  ;)

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

Я вам уже написал, что это первый попавшийся блог. Замените -1 на 0, если знаете где, и вызов уже будет не блокирующим.
Но вы этого уже не читаете, вам сказать нечего.
Вся работа с epoll может проходить в одном потоке и быть асинхронной. А вы доказываете, что это не возможно. :)

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

А на счет переименования темы - я за. :)

Или уведомлять eпулл через eventfd о других событиях и таки ждать=)

Вот вам:  ;D

да мне пофигу твои сомнения.
где пруф?
почему не приводишь?

стало быть, ты балаболка?


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

из моих слов следует, что под капотом epoll многопоточка.

специально для тех кто в танке:
твоё приложение может быть однопоточным.
система многопоточная.
на уровне ядра системы - многопоточность во все поля.

Так под этим моим предложение как раз ваши цитаты находятся. :)

Ага, значит пример с epoll - асинхронка.
А теперь замените epoll на проверку регистра с данными от uart и вызовом функции обработки при наличии, которое выполняется на микроконтроллере без ОС. Это уже будет не асинхронка?

я ничего тебе не доказываю (нафиг ты мне нужен)

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

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

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