Why does sf::Packet convert to big endian?

[iride]

Windows and OS X are little endian. Linux can theoretically be big endian, but today pretty much 100% use little endian.
Converting to big endian seems like waste of cpu. Is there something I'm missing?

[Jesper Juhl]

Network byteorder is big endian.

[iride]

Network byteorder is big endian. But as far as I know, as long as both sending and receiving sides use same endian for data, it doesn't matter. Since SFML's platform uses little endian, why is sf::Packet needlessly converting to big endian?

[Jesper Juhl]

You don't know 100% what's at the other end of the pipe (big/little endian), but everyone agrees that data on the wire is big endian - so everyone can interoperate.
I have a DEC Alpha running Debian Linux that may be very cross if you start assuming that it is little endian and should expect that on the network. Also, little endian machines *know* that everything coming in is big endian and will convert - if it is suddenly little coming in, that conversion will be wrong, at the very least you have backwards compatibility issues with previous sfml versions.
Better to just let the network stay BE as it always has and get fewer headaches. The performance hit is negligible anyway.

(And how on earth did that fscked-up LE byteorder get the upper hand anyway? That's just wrong - BE is the natural thing and the way to go - but I give up...)

[Laurent]

And because we use a "standard" byte order, functions that convert from/to it are widely available on all target platforms, there's no need to reinvent the wheel.

[Nexus]

But as far as I know, as long as both sending and receiving sides use same endian for data, it doesn't matter.

Yes, just that the "as long" is not helpful if the code breaks occasionally. In reality you don't know the other's host endianess.

Since SFML's platform uses little endian, why is sf::Packet needlessly converting to big endian?

SFML's network sockets cannot just communicate to other SFML endpoints. They run TCP and UDP protocols which are ubiquituous, you can talk to anything that implements them. For example, I've once written a sf::UdpSocket that sends to a Java DatagramSocket.

[iride]

But as far as I know, as long as both sending and receiving sides use same endian for data, it doesn't matter.

Yes, just that the "as long" is not helpful if the code breaks occasionally. In reality you don't know the other's host endianess.

I don't really understand what you are saying. I'm talking specifically about sf::Packet. Users who use that class don't have to know anything about endianess. So why would the code suddenly break? Also, I just said that the platforms on which SFML runs on use little endian.

Since SFML's platform uses little endian, why is sf::Packet needlessly converting to big endian?

SFML's network sockets cannot just communicate to other SFML endpoints. They run TCP and UDP protocols which are ubiquituous, you can talk to anything that implements them. For example, I've once written a sf::UdpSocket that sends to a Java DatagramSocket.

SFML's UdpSocket and TcpSocket can talk to other UDP and TCP sockets, but sf::Packet is supposed to be used only within SFML.

[Hiura]

Yes, such packets were designed to be used in SFML <-> SFML applications communication. But since we don't have the strong guarantee that all platforms on which SFML runs are using the same endianness, why add such limitations? Did you experience a significant bottleneck due to this bytes reordering?

[scellow]

C# use little endian, i'm not using sfml network but i think the best would be an option to choose what endian to use

[Laurent]

C# use little endian

What does that mean? Network byte order is independant from any language, it is just a convention. And by the way, C# has functions to work with network byte order too.

i think the best would be an option to choose what endian to use

Since this is an internal format anyway (ie. you don't decode it yourself), what would that change?