[mehdinahid]

Hi all,

I need to convert a double from little-endian mode to big-endian mode but I don't know how? Can anybody help me?

Many thanks, Mehdi

[Banfa]

Well conversion from big to little endian (and vice versa) is just a matter of swapping the order of the bytes in memory.

The problem with a double (or a float) is that there is no platform independent way of doing this.

However assuming that you are happy with a slightly dirty platform dependent method get a pointer to your double or the buffer containing its data and convert that pointer to a pointer to char (this is the platform dependent dirty step). Then you can use the char pointer to swap the bytes in memory.


However I am a little concerned about why you want to do this, however since you have not said what the purpose of the code is though I can't really tell if what you are attempting is logical.

[mehdinahid]

Thanks for the comments. But how can I swap the bytes in memory and in which direction? can you please help? I have a double (data) reading from a binary file using this command (part of the code):


is.read(reinterpret_cast<char *>(&data), sizeof(double));
cout << "Read : " << data << endl;

Now how can I convert it to big-endian.

Thanks

[taylorc8]

http://www.ibm.com/d...ex.html?ca=drs-

[#define]

Transferring files from one system to another can bring up issues like this.
I'm not sure that swapping bytes will work for doubles , use of bitfields and unions, maybe. I haven't tested this for doubles, though.

You may need to work out the format.
ieee754.h

And use unions and bitfields
Unions


Bitfields

Readable and Maintainable Bitfields in C

ldexp()

[Salem_c]

Bitfields are useless for this task, and one of those links is flat-out wrong.

> Bitfields in C always start at bit 0.
It is implementation-defined where the compiler chooses to put the first bits of the first bit-field.

At least the first response puts them right on a number of points.

[#define]

Salem_c, on 29 June 2010 - 08:25 PM, said:

Bitfields are useless for this task, and one of those links is flat-out wrong.

> Bitfields in C always start at bit 0.
It is implementation-defined where the compiler chooses to put the first bits of the first bit-field.

At least the first response puts them right on a number of points.

Don't know what you are talking about, seems fairly simple to me.

Quote

At least the first response puts them right on a number of points.

Could use char pointer and bitwise operators, swapping bytes not so sure that would work.

Quote

However I am a little concerned about why you want to do this, however since you have not said what the purpose of the code is though I can't really tell if what you are attempting is logical.

I've worked on transferring data between different systems, so understand why someone may want to do this.

If I have some spare time I may look at it.

[Banfa]

#define, on 29 June 2010 - 10:24 PM, said:

Salem_c, on 29 June 2010 - 08:25 PM, said:

Bitfields are useless for this task, and one of those links is flat-out wrong.

> Bitfields in C always start at bit 0.
It is implementation-defined where the compiler chooses to put the first bits of the first bit-field.

At least the first response puts them right on a number of points.

Don't know what you are talking about, seems fairly simple to me.

Think about it, we are talking about swapping byte order, bit fields deal with bits (the clue is in the name ) not bytes and are therefore not suited.

#define, on 29 June 2010 - 10:24 PM, said:

Quote

At least the first response puts them right on a number of points.

Could use char pointer and bitwise operators, swapping bytes not so sure that would work.

Well linking different computer platforms through various serial and network links is what I do for a living and manipulation of the bytes using either pointers or bitwise operators is the normal way to achieve this. I have used a union to do the same thing but that is a very dirty way to do it and I only did it that way on an 8bit machine which was trying to manipulate 32bit values because the union used many times less assembly instructions to do the same thing in that instance and processing time was an issue.

#define, on 29 June 2010 - 10:24 PM, said:

Quote

However I am a little concerned about why you want to do this, however since you have not said what the purpose of the code is though I can't really tell if what you are attempting is logical.

I've worked on transferring data between different systems, so understand why someone may want to do this.

Yes but I do not think you are truly appreciating the consequences and issues that the original request entails. Transferring ints between machines is less of a problem most machines deal with ints in the same way and Berkeley sockets specification provides functions for converting ints into and out of network byte order from host byte order providing a platform independent way to do the operation. Even ignoring these functions most platforms today use 8 bit bytes and don't use any trap bits so you can write code using the the bitwise operators to perform the swap that will work on most platforms. Many platforms do use IEEE 754 for floating point representation but it is not mandated. Floating point formats are even less likely than ints to be portable between platforms and therefore just slapping the data into an inter-platform communications link is not a good idea. It would be better to process the data and put it onto the link in a very defined manor and that way you can take it off again at the other end and reconstruct your value.

This post has been edited by Banfa: 29 June 2010 - 05:10 PM

[#define]

Quote

Think about it, we are talking about swapping byte order, bit fields deal with bits (the clue is in the name ) not bytes and are therefore not suited.

Quote

(the clue is in the name )

Lol, I know that it would work for integral types, but I wasn't certain about floats. On further reading/thinking about it, swapping bytes for floats should work. You may say that bit fields are not suited, but it was mentioned that they were useless, which I was really commenting/upset about.

Quote

Quote

I've worked on transferring data between different systems, so understand why someone may want to do this.

Yes but I do not think you are truly appreciating the consequences and issues that the original request entails.

I got it into my head that the OP was reading data from a file ... its been a tough day, but good as well.

Quote

Many platforms do use IEEE 754 for floating point representation but it is not mandated. Floating point formats are even less likely than ints to be portable between platforms ...

Yes this was one of the things I was concerned about.

Thanks for your thoughtful post, it has cheered me up, I'm glad at least one of us is on the ball today.

This post has been edited by #define: 29 June 2010 - 05:54 PM

[Oler1s]

Quote

You may say that bit fields are not suited, but it was mentioned that they were useless, which I was really commenting/upset about.

Bitfields are shortcuts for bitmasking. The problem is that they are a minefield of implementation defined behavior. In particular, the standard indicates that the allocation order of bitfields is implementation defined, IIRC. That allocation order is very likely to depend on endianness of the system.

Just think about this. You need a way to deal with endianness. You propose using bitfields, which depend on the implementation, and quite likely, the endianness. Your solution to dealing with endianness may fail because of dependency on endianness.

I think that characterizes an utterly useless solution.

[Salem_c]

First, a bit of history.
http://plan9.bell-la.../dmr/chist.html
C was born 40 years ago on machines with a lot less than 64K of memory. Note that is K, not M or G.
"K" to "young'uns" today is a rounding error!

Bitfields (and unions) were an excellent way of stuffing many small values into a compact space. For the first 10 years, the lack of a detailed language spec, a single reference compiler and not a lot of concern over portability (that came later) wasn't a problem. Bitfields were portable, because there was only one implementation.

The 80's arrived, and a number of different C compilers sprang up to cater to the emerging PC market. These obviously did a lot of things differently in the details. Eventually, ANSI got a grip on the problem and produced a standard towards the end of the decade (ANSI-C89 and ISO-C90).

Since one of ANSI's remits was to "not break existing usage", and that a lot of existing usage of bit-fields did things differently. Also, the committee did not want to introduce anything which might hinder efficient implementation, with statements like "bitfields shall be packed into 32-bit words, starting with the most significant bit".
The result is that bitfields are almost entirely "implementation specific".

Essentially, all bets are off if you try to expose a bit-field to the outside world.


How many tutorials do you see on the web, where say a BMP header maps directly to a C struct? It 'worked' at the time, because the only compilers that had to deal with it all did it in the same way. Unfortunately, "happened to work 20 years ago" does not equate to a reliable coding technique today.

There might be a few less popular compilers nowadays, but the number of architectures has mushroomed. The number of permutations of endian, padding and alignment options is bewildering. Some machines (eg MIPS) can even flip endian mode at run-time.

The grim reality is, if you want to serialise your data to/from some external source, then you have to basically pick it apart yourself a byte at a time.

The days of simply being able to memcpy() a block of data onto a struct of some sort, and have it all done for you are gone.