I started writing my own optimizer-translator for fun code. I am new to c ++ and SID. I enter the number from the console. Example 1048575. This code writes 00 0F FF FF to the file:

#include <iostream> #include <fstream> using namespace std; int main() { int exe[100000]; ofstream ofile; ofile.open("s.bin", ios::out | ios::app | ios::binary); int n = 0; while (n < 10000) { cin >> n; int n1 = n & 255; int n2 = (n>>8) & 255; int n3 = (n>>16) & 255; int n4 = (n>>24) & 255; ofile << static_cast<char>(n4); ofile << static_cast<char>(n3); ofile << static_cast<char>(n2); ofile << static_cast<char>(n1); } ofile.close(); return 0; }

I read that it is better to work with binary like this:

 #include <iostream> #include <fstream> using namespace std; int n; int main() { fstream f; f.open("s.bin", ios::out | ios::app | ios::binary); while (n < 10000) { cin >> n; f.write((char*)&n, sizeof(int)); } system("pause"); return 0; }

But this code writes the number in the wrong order, it turns out FF FF 0F 00. 1. How to fix the second code? 2. Or is it better to use your bike in the first? “Since I planned to control the byte order in the algorithm during generation.” 3. Why advise the second code to work with binary files? Will there be any "inconvenience" with the growth of the code if you leave the first code?

  • one
    htonl ntohl will help bring to one kind - eri
  • ru.wikipedia.org/wiki/… - Kirill Malyshev
  • If C ++, then it is necessary to work with files as with streams (ifstream, ofstream, fstream), and not with old functions. But even with old functions, it is easier to write an int to the file right away, as in the second example. Why do you need to break the whole into bytes? This is a matter of translator and I / O system. - pepsicoca1
  • Yeah, the second example int writes right away, but as I understood in little endian, I wanted big. - Code07734
  • I can’t understand how to write an int right away in the first example, I don’t know how to deploy bytes in the second. - Code07734

1 answer 1

I do not understand why you do not understand :) that you will read exactly what you write .

If you write a number with swapped bytes - it is clear that you will read the number with swapped bytes, and you really need a “crutch” - either yours or the one written more efficiently, say, in the form of an assembly insertion.

The question is - why do you even write bytes in the wrong order? Why did you decide to choose big endian, working on a machine with little endian? Is it really "for fun" (c)?

The second is that it is not clear where these “tips” come from, to use the C approach. As a rule, one thing is chosen - either the C approach or the C ++ approach. To say what is better and what is worse is to separate holywar here, so I’ll just say that they are absolutely compatible with the results and ultimately work through the operating system API :)

  • It's more comfortable for me. Stop, what I consider uncomfortable, is this default - litle endian? - Code07734
  • Well, it depends on where you work :) - ru.wikipedia.org/wiki/… - Harry
  • I understood! - It seemed to me that at first the bytes are written in the reverse order, and then they are still inverted - at night I was already sitting, he himself invented a problem! "why do you even write bytes in the wrong order?" - To generate processor opcodes. I’ve been reading processor opcodes with a hex editor, which is why I wanted to flip the bytes :). Now I understand the error. - Code07734
  • How to write int in the first code right away? PS Thanks for the help) - Code07734
  • ofile.write(reinterpret_cast<char*>(&n),sizeof(int)); this: ofile.write(reinterpret_cast<char*>(&n),sizeof(int)); . Well, or shorter :), but not in the spirit of C ++ - ofile.write((char*)&n,sizeof(int)); - Harry