Needed : Trusted, "variable-bit," 2s Complement Conversion Functions/Classes

Hi, does anyone have any trusted code for converting various 8/16/32/64-bit, 2s-complement, binary fields to native integers?

I am a relatively weak (actively learning) C++ programmer needing to convert 8/16/32/64-bit, 2s-complement, bit streams (not text representation) to Qt/C++ native numbers. The data stream I receive is highly variable. I will be cutting-out the 8, 16, 32, and 64-bit 2s complement fields from the data stream (as defined by the instructions inside the stream itself), then converting each 2s complement field to a native, C++ integer.

My intent is to create a cross-platform-supportive class that can act on each of the four bit lengths and provide a single (large) result that I then process natively, as needed.

Thank you for any trusted code you suggest.

What do you mean by a "native number"? Neither Qt nor C++ have such a concept. C++ supports signed integers; the only issue here would be one of possible byte-ordering. I'd start by stuffing your stream components into appropriately-sized C++ signed integers to see if the values make sense - they should, if everything is done on the same machine. Of course, that may depend on what you mean by a "stream" if network byte ordering is involved.

Next, you need to determine the endianess of the machine you're running on, which is normally done by inspecting the bytes of a larger integer containing a known value, and use this information to decide whether to byte-swap your ints. You may also have to determine the endianess of your stream, either by ensuring that it is always the same or by including a "magic number" somewhere that can be inspected the same way as native ints.

Thanks SixDegrees, I'll continue my research into the possible need for byte-swaping. I will get a sample of the data feed within a few days.

By native, I was just trying to refer to standard int/short/long integers.

By "highly-variable" and "stream," I was trying to give a terse description to a data feed defined by a session header, followed by a variable number of pairs of A) a 1-byte field descriptor and B) a chunk of variable-length data as specified by that chunk's preceding field descriptor.

The initial environment is Linux (Fedora 14) ... hosted by wmware Workstation 6.5 under Win 7. The CPUs are XEONs.

Thanks for your direction.

If you can guarantee that all data will be produced and consumed by Xeon processors, you don't have to worry about endianess issues; integers will always have the same ordering, period. So you should just be able to stuff your data into appropriately sized integers (use sys/types.h for consistency, with typres like int64_t and u_int32_t are defined and are the same across all platforms) without any further contortions.