No endianess problems for double/float?

[P@u1]

Hi,

I recognized, that in SFML 1.6 the sf::packet code for float and double don't do anything about endianess.

Is there no endianess problem for float/double?

I used google and found some articles about how to convert endianess of float/double, so it seems if these datatypes also have endianess, but I'm not sure...

Another question:
With which header do you get access to functions like htonl?

[Laurent]

Is there no endianess problem for float/double?

To be honest, this point is very confusing. Apparently the IEEE-754 standard doesn't say anything about endianess, but in practice it appears to be always the same across platforms.

With which header do you get access to functions like htonl?

On which OS?

[P@u1]

I was hoping for an platform independant header :-)

Do I have these functions automaticully when including SFML/Network.hpp?

Maybe you wonder, why I'm asking all this.
The non-blocking mode of sf::SocketUDP with sf::Packet seems not to work very good for me.
After receiving a packet over udp with return value sf::Socket::DONE the packet is not valid after reading out the same amount of values I put in on the server side.
Maybe it's just wrong usage by me...

I thought about giving boost::asio a try, but afaik it's lacking features for binary data, so I think about try to roll my own on top of boost::asio.

[Laurent]

I was hoping for an platform independant header

You can't expect anything standard if you want to use the lowest possible level functions.

Do I have these functions automaticully when including SFML/Network.hpp?

No, they are hidden in the implementation so that users are not polluted with OS-specific headers.

The non-blocking mode of sf::SocketUDP with sf::Packet seems not to work very good for me.

UDP and packets don't mix well together in SFML 1.6. In SFML 2 they now work perfectly (I've improved this particular code yesterday).

[P@u1]

Thx for your help!
I will definitely give SFML 2.0 a try!

The only thing which does not really convince me so far is the support for asynchronous io.
The biggest problem is that I can't poll if the socket is busy without actually trying to send or receive.
Maybe i will use an additional thread which does synchronous I/O to emulate async I/O.

Edit:
For the additional thread I would need something like a wait condition I think...
Edit2:
I now tried sfml 2.0 and it doesen't help.
Maybe its up to my usage, but I don't know what I'm doing wrong...