I'm having problems loading data from a file in C++

http://pastebin.com/VhUTQg1F

I load from the file twice. The first time it works and I get the dimension data for the map. The second time nothing is being read it seems and nothing is displayed from cout << memblock[i].

Well, for starters, you're using the new operator for memstuff=new char[2]; when I didn't think that was a valid sort of thing to do. That's where I would have used malloc(), and I'm pretty sure new isn't doing what you think it's doing there.

That part of code is working, I can read data from that memblock. It's the other memblock called mapblock that's the major problem. New essentially does the same thing that malloc() would do which is create a memblock.

No, that is valid.

That said, your deletes do not line up with your frees, among other things. The flow through that method completely falls apart if is_open ever returns false.

Well, it never will return false as the game will define what files are loaded which will exist everytime.

Also this still does not help my problem. I cannot either get data to the memblock or I cannot read it properly to the vector.

Completely false and you should *NEVER* structure your code like this. Handle errors, they *WILL* happen.



Hook up a debugger

I hate to admit it, but Kllrnohj has a valid point there. It's a very big bug if your file loading protocols don't error safely. Never assume that users won't delete accessory files or remove the game executable from the folder. Even if you're going to be generating the files at runtime in the directory of the executable, the operating system could have too little memory and not create the files. There are a million other things that could go wrong to prevent a successful read. *Never* assume that invalid inputs are impossible unless it's your own code generating the input (even then...) or all possible inputs are valid.

To continue in this general line of thinking, the particular name for the programming technique is defensive programming: more or less, assume that everything that could go wrong will go wrong at some point, and handle it. Users typing invalid things at inputs, files missing or corrupt or empty, unconnectable sockets, you name it. You should always check the result of every system call, and every possible point of failure, and deal with it accordingly.

memblock is a really tiny buffer (only 2 bytes), so it makes more sense to allocate it automatically (the overhead that "new" adds is probably much larger than 2 bytes). You can change this code:

Code:

to this:

Code:

And remove the other lines that allocate or delete memblock. You can usually allocate objects like this up to a few kilobytes or more without using "new", unless the size is dynamic (that is, the size is not constant), in which case you definitely should allocate it with "new" and free it with "delete".

Also, you don't have to call map.seekg(0, ios::beg) to move the file pointer to the first byte in the file because the file pointer starts there when you open the file (unless you use the flag ios::ate when opening the file). Similarly, you don't have to call map.seekg(2, ios::beg) because map.read(memblock, 2) automatically moves the file pointer to the third byte after it's called (assuming it doesn't reach end of file).

One last thing: checking for errors throughout your code can actually help you debug your program more easily. If there's a bug in one part of your program, another part just might catch it (and hopefully report the error). Then you just have to find the guilty code. In the case of your LoadMap function, you can check for valid values of MapWidth and MapHeight before reading in the data. By the way, what happens if MapWidth or MapHeight are different for each of the files? Does any of your other code use those as the width and height for all three arrays? If that's the case, you could report an error if the MapWidth or MapHeight are different between the three files, or if either one is negative (char might be signed, meaning the byte 0xFF is negative).

Ok I took your guy's suggestions. As it turned out, and I don't exactly know why this is, it was because MapData and the rest were char vectors and they needed to be int vectors and the data in mapblock needed to be cast to an int when writing to the vector.

So now it's working more or less. XD

Thanks for the help guys.

Yeah, I didn't catch it earlier that doing a "cout << mapblock[i];" will print out a single character rather than a text representation of the number in mapblock[i]. For some values (eg, less than 33), it will look like nothing is printed out because those are non-printing control characters. You would have to cast mapblock[i] as (int)(unsigned char)mapblock[i] to print out an unsigned value between 0 and 255.