Anything that is not C, resides in different build units (lib/dll/exe) and is interfacing means trouble if they are not built with the same exact settings.
Exact settings in the sense that the objects created in one unit may not safely be passed to a different unit if they do not compile to the same code in both.
Esp. classes from templates fall in this category. Even when they are just inside a header, every compilation unit will have it's own copy of the actual code.
If the string is passed in correctly, and later is printed out with std::cout correctly, how do you know characters are being lost?
My vote is on your debugger showing you the wrong value, but that the string is fine and the file itself is in the wrong location.
Try printing out (with std::cout) the value of the string before and after "file.open(filename, std::ifstream::in);".
If they both print out the correct string value, and the only wrong string value is shown in your debugger, then you know it's the debugger that has the bug. Improperly displayed debugger values is a fairly common occurrence for the debugger I use. 
You have another unrelated problem here:
major = Line[16];
minor = Line[20];
build = Line[24];
revision = Line[28];
Line[16] is a char; so only 0-255 of the version will be copied into 'major'... Line[17-19] won't be copied over. (Here's a compilable example)
If the string is passed in correctly, and later is printed out with std::cout correctly, how do you know characters are being lost?
My vote is on your debugger showing you the wrong value, but that the string is fine and the file itself is in the wrong location.
Try printing out (with std::cout) the value of the string before and after "file.open(filename, std::ifstream::in);".
If they both print out the correct string value, and the only wrong string value is shown in your debugger, then you know it's the debugger that has the bug. This is a fairly common occurrence for the debugger I use.
You have another unrelated problem here:
major = Line[16]; minor = Line[20]; build = Line[24]; revision = Line[28];Line[16] is a char; so only 0-255 of the version will be copied into 'major'... Line[17-19] won't be copied over. (Here's a compilable example)
good catch, thanks. I've been working with flat txt files, and will be switching to binaries with the next minor update, . I'm sure i would have caught when those ints were actually used for something. And you were right about the debugger. somehow even though i copied the project, it's working directory was changed back to default, rather than $(OutDir) in vs2010 express. This was not an issue in the other version, because i had data files in both the projectdir, and the outdir.
Did you notice the pattern that the first 4 characters are discarded, regardless of string length? Linking two different versions of the String class caused slicing: the reader thinks the string begins four characters past the location where the writer thinks it begins. It's like reading a book starting from page 5 and not realizing that one is missing a part. Presumably the "debug" string variant adds a 4 byte field, like a pointer or a length, before the string characters; of course, getting far enough to access a wrong-named file instead of segfaulting is a miracle of undefined behaviour. Advice: 1. Kill your old dirtbag compiler: obsolete C++ might be "retro", but incoherent linking has never been acceptable. 2. When in doubt, delete all compiler output and compile everything from scratch.
It was not the first 4 characters, but half the string. on "k1820304.txt" it would return "04.txt" . in regards to your advice... that dirtbag was my only computer at the time, and 2nd, i always attempt that, as i've seen the voodoo that msvc can manifest. I generally don't ask for help unless i've exhausted all known avenues of attack.
Meh, Visual Studio isn't too bad.
The reason you get a problem is because you are calling a function in a library that uses a template parameter, and the compilation unit you called it from and the library don't have the same settings. The name mangling of the template resolves to the same thing despite the layout of the classes being different, so the compiler and linker thinks the class is the same size when it isn't.
