[eng. elaph al_abasy]

r.stiltskin, on 12 March 2011 - 11:06 AM, said:

My answer is still basically the same:

while(in.read(reinterpret_cast<char*>(&cos),sizeof (int))) {
    out.write(reinterpret_cast<char*>(&cos),sizeof (int));
}

But that doesn't make sense to me. You say that you are generating a new wave, so why are you reading the data of the old wave and writing the same data to the output file?

I also don't understand what you are doing with seekg. After each 4-byte read, the file pointer automatically advances 4 bytes. Isn't your data contiguous? Did you write something else in between the wave points that you want to skip over? What is s? Why are you moving the pointer?

edit: If you have a reason to skip some of the points from the input file, that's fine.
while(in.read(reinterpret_cast<char*>(&cos),sizeof (int))) will read and enter the loop only as long as there is more data in the file. It won't duplicate the last entry.

i read it from file because later i will use the same code idea with DSP "TMS320C6000"
so i cant generate cosine wave and using the COS function but i have a table to read the wanted values from it "table lock up method "

[eng. elaph al_abasy]

also for the seekg i calculate the step size for each corresponding freq (S) and set the pointer to(S-1)points this s-1 is un wanted points i want skip them

This post has been edited by eng. elaph al_abasy: 12 March 2011 - 11:43 AM

[r.stiltskin]

OK, well I still have only a vague idea of what you're doing, and why you're skipping points. The entire sequence of points in the input defines your cosine wave. If you are skipping points and writing only a subset of non-contiguous points to the output file, the output file will not define a cosine wave.

Anyway, if you set up your while loop to read in the manner that I suggested above, it will not duplicate the last entry in the file. If you're not getting the results that you expect, there is something else wrong in the logic of your procedure.

[r.stiltskin]

I understand that you are using a lookup table but you haven't explained (or shown) exactly how you are implementing this. I suspect that you are making multiple passes through the file and "scrambling" your wave in the process.

I suggest that you make a single pass through the file and read all the points in order into an 8192 int array, modify the data in the array as necessary, and then write the entire array to the output file.

[eng. elaph al_abasy]

r.stiltskin, on 12 March 2011 - 12:25 PM, said:

I understand that you are using a lookup table but you haven't explained (or shown) exactly how you are implementing this. I suspect that you are making multiple passes through the file and "scrambling" your wave in the process.

I suggest that you make a single pass through the file and read all the points in order into an 8192 int array, modify the data in the array as necessary, and then write the entire array to the output file.

if i do that save the data to the array i will have a problem with the big size of that array on RAM
and i want to do that in min space using of the RAM memory

[Techno Viking]

This is GOLD for beginners like me!! THANKS!!!

[bloodzdevil]

Sorry If I sound stupid, but can this method (>>operator) one be used with read and write functions with little or no modifications?

[r.stiltskin]

Your question isn't exactly clear. It would be better to ask in the c/c++ help forum, using your own code as an example.

[bloodzdevil]

I felt that this was appropriate...I don't have any code but it was just an idea...I'll explain it further.

It was said that after overloading the '<<' operator, we can avoid repetition of the last data read from a file in c++.
This method could be used for simple as well as user defined data types.
My question was that could a similar approach be used in case of read() and write() functions instead of '<<' operator.
Can we avoid repetition of the data, and replace while(!eof()) with something involving the aforesaid functions?

[r.stiltskin]

It makes sense for read, e.g., while( infile.read( ... ) { ..., but it's not clear what you have in mind regarding write, since writing is generally limited by whatever your program has to write & not by the status of the file or output stream (assuming the file has been successfully opened for writing).

[OLH064]

I was learning about ASCII files before I found C, and I had a train of thought similar to that of a developing atheist.
"Why use a value to limit file size? Why not just use the file system's byte count?"

[r.stiltskin]

Probably because that information isn't part of the file -- it's information about the file that is maintained by the operating system. Using that approach the program would have to get the file size from the operating system. You can't assume that every operating system will have the same interface for getting that information, so a program would either be written for one specific OS and would work only on that one, or the program would have to include code to determine which OS it's running on, and different functions to read from each possible OS.

Much more complicated than placing a simple marker in each file.

[OLH064]

But file ops in themselves are functions of the OS. I see a problem with having to learn a new OS's deeper file ops, but that's part of learning file access, right?

[r.stiltskin]

Well I've never really thought about it since I haven't been anywhere near writing an OS or a compiler, but it seems that the basic, universal piece of information that an OS must be required to provide is some signal indicating that there is no more data, and with the current approach that's enough. A program just needs to know how to recognize that signal, whatever it is, from the particular OS that it was compiled for and insert an 'eof' marker into the data stream.

Finding out the exact amount of data from the OS requires that the OS be willing and able to supply that information. File systems don't tailor storage space down to the exact number of bytes for each file. Disk space is allocated in "blocks" of arbitrary sizes determined by the file system so a file rarely fills all of the space allocated to it. I don't know for certain, but I doubt whether the exact amount is accessible outside of the disk controller itself.

[DamaroPoject]

Hi, if you want read one line try this:

while( getline(file,line))
{
  cout<<line;
}