furyoftheskies wrote:Holy cow Balcerzak, you've done pretty much the basic thing that I want to do lol. I meet another genius now lol.
What C++ program are you using? Dev-C? Visual C++?
Far from a genius, to be perfectly honest I'm really an amateur with little to no formal computer programming education (I took a one-month course on Intro to C++). I do use a lot of programming at work, so I do have a fair bit of practical experience, but I'm really more of a physicist that codes, rather than an actual computer programmer, and thus I may not always fully understand what's going on behind the scenes (though I do try to learn).
That said, as far as what I work with, I use the version of CINT that comes bundled with ROOT, as that's what I do most of my programming in for work, though it does have a standalone version. See wikipedia's entry
on it or the project's homepage
for more information. So that means most of what I do is interpreted C++, and I'm a little shakier when it comes to designing makefiles and compiling executables, so probably can't be of a whole lot of help there. There's also some nuance differences when feeding macros to ROOT to be interpreted, that I cleaned out already for you, to leave it in more generic C++. (For instance, ROOT tends to want the name of the main function to be executed to match the filename of the macro file you feed it for execution, and it uses that to build some sort of internal "main", as far as I'm aware.)
I'm going to rearrange your post and reply to it in a different order, so I hope that doesn't cause any confusion. Just FYI.
fury wrote:I'll go and write the code and see if I can get it done. Believe it or not, I'm actually going to try and convert this to C# (C Sharp) since I've been using it a bit often. But I can always write it in C++ thanks to you Balcerzak.
I encourage you to do this, actually. While I don't honestly know any C# myself, nor even much about it, so wouldn't be able to offer any language specific advice, it's really best to work in the framework you're most familiar with. This also means you don't have to worry about downloading new unfamiliar software or packages in order to make or run the tools you need or want.
On the other hand, some problems lend themselves to easier solutions in different environments, so sometimes it's not always feasible to do this, but when it is, and you're able to work with something you're familiar with, you tend to understand it better, and can then in the future apply it to solving similar puzzles. I honestly don't think there will be any issues here, though, as from what little I do know about C# leads me to believe that's is very closely related to C and C++, which means a simple transition should be possible, and easily workable.
Also, like phib (or at least how I understood what he said) I don't have any immediate or long term interest in the project, at this point, but I don't like seeing people struggle if I think I can help out. Ultimately though, I hope I can help you learn to help yourself. I am fully aware from my own personal experiences, however, of how much more convenient it is to be shown a complete working example of code. Also, I got a little intrigued by your particular problem and have a hard time resisting a well-defined challenge, just as a test of my own skills and understanding.
Now, onto the actual code part of the discussion. I suppose it would be helpful if I explained exactly what did what, so that you can do conversions more easily. First though, I'm going to answer your quick question from the end.
Quick question: Is this how to skip to a certain byte? For example, I know that the offset of a file is located 76 bytes after the beginning, and every successive 76 bytes there is an offset read little endian. Would the code go something like this?
Code: Select all
x is a variable integer. The program should run until it hits an offset that is too large. Ex if the filesize is 4500 bytes, if the program hits an offset that is lets say 6000, it will stop and then output x, which would tell me the number of offsets in the file.
This will not work, for a couple of different reasons. First of all, you haven't properly defined x, and you're going to need some sort of external control structure to do what you're ultimately intending here (if it was me, I'd probably choose a for loop, I like for loops). Secondly, when we declared the bytes variable, we declared it as a static array with only enough room for two entries, meaning we can only properly use bytes and bytes, anything else is asking for trouble (most likely unexpected runtime behaviour, segmentation faults, etc.).
Detailed TL;DR explanation: What you're actually asking the code to do here is to retrieve the amount of data from file that fills the same amount of space as a member of the bytes array, and to store that information at the memory address found by following the pointer to the beginning of the bytes array, and then continuing along until you're reached the specified offset (in the case of x == 1, that is putting things into bytes). This is highly dangerous, as the bytes may point to memory the program doesn't have access to, it may be a different variable that's important to the program running that now gets over-written, but doesn't end up crashing it, leading to unexpected behaviour, or any of a number of other things could go wrong.
I'd deal more with a couple of ways to try to do what you want to do here later, but I think I should now go ahead and actually explain step-by-step, how the various pieces go together. If I over-explain things you already know or understand, forgive me for being thorough, I don't mean it as disrespect. (Spoilered to save on visible space.)
So that's the detailed summary of everything I had written for you earlier, so hopefully knowing the concepts behind the code will make your C# transition easier. For further reference, a look at http://www.cplusplus.com/doc/tutorial/files.html
couldn't hurt, as it seems to lay out the basics very well, though if you need more information on any of the specific methods for fstream the link I provided earlier is probably a better bet.
Your program does what I want to do with the file. It specifically does almost all of what I want to do.
From your code, I want to change to this:
Code: Select all
fstream oldFile("X:\script\filename.scn", ios::binary | ios::in | ios::out);
short* foo = &oldBytes;
oldRevbytes = oldBytes;
oldRevbytes = oldBytes;
short* bar = &oldRevbytes;
fstream newFile("X:\newScript\filename.scn", ios::binary | ios::in | ios::out);
short* foo = &newBytes;
newRevbytes = newBytes;
newRevbytes = newBytes;
short* bar = &newRevbytes;
You're going to need to make sure to use different variables for the shorts for oldFile and newFile. oldfoo/newfoo might work, or you could actually give them a real descriptive name. I was just being lazy originally.
fury wrote:As you can see, filename.scn is the same file in terms of name, but the location (and most likely size) will be different. The original one is located in x:\script\, while the modified one will be located in x:\newScript\
After that, I determine the size and header of the original. From there, I compare those values obtained to the new script. If the new script's header size:
1) Does not correct match the file of the original (As in, if the file size minus the little endian bytes DOES NOT equal the header) then the program will fix it and output it for verification by using the data of the original. (In other words, it will show me what it will do, with a Y/N question confirming if I want to do it.)
Mmm, intriguing. I think I could figure out most of that, with the possible exception of the user prompt. I've not done a lot of work with user input. I may have to do a little more tinkering around just for fun here.