recv и send ты проверяешь ведь по всем правилам?Откуда вдруг взялась "минимальная допустимость"
противоречит "минимальной допустимости"
не интересуюсь разработкой игр, как способом заработать деньги
Пока не рассматриваю разработку игр, как работу в будущем
Main? Для тебя ведь прозрачно что память, в которой этот экземпляр живет, имеет больший или равный размер, чем требует тип Main? а создавать отдельные потоки на каждую виртуальную машину не является оптимальным и только хуже должно сказаться на производительности.
operator >> читает раздельно по словам. И запись каждого слова ты завершаешь с помощью std::endl.void physicalObject::update() {
// Обновление положений
for (int i = 0; i < thrusterMount.size(); i++) {
thrusterMount[i].update(*this, position);
}
}thrusterMount::update должным образом.thrusterMount::update связь с владеющим объектом physicalObject.class thrusterMount {
public:
const physicalObject* host_object = nullptr;
sf::Vector3f position;
void update(sf::Vector3f objectPosition);
};
На борту у тебя Intel® Xeon® Processor E5430, на кристалле которого разведено 4 ядра без HT.
В самом буквальном смысле, это означает что без взаимных блокировок и группировки в очереди в твоем процессе сможет работать не больше четырех потоков.
Если ты сделаешь больше 4х потоков, то они начнут вытеснять друг друга с занимаемых ядер и уходить в ожидание исполнения. Таким образом производительность ты для себя только снижаешь.
А при большом увеличении количества потоков их часть и вовсе не сможет выбраться из очереди ожидания исполнения. Собственно, это то, что ты и наблюдаешь.
Тебе, опираясь на значение
hardware_concurrency, стоит задавать не больше достаточного количества потоков в пуле, аффинировав[W][L] каждый поток конкретному ядру процессора, чтобы они не скакали, чтобы на ядрах не было переключения контекстов.В этом, собственно, заключается базовая суть пула потоков.