My name is Alberto Fernandez and first of all, thank you very much for the tool you are sharing. I have a problem that is driving me crazy.
To the problem that I mentioned, I'm trying to parse a file compiling with visual studio 2005 Express. It seems that I can not read the file. The curious part is that if I compile the same code with gcc (I used code::blocks as IDE as I'm not that deep into programing). When I read the file with the unix eol character it works but if it has the windows enl then I can not read it (compiled with visual studio it does not work any way). I can not use gcc in this particular case because I have a dll (from someone else) compiled with visual studio that seems not to work with gcc.
I have been investigating in your basic_initialization and your read_in_file functions but I can not locate what is going wrong. Could you be so kind as to help me with this.
Thank you very much for your time.
there was a bug report dealing with this issue. I was working for
a while on this strange behavior. After long analysis, I found out,
that the MS implementation of the istream .unget() and .seek(-1) goes back
two characters when the last letter was a '\n'. I consider this
to be not so good - not to say: totally nuts. Anyway, loading the file
into Notepad and saving it resolves the issue, because notebad
replaces '\n' with '\n\r' which is the two letter Windows Newline.
For more info, please google about the
Carriage Return / Line Feed problem.
I have the same problem using MSVC2003, I beleive it has something to do with the fstream class. This might be caused by the differences between windows and unix end of line and how fstream handles them. I didn't dig deeper into the __read_in_file function to find out what was the problem.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.