I mean it, which i wrote in my question because i asked same questions to others but i got answ that they are't able to give me answer.
Ok, i have one more question
firstly i'm using win XP and compiler is TC++
question is i have to read a file. i'm skipping some lines by reading them, after this i'm reading that line which i want and then i'm writeing this line on output file.
here is my code



but it's showing odd output. i'm taking SIZE=1024.
In inputfile few lines are very long n few are too short.

i made a file, only 5 lines r there.
i took experiment on few lines, like i start reading file from bigning and then write it on output file. It writes that line accurately but after that line it's writing another line on same row which does not exist on source file, i do't know why and where from.

can u tell me how can i flush inputstream.

First off, which version of Turbo C++ (I presume this is what you meant by TC++) are you using? The older versions are 16-bit, pre-ISO standard C++ compilers that these days should be considered pretty obsolete (see http://en.wikipedia.org/wiki/Turbo_C++ for a brief history). Note that if you are using one of the old 16-bit Turbo C++ compilers then you cannot make use of any Win32 features, you are stuck in 16-bit compatibility mode of the Windows on Windows (WOW) subsystem. You also would not have access to standard C++ library features. In particular you will be using the Borland implementation of the pre-standard (traditional) IOStreams library, about which I have no, or little, specific information. If you do have an old pre-ISO standard (and 16-bit) compiler, then I really urge you to consider updating to a more up to date implementation. Both Borland and Microsoft have free downloadable C++ offerings, see http://www.thefreecountry.com/compilers/cpp.shtml for a list of free compilers, including the Microsoft and Borland offerings.

Secondly, your question and shown code do not give enough information to pin point all your problem(s) for sure.

However I would start by reading the small print of the write function. This function does _not_ write C-style strings. If you give it a pointer to a buffer of n chars (or more) and tell it to write n chars then it will write n chars to the best of its ability. It _will_ _not_ take note of any end of string markers because, as I said, it is _not_ intended for writing strings! It is intended to allow the writing of buffers of binary data. Thus you can either tell write to write just the characters from the read string (e.g. by passing the value returned from strlen(line) instead of SIZE to write). This still will not get you an end of line as write does not, of course, add one automatically, and getline will read one if encountered before the buffer is full but not place it into the buffer. Thus a more obvious way to write your data is to use the stream insertion operators (operator<<):

   fwrong << line << '\n';

Or you could use std::endl (or just endl, if using a pre-ISO standard library):

   fwrong << line << endl;

The point about endl is that it writes the end of line to the stream and flushes the stream (which answers your final question I think). ISO standard C++ output streams also have a flush operation, and a quick look in the pre-ISO standard "The C++ Programming Language" 2nd edition by Bjarne Stroustrup indicates this should be so for pre-ISO standard (traditional) IOStreams also:


Output streams are also flushed before being closed of course. Note that continually flushing data to file will slow down your program. If this becomes noticeable then consider not flushing so often (if doing so often, for safety for example). In most cases I tend to write data to a file in one lump then close it. If the file is to be left open for a long time with sporadic writing, then I might flush after each chunk of output, where the length of the chunk depends on the circumstances. In really critical cases I might open the file, write a chunk of data and close it again (an error log file for example).

Note also that if any of your input lines exceed 1023 characters (standard behaviour, check your compiler library documentation for non-standard behaviour) then getline will not read the whole line. This would lead to such lines being written across more than one line unless you take additional steps.

If you do have a compiler that has an ISO standard C++ library then you can read from a stream into a std::string class object (include <string>):

   std::string line;
   std::getline(firstfile, line);

This should only fail for very, very long lines that exhaust available memory for the line std::string object to use to store the characters in (unless some other problem is encountered of course). The exact reasons for the above getline function to stop reading and storing characters are:

- the firstfile.width() is greater than 0 and width() characters are stored

- firstfile.good() is false (indicating a stream error and may raise an appropriate exception if the stream is so set up)

- a delimiting end-of-line ('\n') is extracted (but not stored)

- line.max_size() characters are stored

Hope this is of help.


All Answers

Answers by Expert:

Ask Experts


Ralph McArdell


I am a software developer with more than 15 years C++ experience and over 25 years experience developing a wide variety of applications for Windows NT/2000/XP, UNIX, Linux and other platforms. I can help with basic to advanced C++, C (although I do not write just-C much if at all these days so maybe ask in the C section about purely C matters), software development and many platform specific and system development problems.


My career started in the mid 1980s working as a batch process operator for the now defunct Inner London Education Authority, working on Prime mini computers. I then moved into the role of Programmer / Analyst, also on the Primes, then into technical support and finally into the micro computing section, using a variety of 16 and 8 bit machines. Following the demise of the ILEA I worked for a small company, now gone, called Hodos. I worked on a part task train simulator using C and the Intel DVI (Digital Video Interactive) - the hardware based predecessor to Indeo. Other projects included a CGI based train simulator (different goals to the first), and various other projects in C and Visual Basic (er, version 1 that is). When Hodos went into receivership I went freelance and finally managed to start working in C++. I initially had contracts working on train simulators (surprise) and multimedia - I worked on many of the Dorling Kindersley CD-ROM titles and wrote the screensaver games for the Wallace and Gromit Cracking Animator CD. My more recent contracts have been more traditionally IT based, working predominately in C++ on MS Windows NT, 2000. XP, Linux and UN*X. These projects have had wide ranging additional skill sets including system analysis and design, databases and SQL in various guises, C#, client server and remoting, cross porting applications between platforms and various client development processes. I have an interest in the development of the C++ core language and libraries and try to keep up with at least some of the papers on the ISO C++ Standard Committee site at http://www.open-std.org/jtc1/sc22/wg21/.


©2017 About.com. All rights reserved.