-
Greetings. Now, like others, I plan to have a list active connections.
Like others, I ran into the copying problem. To prevent the socket from being copied, I can use a unique_ptr. The problem is, I cannot figure out how to make this work with an std::pair. It needs to be constructed by either moving or copying, and I cannot do either. Currently I was attempting this:
sockets.push_back(std::make_unique<std::pair<sf::TcpSocket, std::mutex>>(sf::TcpSocket(), std::mutex()));
The mutex was my attempt at making it threadsafe. I plan to, for each client, have a blocking receiver in it's own thread. While this is going on, whenever I want to send a message, I would do it via the same connection. I don't know whether or not that works at the same time.
-
Why are you dynamically pairing sockets with mutexes?
-
Why are you dynamically pairing sockets with mutexes?
Why dynamic, or why mutexes? I think I explained why mutexes. As far as dynamic, I don't know how many connections there will be - unlimited, theoretically. Predefined seems rather rigid and more problematic.
-
I understand the need for dynamic sockets, just not paired mutexes. It sounds like a lot of unneeded work. Just have one mutex lock down the resources so the clients accessing them won't corrupt them.
-
I understand the need for dynamic sockets, just not paired mutexes. It sounds like a lot of unneeded work. Just have one mutex lock down the resources so the clients accessing them won't corrupt them.
Imagine there are 100 or more connections. Wouldn't all the waiting start to impact response times? If we are talking about every send and receive. Although I am not certain how this will work if the socket is blocking, unless receive is safe.
-
I suppose you would know better than me.
Try this...
std::list< std::unique_ptr< std::pair<sf::TcpSocket*, sf::Mutex*> > > list;
list.push_back(std::unique_ptr< std::pair<sf::TcpSocket*, sf::Mutex*> >(new std::pair<sf::TcpSocket*, sf::Mutex*>(new sf::TcpSocket, new sf::Mutex)));
-
Omega, the whole point of std::unique_ptr is to avoid manual memory management...
The problem with
sockets.push_back(
std::make_unique<std::pair<sf::TcpSocket, std::mutex>>(sf::TcpSocket(), std::mutex()));
is, apart from being far too convoluted, that you attempt to move/copy-construct the socket and mutex.
What you should do instead, is default-construct:
typedef std::pair<sf::TcpSocket, std::mutex> Pair;
std::list<std::unique_ptr<Pair>> list;
list.push_back(std::make_unique<Pair>());
-
Makes sense. I don't often work with std::pair or std::unique_ptr, plus I'm still using VS2010, so I don't have std::make_unique. The way I offered works, but obviously not in the way intended. But I will remember this for future reference. +1.
-
Instead of
std::make_unique<Pair>()
you can also use std::unique_ptr<Pair>(new Pair())