Простота, кроссплатформенность, не нужно тянуть тяжелые либы типа Boost-а или Qt.
Никто не мешает попробовать разные потоки и понять, что больше подходит тебе для твоей задачи. Сделаешь один класс-обертку, а что уж внутри него - дело десятое, сможешь с ним играться сколько влезет. На других частях программы это не должно сказаться вообще никак.
Позволю себе добавить, что выбор Qt решает не только проблему с использованием потоков, но и добавляет к ней отличнейшее средство межпоточного взаимодействия в виде сигналов/слотов.
std::thread ибо стандарт (в C++11 еще и лямбды умеет), очень удобно сделан класс QThread в Qt. Если нужен параллелизм, то можно взглянуть на C++ Actor Framework (CAF), сложно и монструозно, но работает.
Использовал livev в одном из своих проектов. Показал себя просто отлично. А вообще для многопоточности сейчас лучше go заюзать. Я так и сделаю как только в проекте понадобиться.
Кстати, что там не так? Как оно работает? Разве это не засахареный способо регистрировать коллбеки?
Именно он. Просто преподносить его как единственное средство IPC явно не стоит. Использование с/с как IPC очень часто приводит к аццким багам (в основном из-за потери контекста сообщения за время доставки), а те, кто это пишут, как правило слишком увлечены простотой идеи, чтобы замечать общую опасность подхода.
Сабж потокобезопасен, если грамотно использовать, можно очень хороших результатов добиться.
Если «грамотно использовать», то добиться результатов можно везде. А потокобезопасность сомнительна, т.к. данные всё равно как-то приходится шарить между потоками.
А потокобезопасность сомнительна, т.к. данные всё равно как-то приходится шарить между потоками.
У Qt половина тулкита потокобезопасна это раз. Передавать данные между потоками бывает требуется только на чтение это два. Ну и необходимость понимания происходящего не отменял никто (и я того не говорил) это три. Факта потокобезопасности сигнал-слота из Qt всё это никак не отменяет. Факт передачи по queued или default соединению сам по себе никак и ничего сломать не может. ЗЫ сломать можно всё и в одном потоке, делаем queued соединение, шлём указатель на объект в стеке, ловим веселый сегфолт, это таки кресты, жабофилам и прочим сеньёрам такое не осилить.
Ну если мозгов осилить работу с памятью не хватает (а что там сложного я никак не пойму) без GC никак, будет тупить, пердеть, жрать память аки «не в себя» но ворочаться как и вообще всё написанное на всяких ваших жабах...
Раааз. Передал один ссылку на COW-вектор, а пока сообщение шло в другой поток, вектор тупо удалили. Спасла тебя потокобезопасность вектора? в С++11 весь STL в плане const методов потокобезопасен - и чо?
Ну и необходимость понимания происходящего не отменял никто (и я того не говорил) это три.
За этой отмазкой прячется всегда говнодизайн. Тупые программисты в проекте всегда будут и не всегда их код будет нормально ревьюится. Твое мнение диванного теоретика про идеальный случай оставь себе. Дизайн приложения не должен позволять легко ошибиться, даже ламеру. Иначе это говнодизайн.
Факта потокобезопасности сигнал-слота из Qt всё это никак не отменяет. Факт передачи по queued или default соединению сам по себе никак и ничего сломать не может.
От этого факта в вакууме ни холодно ни жарко.
ЗЫ сломать можно всё и в одном потоке, делаем queued соединение, шлём указатель на объект в стеке, ловим веселый сегфолт, это таки кресты, жабофилам и прочим сеньёрам такое не осилить.
Аргумент на уровне детсада. «А я могу себе х@й прострелить!»
Ну если мозгов осилить работу с памятью не хватает (а что там сложного я никак не пойму)
Ты у нас настолько идеален, что никогда не ошибаешься? Рассказывай.
Забатхёртило твои влажные фантазии, у меня тут полный порядок.
Раааз. Передал один ссылку на COW-вектор, а пока сообщение шло в другой поток, вектор тупо удалили.
Не умеешь работать с памятью, убери свои кривые лапки от крестов жабофил!
За этой отмазкой прячется всегда говнодизайн. Тупые программисты в проекте всегда будут и не всегда их код будет нормально ревьюится. ... Дизайн приложения не должен позволять легко ошибиться, даже ламеру. Иначе это говнодизайн.
С кодом должны работать профессионалы, а иначе что не городи будет всё плохо. Хороший дизайн позволяет исключить некоторый возможный геморрой, обеспечить быстрое и лёгкое включение в разработку, разбить разработку на части, модифицировать и поддерживать минимальными трудозатратами и не должен содержать не очевидных «подводных камней».
Твое мнение диванного теоретика про идеальный случай оставь себе.
Это позволяет сократить кол-во кода и естественным путем делает его более наглядным.
Аргумент на уровне детсада. «А я могу себе х@й прострелить!»
На твой «х подстрелить» и отвечено как противовес. Сути ты не ловишь, твои самострелы делаются и в одном потоке, особенность ЯП такая. Тут мозг применять надо, а не аки Обама с гранатой по клаве молотить...
Ты у нас настолько идеален, что никогда не ошибаешься? Рассказывай.
Ничего подобного, большинство ошибок правда очепятки и синтаксические, иногда по запаре и что похуже. Но жопа у меня не болит, в отличии от. А GC не жрёт ресурсы. Я счастлив.
ЧСВ, такое ЧСВ, это было обращение к собирательному образу, (девиз, лозунг или как-то так).
Пока, диванный теоретик. Ждем, пока ты устроишься на работу и узнаешь правду.
Давай, давай, ванга-неоудачник. Устройство на работу уже давно пережитый и преодолённый этап моей жизни. По себе судить окружающих - удел неудачников и школьничков. Первым уже не поможешь, вторые бывает вырастают. Надеюсь у тебя пройдёт. ЗЫ заодно может глянешь как-то однажды что такое IPC на педивикии :D
Давай, съезжай на личности дальше. Я достаточно натрахался с быдлокодом любителей сигналов в другие потоки, чтобы не считать 1. мир идеальным, а разработчиков поголовно квалифицированными, 2. дизайн взаимодействия потоков, основанный на сигналах, дубово-качественным.
ЗЫ заодно может глянешь как-то однажды что такое IPC на педивикии :D
А без придалбывания к словам? Ну замени sed'ом «IPC» на «взаимодействие потоков», если ты это по контексту не допёр.
Сказал персонаж, и начавший сей процесс :D Есть что сказать, говори по делу.
Я достаточно натрахался с быдлокодом любителей сигналов в другие потоки, чтобы не считать 1. мир идеальным, а разработчиков поголовно квалифицированными, 2. дизайн взаимодействия потоков, основанный на сигналах, дубово-качественным.
Я достаточно натрахался с быдлокодом как таковым и поработал с кодом на целой прорве разных языков (от ковыряния в чужом и хорошем коде, и в говнокоде, до проектирования и реализации проектов своими руками), чтобы 1 не считать что выбор инструмента (ЯП, тулкида, парадигмы, патернов и т.д.) может как-то повлиять на качество работы быдлокодера 2 не считать вообще хоть что-то дубовым и не ломаемым кривыми ручками 3 не считать проектирование менее или более важным чем качество реализации. ЗЫ И достаточно опытный специалист чтобы понимать, что создать качественный код можно только руками хороших спецов и что его создать таки можно. Если в проекте затесался говнокод вопрос к тому, кто набирает кадры или код принимает в проект (зависит от способа разработки).
А без придалбывания к словам?
А без влажных фантазий о собеседнике в неизвестном конце глобальной сети?
Если в проекте затесался говнокод вопрос к тому, кто набирает кадры или код принимает в проект (зависит от способа разработки).
Таких проектов куча. В моем случае это легаси + пачка быдлокодеров со стороны заказчика, которых по этой причине не уволить. Вопросы задавать круто, но на код это не повлияет и с ним надо работать. Взять и переписать нереально, можно только материться и дебажить бесконечные рейсы и дедлоки.
не считать что выбор инструмента (ЯП, тулкида, парадигмы, патернов и т.д.) может как-то повлиять на качество работы быдлокодера
не считать проектирование менее или более важным чем качество реализации.
Грамотное проектирование может очень усложнить написание бажного кода. Четкое прописывание формы и интерфейса взаимодействия потоков - как раз главный пример этого. И это проектирование, а не детали реализации.
Таких проектов куча. В моем случае это легаси + пачка быдлокодеров со стороны заказчика, которых по этой причине не уволить. Вопросы задавать круто, но на код это не повлияет и с ним надо работать. Взять и переписать нереально, можно только материться и дебажить бесконечные рейсы и дедлоки.
Такова наша жизнь. Мне тоже приходиться в куче какашек барахтаться. Но первопричина как была так и есть быдлокодеры.
Грамотное проектирование может очень усложнить написание бажного кода. Четкое прописывание формы и интерфейса взаимодействия потоков - как раз главный пример этого. И это проектирование, а не детали реализации.
Усложнит, но не избавит - раз. Нагромождение защиты от самострелов даёт накладники - два.
Будь то GC, хитрый тулкит или ещё что, один хрен слишком много накладников и всё равно говнокод (и как правило качество кода только падает тем сильнее чем больше защиты от дурака и не важно на каком уровне защита, если это не отдел кадров). Хороший дизайн и правильный инструментарий помогут всё сделать хорошо, но только помогут, а не обеспечат. К сожалению, приходится сталкиваться с говнокодом из разных источников. И повлиять нету возможности ни на качество реализации, ни на качество проектирования, ни на правильный выбор инструментария. Ковырял я говнокод написанный и на C/C++, и на Qt, и STL, и на дикой каше из разношёрстных либ, и на С#, и жабе, и на CMD и shell script. И были там вещи загнанные в состояние УГ ещё на этапе проектирования и с хорошим изначально дизайном. И писал я и на STL, и на Qt, и на жабе, шарпе, шелле и прочем, прочем, прочем. Могу сказать, что правильные спецы могут делать как минимум сносно с любым инструментарием, но лучше если полагаться не на защиты от дураков, а мозг, как на этапе проектирования так и реализации. Эффективен лишь отсев дебилов, остальное не спасает. А ссылки на сторонний код лишь пустозвонство, наворотят говно из чего угодно и чем угодно и тут ты не повлияешь никак всё равно.