Hello,
I have data retrieved from .read() file i/o operations which works on char arrays. I'm looking
at cleaner ways to convert into arrays of 16 bit and 32 bit unsinged integers.

One way to do it is :
I am trying to avoid coding with C arrays where I can write past boundaries. Is there a better C++ way?

Another question is that if I encapsulate the .read into a function that outputs with C++ strings,
is there an easy way to do the same thing, i.e. convert from the char array to shor int arrays?

The signature is fixed. If it expects a character array as an argument, you have to provide a character array.
You may want to look at the string class. eg.

The "better C++ way" is not to use arrays. Use vectors. (Read a value. Push it. Read a value. Push it. Etc.)
See Footnote.

I assume that your file contains binary data. If not, then there's not much point in using the istream read() function, right? I mean, if you want to read integer values from a text file, just use ">>" to read the formatted data. (Still using vectors to hold the values, not arrays.)

Anyhow for binary files:


I have attached a zipped binary file for testing. The file contains hex bytes
Here's the output:


As you can see, on my system shorts are two bytes long and internal storage is little-endian.
What the heck are you asking? What do you have and what to you want to convert it to? Could you give an example?

(If I had a numeric variable and I wanted to convert its value to a C++ string, I would probably use a stringstream object, but I'm not sure that's what you have in mind.)

Regards,

Dave

Footnote: If you really, really need to use arrays rather than C++ vectors (and there are times when you may have to do this), then the way to keep from writing past the end of the arrays is to create code that doesn't write past the end of the arrays. I know this sounds silly and maybe even a little sarcastic, but I mean no disrespect. It is the programmer's duty to make sure the code he/she writes can never, ever write past the end of the arrays.

davekw7x,
Thanks very much for the vector advice.
Earlier this year, I made an array class with the [] operator and messages that pop up if I try to write past the boundaries. The vectors look like a clean already existing method.
There are 2 goals.

GOAL A) is to not use arrays at all nowhere in my code. Even with my integer class, I had to do the intermediate pass with arrays sometimes.

GOAL B) is to get rid of the amateurish way to take 4 chars (usually as subsets of C++ strings), do the sign checking and create an unsigned 32 bit integer. (also the same with the 16 bit short ints)

You see I have packets where in a function I process the header and footer, leaving the middle payload for another function to process as a C++ string. This payload has the 32 and 16 bit arrays I was talking about and am exploring neater ways to do this. Not all my packets have the same size of 16 bit arrays. Maybe I could use a few structs for the couple packet sizes.

Off the top of your head, do you see another solution for goal B???
Thanks a lot!
Frank

Well, I have seen it written that some people think that arrays are always evil. I feel that there are times when they are appropriate and even desirable, and times when other things (C++ STL objects like vectors, sets, maps, lists, queues, etc.) are The Way To Go. (Your Mileage May Vary.) Believe it or not, it is possible to write a bad program with vectors, too.

I still don't know what you mean. What "amateurish" way? I showed how to get bytes from a binary file into memory (actually, I used your file read() example, and I don't see anything particularly amateurish about it).

If you know that the bytes are in correct order, (file-endianness is the same as machine-endianness), then you are through, as I showed in the printout. If the bytes must be reversed, then reverse them. So: What's the question? (But I asked that already.) There's no "sign checking or other "creation." They simple are in memory assigned to a particular variable.
If you are thinking of a file or a network packet as an array of bytes (chars), note that an array of chars is not a string. Not in C. Not in C++. The bytes mean whatever you have defined them to mean. Four bytes in a row can be a 32-bit integer. Even if they are four ASCII chars, that still doesn't necessarily mean that they are a string. (The first four bytes of a .wav file are 0x52, 0x49, 0x46, 0x46, which are ASCII for "RIFF", but they are not a string. Not a C string. Not a C++ string. They are just four bytes. The next four bytes are a 32-bit unsigned int (in little-endian format) They represent the number of bytes in the file after those first eight. There is not a single "string" in a standard .wav file.

Read the bytes from the file into wherever the heck you want them to go. If they are binary numerical values and the bytes in the are in the correct order for your machine, then read them into a variable of the correct type (length). If your program has to read bytes from a file or a network packet (you always have to know whether the ints were written in big-endian order or little-endian order) you can create code that reads a byte at a time into a numeric variable of correct size (using logical shift and "OR" operations) and store in whatever endianness is natural for your machint. In other words the same source code will work whether it is compiled on a big-endian machine or a little-endian machine.

Network programmers use functions like htonl(), htons() to do it in a way that is more-or-less invisible to programmers. Compiler configuration by the vendor has already taken into account whether the bytes going between machine and network need to be reversed. These and many other functions used in sockets programming are not standard C or C++ library functions, but are (almost) always supplied with serious compilers.
Use of structs is an implementation detail (like headers defined with various parameters for bitmap files or waveform files). If the headers are structured in a defined way, then use a struct to make program documentation easier (and the code can look neater, but it's not automatically neater---it depends on you). For example, it's easier to call functions that use pointers to structs as arguments rather than a long list if individual numeric arguments.

Regards,

Dave

Footnote: The subject of endianness must always be taken into account whenever you are dealing with binary multi-byte numeric data items. If you are making your own network protocol, use whatever you want, but you should be aware that all significant network standards transfer bytes in big-endian fashion. That means for people using Intel/AMD PCs (and all of the other little-endian systems out there) always have to reverse byte order when transmitting or receiving multi-byte binary numeric data.