AlexBoss, если ваш код на питоне выполняет множество вычислений ( майнит биткоины, поворачивает изображения, в общем делает что-то тяжелое это вычислительная задача.
Отвечать же на запросы по сети данными из базы можно почти без вычислений, тут сплошные блокирующие операции которые будут выполняется вне питона.
Парсинг файлов например будет легко читать сразу множество файлов но когда дойдет до собственно анализа данных тут разные потоки начнут друг друга блокировать.
В общем если у вас в коде есть нечто что работает с файлами и именно эта рабобта с файлами требует основного времени ( а сокеты это тоже файлы ) то многопоточность должна помочь.
Нет, Qt это не обычный c++ это надстройка над си++. Без своего прекомпилятора им пользоваться нельзя. Signal/Slot ущербны, и это легко проверить - попробуйте написать любую ерунду в теле макросов SIGNAL SLOT и убедитесь в этом сами. Нет никакой проверки при компиляции того что вы там написали. Потому что все что приходит в тело этих макросов потом заменяется кьютишным прекомпилятором на вызовы функций на основе строк. Увы если такой строки не найдется ( читай пытаемся соединить сигнал с несуществующим слотом ) ни Кьюти ни компилятор нам ничего не скажут. Ищи потом баг в рантайме.
В чем же такое великое приемущество QMap над std::map?
coodan: Таких кратких и длинных сводов полно на самом деле. Каждая компания пишущая на плюсах создает свой ( ну или берет один из популярных, гугла например ).
Плюс в хороших книгах по плюсам обычно расписаны не очень удачные решения которых следует избегать.
Очень распространенное заблуждение что если обернуть все поля класса в методы get/set то у нас сразу же все будет красиво и инкапсулировано. Фигня это.
Вот например делаю я класс для работы с файлом:
Инкапсуляция? Вроде да, ведь есть get/set но самом деле это типичная дырявая абстракция которая ничего не инкапсулирует.
Уж скорее инкапсуляцией можно назвать скрытие реализации за интерфейсом. Причем такое скрытие которое не позволит внутренней кухне реализации выскользнуть за границы интерфейса.
В вашем случае совершенно не важно что вы возвращаете, так как это значение не используется. Чтобы оно использовалось - нужно передать указатель на него вторым параметров в функцию создания потока: stackoverflow.com/questions/25417820/pthread-exit-...
Поэтому если вы хотели чтобы поток изменил основную переменную, из тела функции main нужно было передать в функцию указатель на указатель на эту переменную.
Blunker: Упростите себе задачу. Уберите потоки для начала и убедитесь что ваша функция без них работает правильно. Только после этого снова вводите потоки ( можно по одному ).
Почитать посоветую Effective C++ Меерса. Разжевывает многие аспекты языка, к тому же формулировка в виде задач побуждает к собственным попыткам разобраться.
Думаю не лучше, так как компилятор должен сам понимать что в данном случае временно значение без надобности и оптимизировать код. Имхо имеет смысл задумываться над префиксным-постфиксной записью именно там где она нужна: когда нужно вернуть старый объект при увеличении счетчика.
В двухтысячных тоже самое говори про Java. И что? Да она занимает прочное место на рынке, но потребность в других ЯП никуда не делась. Да и вообще - говорить что будет нужно что-то одно означает лишь что под этим подразумевается серебряная пуля, который как известно не существует.
tsarevfs: Речи об обратной польской записи в вопросе не шло. Нужно лишь решить функцию. То есть по сути обработать выражение a+b*c-d/e.... ну еще возможные скобки. Где тут сложности парсинга? Читаем число, читаем операцию, и тд. Потом разбираемся с приоритетами. Потом добавить рекурсивные скобки. Задача решена. Да чуть сложнее поиска по массиву. Но один фиг человек сам даже не приступил к решению.
Задал бы он вопрос "решаю задачу, в этом месте лажа в коде/алгоритме" было бы совсем другое дело. А так "я ничего не понимаю - покажите мне как это делать". Печально.
Рекомендую не создавать своих протоколов а воспользоваться уже готовыми. А еще лучше найти готовый код который уберет от вас все ( или большинство ) сложностей ручной работы с сокетами. Разве что если вам это нужно для обучения - тогда конечно пишите все сами.
Советую взять одну из библиотек для работы с xmpp и реализовать чат поверх него. Тогда у вас будет готовая авторизация, списки контактов, их состояния, комнаты. Да и работать с этим будет куда проще чем отправляя сообщение в голый сокет. Посмотрите например на strophe.im/libstrophe или на camaya.net/gloox
Зы. тут вам уже посоветовали использовать Mq, но имхо мое предложение должно подойти лучше, как протокол созданный специально для чатов.
msdn если вы пишите только под винду. Если же подразумеваются другие платформы - одна или несколько сразу лучше искать кросс-платформенные библиотеки. Начать лучше с stl так как он есть везде.
Отвечать же на запросы по сети данными из базы можно почти без вычислений, тут сплошные блокирующие операции которые будут выполняется вне питона.
Парсинг файлов например будет легко читать сразу множество файлов но когда дойдет до собственно анализа данных тут разные потоки начнут друг друга блокировать.
В общем если у вас в коде есть нечто что работает с файлами и именно эта рабобта с файлами требует основного времени ( а сокеты это тоже файлы ) то многопоточность должна помочь.