Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - snooc

Pages: [1]
1
General discussions / Re: Portability Verion 1.6 to 2.0
« on: February 03, 2013, 03:24:08 pm »
Oh sorry, I didn't had my coffee at that minute so I didn't realized your answer :D

I just came to another thing (I don't want to start a new thread on this one).. I decided to use v2.0 so I don't have to port the whole thing later on.. Since my project is just at the beginning phase this isn't such big a deal.

Well... I saw that Socket::close() is now a protected member which leads me to the question how the connection is closed if I didn't derived e.g. UdpSocket, instead, using this as a member. I guess, that Socket::close() is called in the destructor, isn't it? If so, you might should add a line to the documentation but anyway.. how am I supposed to close an UdpSocket now?

/**
 * Destructor
 */

AcceptUDPConnectionThread::~AcceptUDPConnectionThread()
{
  if(m_udpSocket) {
    m_udpSocket->close(); // called in Socket::~Socket() ?
    delete m_udpSocket;
    m_udpSocket = 0;
  }
}
 

2
General discussions / Re: Portability Verion 1.6 to 2.0
« on: February 03, 2013, 12:08:02 pm »
Okay I see, so I will have to consider some changes but as far as I can see they will be managable (speaking for the network part). :)

What is about the other thing with the error handling with sockets?

SocketTCP::Accept() returns either sf::Socket::Done, sf::Socket::Error, sf::Socket::Disconnected or sf::Socket::NotReady but is there any way to specify the kind of error that occurs? Today I started a server that worked for a while (as I was programing). After two hours all of a sudden the Accept()-function returned sf::Socket::Error and I couldn't find out what the reason was for this. After rebooting my machine it worked again.. maybe it was my fault anyway.. but still.. it would be useful if there was an error specification for things like that (if that's even possible).

I am not sure if is even possible to go far deeper into error response on this one.. but it would be great if there was something like sf::Socket::getLastError : std::string or something near it.

3
General discussions / Portability Verion 1.6 to 2.0
« on: February 03, 2013, 03:44:20 am »
Well.. my question is pretty short.. :)

Will it be possible to easily update the library from v1.6 to v2.0?
I am asking especially after the network part I am using in a project right now.

And here is another little thing I'd like to ask..

SocketTCP::Accept() returns either sf::Socket::Done, sf::Socket::Error, sf::Socket::Disconnected or sf::Socket::NotReady but is there any way to specify the kind of error that occurs? Today I started a server that worked for a while (as I was programing). After two hours all of a sudden the Accept()-function returned sf::Socket::Error and I couldn't find out what the reason was for this. After rebooting my machine it worked again.. maybe it was my fault anyway.. but still.. it would be useful if there was an error specification for things like that (if that's even possible).

Best regards - and thank you that I may use your library :)

Pages: [1]
anything