Thank you very much for your reply. I don't consider myself to be a very
experienced c++ programmer so forgive me if the questions seem
mundane/trivial
do you mean just for correctness ? because I see that istream is a base
class for iostream.. or is there some other reason for explicitly including
istream
Because the standard says so
.
Officially, <iostream> is not required to define any class. It
is only required to provide external declarations (not
definitions) of the standard iostream objects (e.g. std::cout,
etc.). And you don't need a class definition to provide a
declaration. I'll spare you the real requirements, because they
are extremely (and IMHO unnecessarily) complicated, but it comes
out to roughly the equivalent of:
namespace std {
class ostream ;
class istream ;
extern istream cin ;
extern ostream cout ;
// ... same thing for all of the other objects,
// plus for the wide character classes and objects...
}
For convenience, all of the actual implementations of <iostream>
that I know of start by including <istream> and <ostream>.
People have gotten used to this, many books (including some very
I'm sorry about that... I just created a default win32 console project
using VS2005 and thats what it gave me. I'm really not sure whats the reason
for all that either, but i think it somehow converts to the typical main()
That's what I suspect as well, but since I don't normally have
access to a Windows machine...
can you tell me where is the most updated (or correct) documentation for
these functions? because all the places that I looked -basically MSDN and
google search results - do not mention this thing about seeking undefined
for text mode.
The official documentation would be the ISO standard for C++.
In this case, however, it refers to the C standard---everything
is "as if" such and such a C library function were used on a
FILE*. Which isn't necessarily a bad thing, since the C
standard is somewhat less unreadable than the C++ one
.
With regards as to where you should look for such information,
I'm not sure what to tell you. I was tracking the ANSI
C standard for a customer when it was being written, and writing
a C standard library for them, so I got in on the ground floor,
so to speak. I don't think that trying to read the standard is
a good way to learn.
I would hope that any text which teaches C++ IO would discuss
the issues, but apparently, yours didn't. And given my
background, I've not had the occasion to read such texts myself.
(I have copies of the C and the C++ standards, and the latest
draft for the next version of the C++ standard, on line, and
consult them when I'm unsure of anything. But IMHO, unless you
already have a very good idea about is available and allowed,
they wouldn't be of much use.)
if you read my other post, you'll see that the problem was with 'LF'
characters in the text file.
And, presumably, certain implementations accepting them as end
of lines, and others not.
Note that this is a difficult problem in general. The Windows
convention is to use the two character sequence 0x0D,0x0A as an
end of line indicator. The Unix convention is a single 0x0A,
the traditional Mac convention a 0x0D, and most mainframes don't
use any character at all; the information is stored in the file
format. All of which wouldn't cause too many problems, except
that the C committee decided that within C, the Unix convention
would prevail, so some remapping is necessary at the interface
(and we get the distinction between text and binary files), and
of course the fact that today, thanks to the network, files
written on one system are being read on another, so you can't
really count on the file following the local conventions. IMHO,
a good implementation will handle the Windows, Unix and Mac
conventions transparently on input, and output according to the
native conventions, but I've also had various problems because
of inconsistencies.
The fact that some "char" might in fact be represented by a
varying number of bytes in the physical file is why there are
so many restrictions on where you can position to in text mode.
Note that the problem will become more difficult, not less, as
time goes on---UTF-8 is rapidly becoming a standard 8 bit code,
and with UTF-8, of course, the number of bytes in a single
character can vary from 1 to 6.
I have been using this legacy code that was written by one of my
predecessors... and its probably outdated (or the wrong) way to do things.
I am all for moving to a more commonly used (and free) parsing
technology...but I don't know where to start. I tried looking up parsing in
google once but I was overwhelmed by what was out there. I need to be able
to read a text file that contains strings and numbers... but ignore c-style
comments like '//' and '/*' and '*/'
Is there any easy to use parsing utility that can do that for me (in both
windows and unix) ?
Well, I tend to use lex (or flex) a lot. (Technically speaking,
I think your problem involves tokenizing, which is generally
viewed as a preliminary step to parsing.) Flex is available for
most platforms, although I don't know how you'ld go about
integrating it into your builds if you use Visual Studio. (I
use GNU make everywhere, including with VC++ under Windows.) It
also generally takes a bit of hacking to make it work with C++.
You might want to have a look at the sources to my executable
kloc (
http://kanze.james.neuf.fr/code/Exec/kloc/kloc.l); you
certainly won't be able to use it directly, but it should give
you some ideas about one way to handle comments directly in
flex.
Depending on the syntax, and the size of the files, you might be
able to either process the file line by line, or even the entire
file at once. Once you have a block of text in memory, of
course, random positionning, backing up, etc. is no problem.
And you can use tools like boost::regex on the in memory data.
If you don't want to rewrite everything, you might also try
reading the file as binary, and handling the new line
conventions yourself---it isn't that hard to treat \n, \r and
the two character sequence "\r\n" in an identical fashion.
(There will still be problems, of course, if you move to UTF-8
input, with accented or non-Latin characters, but this may not
be an issue for you.)
