Portability Verion 1.6 to 2.0

[snooc]

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

[Lo-X]

I'll answer about the version part (since I never used the network part for anything else than tests)

There is a lot of difference between 1.6 and 2.0 in the API. Indeed the naming convention passed from MyClass::MyMethod() to MyClass::myMethod() [so from CamelCase to camelCase]. That's a lot of work if you have a lot of code to change (or some reflexion with a good "search and replace" regex with your IDE)

Furthermore the APIcontent changed too. Some classes are gone, there are new classes, and some classes have new functionalities or removed one. The only way to checkall that is to go to the documentation.

Note that the network part hasn't changed (if I'm not mistaken), in anything else than the camelCase renaming (so you can adapt your code pretty fast).

[Laurent]

It's wrong, the network part has changed too
Not as much as the graphics module, but there are new classes, and most important, the socket classes have new semantics.

Basically, the network error codes are a little more detailed internally, but I'm not sure it would help. The meaningful codes are already separate (Disconnected, NotReady).

[Lo-X]

It's wrong, the network part has changed too
Not as much as the graphics module, but there are new classes, and most important, the socket classes have new semantics.

woops !

[snooc]

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.

[Laurent]

I also answered to that in my previous message

[snooc]

Oh sorry, I didn't had my coffee at that minute so I didn't realized your answer

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;
  }
}
 

[Laurent]

Read the doc of the class that you use, don't try to deduce things from the internal stuff of the base class.

UdpSocket::unbind()
TcpSocket::disconnect()
TcpListener::close()