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

Больше всего радует когда пишут для дебагера, ну так сразу чтоб уйти в глубокую отладку своего говнокода :D ЗЫ на своих проектах пользовал профайлеры, полезная штука. А вот дебагер как-то не пригождался, даже освоить никак не выходит без реальной практики, только теория. Если ошибка не в ДНК (того кто реализовывал и/или проектировал) её легко найти внимательным осмотром кода.

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

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

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

Что никак не противоречит использованию сигнал-слота в Qt... не так ли?

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

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

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

ACE

на ваш взгляд

то есть, критерии пусть будут вашими

C++ Actor Framework (CAF)

ух, ни разу про это не слышшал, надо будет ознакомиться

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

shared_ptr не предлагать

почему?

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

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

«системой, которой сможет пользоваться каждый идиот, только идиот и будет пользоваться»

из-за проблем с мутексами

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

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

запустить евентлуп, не?

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

как бы да... просто есть нюанс

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

обертки мютексов

имею ввиду lock / unlock. Допускаю, что конструктор вполне вóлен кинуть. плохо от этого не будет.

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

А если ты имеешь в виду в области, закрытые мютексом, то для этого RAII есть.

вот как раз RAII тут не в кассу

да, имел в виду области кода, закрытые мутексом

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

ну хз. Что видел, про то и говорю.

Мне Qt только чтоб временные киенты делать с кнопочками и графиками. Процентов 5 наверно только пользую от всего.

факт нелюбви кутевцев к экзепшенам

Лично я их вообще не люблю и без Qt, и жабу из-за них в частности.

За что люблю цитаты, так это за то, что под любую ситуацию для любой из сторон можно найти цитату.

Если на этих стеках только POD-ы, можно грохнуть целиком (запомнить один адрес несколько проще, не правда ли?). Если нет, можно раскрутить стек.

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

еще futex посоветуй

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

Зачем двигать? Запустить. (это разные вещи, можно и двигать...)

в qt есть божественный qmutexlocker, который будет разрушен вместе с остальным стеком, заодно освободив мутекс.

тред не читай?

вижу сообщение - отвечаю на него.

problems?

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

тред не читай...

многопоточность - миф

и вы нам сейчас его развенчаете

GCD

Кстати std::thread сейчас использует pthreads в gcc как бекенд (линковать надо -lpthread)

std::thread (нативная, кроссплатформенная), Qt (высокоуровневая, кроссплатформенная), OpenMP

не для всех уровней абстракций

так какая из них лучшая? (для ваших целей и почему)

me практически не использовал многопоточность на С++.

Сложно сказать, что лучше: додж чарджер 70г.в., ока, или белаз.
Ясно, что использовать Qt целесообразно в Qt приложении. std::thread это так сказать must have, ибо нативная возможность языка. Появился недавно (C++11) потому кода с ним в продакшене не так много, сейчас хотя набирает обороты.
OpenMP очень мощная либа с большим количеством фич, довольно популярная в продакшене, хорошей документацией. Низкоуровневая, что позволяет активно использовать в системном программировании. Для gcc не требует сторонних либ, все компилируется только с добавлением опции компилятору. Мне, лично, по душе описывать многопоточный код директивам: нужен код для многопоточности — взял в блок, описал директивами. Удобно. Довольно сложная, требует знать матчасть многопоточного программирования (мьютексы, семафоры,etc).
Так что выбор субъективен, и эквивалентен выбору твоего дистрибутива.
//P.S еще есть boost. Но благодаря std:thread им можно пренебречь.

Если же говорить о себе, то я чаще всего использовал Qt-шные потоки, ибо чаще всего многопоточность нужна именно в Qt приложении с формачками и прочими гуевинами.
несколько раз использовал OpenMP для параллельных вычислений.
С выходом 11-го стандарта потыкал std::thread, и понял что на приклодном уровне его оченб даже не плохо использовать.
Но чаще всего, я конечно реализую Runnable, чуть реже наследуюсь от Thread :)

чуть реже наследуюсь от Thread :)

в смысле, от QThread, ну я понял.

ок, спасибо

в смысле, от QThread, ну я понял.

Нет, именно от Thread. Тонкий намек, на более частое использование многопоточности мною в java, чем в с++ :)

ясн)