LINUX.ORG.RU

Ответ на: комментарий от next_time

Кроссплатформенность наверное

anonymous
()
Ответ на: комментарий от next_time

Какая библиотека для обеспечения многопоточности в С++ лучшая, на ваш взгляд?

Qt.

хочется получить развёрнутый ответ.

Знакома лучше всех, не мало практики с ней, кроссплатформенно.

erfea ★★★★★
()
Ответ на: комментарий от next_time

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

happycorsair
()

Что есть лучше?

Я пользовался и Qt, и boost, и std, и pthread. Все они хорошие. Такты не считал.

staseg ★★★★★
()
Ответ на: комментарий от erfea

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

g0t0
()

std::thread ибо стандарт (в C++11 еще и лямбды умеет), очень удобно сделан класс QThread в Qt. Если нужен параллелизм, то можно взглянуть на C++ Actor Framework (CAF), сложно и монструозно, но работает.

NegatiV
()

Всё зависит от задачи, где-то и OpenMP будет достаточно.

AlexVR ★★★★★
()

Использовал livev в одном из своих проектов. Показал себя просто отлично. А вообще для многопоточности сейчас лучше go заюзать. Я так и сделаю как только в проекте понадобиться.

deterok ★★★★★
()
Ответ на: комментарий от Pavval

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

erfea ★★★★★
()
Ответ на: комментарий от g0t0

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

erfea ★★★★★
()
Ответ на: комментарий от Pavval

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

vertexua ★★★★★
()
Ответ на: комментарий от erfea

Контейнеры с copy-on-write вообще замечательны и намного удобнее в работе, чем контейнеры из std::

Ну и все остальное тоже очень даже кул.

g0t0
()
Ответ на: комментарий от g0t0

Я вот тоже прям дождаться не могу, когда он уже начнёт жечь глаголом...

erfea ★★★★★
()
Ответ на: комментарий от vertexua

Кстати, что там не так? Как оно работает? Разве это не засахареный способо регистрировать коллбеки?

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

Pavval ★★★★★
()
Ответ на: комментарий от erfea

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

Если «грамотно использовать», то добиться результатов можно везде. А потокобезопасность сомнительна, т.к. данные всё равно как-то приходится шарить между потоками.

Pavval ★★★★★
()
Ответ на: комментарий от vertexua

Не помешала бы иммутабельная паранойя

И GC, чего уж там. Чтобы данные проживали время передачи сообщения (shared_ptr не предлагать).

Pavval ★★★★★
()
Последнее исправление: Pavval (всего исправлений: 1)
Ответ на: комментарий от Pavval

Использование с/с как IPC...

Ууу, всё ясно. Ваше мнение самое важное для нас!

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

У Qt половина тулкита потокобезопасна это раз. Передавать данные между потоками бывает требуется только на чтение это два. Ну и необходимость понимания происходящего не отменял никто (и я того не говорил) это три. Факта потокобезопасности сигнал-слота из Qt всё это никак не отменяет. Факт передачи по queued или default соединению сам по себе никак и ничего сломать не может. ЗЫ сломать можно всё и в одном потоке, делаем queued соединение, шлём указатель на объект в стеке, ловим веселый сегфолт, это таки кресты, жабофилам и прочим сеньёрам такое не осилить.

erfea ★★★★★
()
Ответ на: комментарий от Pavval

И GC, чего уж там.

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

erfea ★★★★★
()
Ответ на: комментарий от erfea

Что ж тебя так забаттхертило-то?

У Qt половина тулкита потокобезопасна это раз.

Раааз. Передал один ссылку на COW-вектор, а пока сообщение шло в другой поток, вектор тупо удалили. Спасла тебя потокобезопасность вектора? в С++11 весь STL в плане const методов потокобезопасен - и чо?

Ну и необходимость понимания происходящего не отменял никто (и я того не говорил) это три.

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

Факта потокобезопасности сигнал-слота из Qt всё это никак не отменяет. Факт передачи по queued или default соединению сам по себе никак и ничего сломать не может.

От этого факта в вакууме ни холодно ни жарко.

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

Аргумент на уровне детсада. «А я могу себе х@й прострелить!»

Ну если мозгов осилить работу с памятью не хватает (а что там сложного я никак не пойму)

Ты у нас настолько идеален, что никогда не ошибаешься? Рассказывай.

Pavval ★★★★★
()
Ответ на: комментарий от Pavval

в основном из-за потери контекста сообщения за время доставки

1. Положить конекст на стек

2. Стек переключать

3. ....

4. PROFIT

anonymous
()
Ответ на: комментарий от Pavval

И GC, чего уж там. Чтобы данные проживали время передачи сообщения (shared_ptr не предлагать).

Аналогично моему предыдущему комментарию.

anonymous
()
Ответ на: комментарий от Pavval

Что ж тебя так забаттхертило-то?

Забатхёртило твои влажные фантазии, у меня тут полный порядок.

Раааз. Передал один ссылку на COW-вектор, а пока сообщение шло в другой поток, вектор тупо удалили.

Не умеешь работать с памятью, убери свои кривые лапки от крестов жабофил!

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

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

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

Сказал профессор, не знающий даже что такое IPC! :D

От этого факта в вакууме ни холодно ни жарко.

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

Аргумент на уровне детсада. «А я могу себе х@й прострелить!»

На твой «х подстрелить» и отвечено как противовес. Сути ты не ловишь, твои самострелы делаются и в одном потоке, особенность ЯП такая. Тут мозг применять надо, а не аки Обама с гранатой по клаве молотить...

Ты у нас настолько идеален, что никогда не ошибаешься? Рассказывай.

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

erfea ★★★★★
()

Лучше пиши на С#, там с потоками всё отлично.

flareguner
()
Ответ на: комментарий от erfea

Не умеешь работать с памятью, убери свои кривые лапки от крестов жабофил!

Мимо кассы два раза.

С кодом должны работать профессионалы

Пока, диванный теоретик. Ждем, пока ты устроишься на работу и узнаешь правду.

Pavval ★★★★★
()
Ответ на: комментарий от Pavval

Мимо кассы два раза.

ЧСВ, такое ЧСВ, это было обращение к собирательному образу, (девиз, лозунг или как-то так).

Пока, диванный теоретик. Ждем, пока ты устроишься на работу и узнаешь правду.

Давай, давай, ванга-неоудачник. Устройство на работу уже давно пережитый и преодолённый этап моей жизни. По себе судить окружающих - удел неудачников и школьничков. Первым уже не поможешь, вторые бывает вырастают. Надеюсь у тебя пройдёт. ЗЫ заодно может глянешь как-то однажды что такое IPC на педивикии :D

erfea ★★★★★
()
Последнее исправление: erfea (всего исправлений: 2)
Ответ на: комментарий от erfea

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

ЗЫ заодно может глянешь как-то однажды что такое IPC на педивикии :D

А без придалбывания к словам? Ну замени sed'ом «IPC» на «взаимодействие потоков», если ты это по контексту не допёр.

Pavval ★★★★★
()
Ответ на: комментарий от Pavval

Они на то и потоки, что им IPC нафиг не нужен. Ты википедию так и не открыл поди?

nanoolinux ★★★★
()
Ответ на: комментарий от Pavval

Давай, съезжай на личности дальше.

Сказал персонаж, и начавший сей процесс :D Есть что сказать, говори по делу.

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

Я достаточно натрахался с быдлокодом как таковым и поработал с кодом на целой прорве разных языков (от ковыряния в чужом и хорошем коде, и в говнокоде, до проектирования и реализации проектов своими руками), чтобы 1 не считать что выбор инструмента (ЯП, тулкида, парадигмы, патернов и т.д.) может как-то повлиять на качество работы быдлокодера 2 не считать вообще хоть что-то дубовым и не ломаемым кривыми ручками 3 не считать проектирование менее или более важным чем качество реализации. ЗЫ И достаточно опытный специалист чтобы понимать, что создать качественный код можно только руками хороших спецов и что его создать таки можно. Если в проекте затесался говнокод вопрос к тому, кто набирает кадры или код принимает в проект (зависит от способа разработки).

А без придалбывания к словам?

А без влажных фантазий о собеседнике в неизвестном конце глобальной сети?

erfea ★★★★★
()
Ответ на: комментарий от erfea

Если в проекте затесался говнокод вопрос к тому, кто набирает кадры или код принимает в проект (зависит от способа разработки).

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

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

не считать проектирование менее или более важным чем качество реализации.

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

Pavval ★★★★★
()
Ответ на: комментарий от Pavval

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

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

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

Усложнит, но не избавит - раз. Нагромождение защиты от самострелов даёт накладники - два.

Будь то GC, хитрый тулкит или ещё что, один хрен слишком много накладников и всё равно говнокод (и как правило качество кода только падает тем сильнее чем больше защиты от дурака и не важно на каком уровне защита, если это не отдел кадров). Хороший дизайн и правильный инструментарий помогут всё сделать хорошо, но только помогут, а не обеспечат. К сожалению, приходится сталкиваться с говнокодом из разных источников. И повлиять нету возможности ни на качество реализации, ни на качество проектирования, ни на правильный выбор инструментария. Ковырял я говнокод написанный и на C/C++, и на Qt, и STL, и на дикой каше из разношёрстных либ, и на С#, и жабе, и на CMD и shell script. И были там вещи загнанные в состояние УГ ещё на этапе проектирования и с хорошим изначально дизайном. И писал я и на STL, и на Qt, и на жабе, шарпе, шелле и прочем, прочем, прочем. Могу сказать, что правильные спецы могут делать как минимум сносно с любым инструментарием, но лучше если полагаться не на защиты от дураков, а мозг, как на этапе проектирования так и реализации. Эффективен лишь отсев дебилов, остальное не спасает. А ссылки на сторонний код лишь пустозвонство, наворотят говно из чего угодно и чем угодно и тут ты не повлияешь никак всё равно.

erfea ★★★★★
()
Ответ на: комментарий от erfea

Усложнит, но не избавит - раз.

Конечно.

Нагромождение защиты от самострелов даёт накладники - два.

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

Pavval ★★★★★
()

Раньше была tbb, сейчас не знаю.

amaora ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.