Hell ho !

I want to be able to send some double values over a network, but as I want to do it the right way I am in search of some converting function.

Have you ever hear about something as ntohd, htond functions ?

As discussed before, it can often be more efficient to send numbers as text. It can even be more accurate if the numbers are rational e.g. 0.1

Just use that templated one posted a while back.

Thanks to All, thanks to piccolo too ( even if you were not seeing what the question was ).

CGamesPlay: I was thinking so but waiting for someone to confirm.
Matt Smith: I got big and tons of values. Using sprintf trick is too much cost.

What I got tested: same byte order in all Intel/Amd. seem reversed for Sun/Aix.

A good job has been made there

I am waiting for BAF and his link !

I want to give cookies !

Quick !

Basically all machines use IEEE-754 floating point format. However, the endianess of this value is like any other issue. What I did for my network library GNE is to say that all values will be sent little-endian (I chose this because I expect virtually all peers to be little-endian). For floating point I said that I will send in little-endian IEEE-754 single or double precision. Well, Intel and Sun and PPC machines all use IEEE-754, so what the plan is just to say machines that don't support IEEE-754 are just simply "not supported" by any current port of GNE, and if I really need to do it, it isn't too onerous to actually parse a IEEE-754 number by breaking it into its components then using portable C to "convert" it to a float/double. But since I can't find a computer you actually need to do this for nor expect any target user of my library to have one, I never wrote the code.

So, in other words, do whatever you want as long as you precisely define it and give yourself a way out. If that's true, then if the unexpected happens, you can actually perform the work.

What gillius said. Something like:

COMPILE_TIME_ASSERT(sizeof(float) == sizeof(int));
float ntohf ( float net_format ) {
   int r = ntohl((int&)net_format);
   return (float&)r;
}
float htonf ( float net_format ) {
   int r = htonl((int&)net_format);
   return (float&)r;
}

That requires that ints be 32 bit types. There's no pretty (by pretty I mean, without ifdefs) way to do the same for doubles, because doubles are 64 bit and there's no standard endianness conversion function for 64 bit values.

I do not like the use of text for this purpose. The advantages are that it is a variable length format that the standard library already supports. The disadvantages are that it has a space efficiency < 50% and its decimal nature makes it use more cycles than is needed for something as simple as encoding a floating point value.
If you were going to use text-based packets anyway though, why make your packets be stringstreams instead of using ReadNum/WriteNum wrappers?
edit:added missing paren

That's not "more optimized", it's just a smaller vtable A more worthwhile optimization:

template<typename t> t ReadNum(const std::string& src)
{
    t ret;
    std::istringstream s(src);
    s >> ret;
    return ret;
}

template<typename t> std::string WriteNum(const t& src)
{
    std::ostringstream ret;
    s << src;
    return s.str();
}

Well, I got my problem resolved:

On all Intel (PC) computers, nothing to do.

I test the following:

On both the output value is 8 meaning that the size is the same.

On Intel bytes are ordered as following:

On SUN this is the following:

So basically we can see that we should swap bytes by pack of two from start to end.

So basically we can see that we should swap bytes from start to end.

Thanks to all !

Cookies time !

EDIT: WTF ! I did as you said in my test code (getting the double value when opening an intel file on a sun ) And I really dunno why I write a so silly mistake. Thanks for pointing it out, orz.

Fixed !

Because the geniuses who designed C++ didn't create the foot or the meter.

Yes sir.

You've given me so many options...

Anyway, my point that supported it fairly solidly was that the designers of C++ (lets make an acronym form them, how about Good Old [C++] DesierS) put a whole lot of thought into every bit of C++.

If the GODS thought that there should be an istringstream and an ostringstream class as opposed to just a single stringstream class then the GODS must of had a good reason. I don't question the GODS' purpose in this and yet I accept that the GODS are all knowing (in the domain of C++) and therefore I embrace and accept the istringstream into my life.