comparing two test files

[ruds]

Hi,
I want to compare the content of two files, which in turn gives me the
output which lines are deleted from latest version and which lines are
added in it and also if the first line no is same is details changed.
I am reading the first file line by line using BufferedReader and the
opening the second file that is the latest version in another while
loop and checking for match.
But after checking the first line, I am unable to read the second file
again and again.
Here is the code:


FileReader fin1=new FileReader(args[0]);
FileReader fin2=new FileReader(args[1]);
BufferedReader br1=new BufferedReader(fin1);
BufferedReader br2=new BufferedReader(fin2);

while((line1 = br1.readLine())!= null)
{
str1=tokens1[2].trim();
while ((line2 = br2.readLine())!= null)
{
str2=tokens2[2].trim();
if(str1.equals(str2))
{
for(j=0;j<tokens1.length;j++)
{
str3=tokens1[j].trim();
if(!(line2.contains(str3))) { //output to file that record is
changed}
}
}
else{ // str1 is not present in the file}
} //end of while for second file
} //end of while for firsts file

it iterates through the first file but doest not enter the second
while loop after reading once onle i.e for the first line of first
file.

Kindly help.

 

[Jeff Higgins]

Hi,
Kindly help.

<http://sscce.org/>

 

[Stefan Ram]

I want to compare the content of two files, which in turn gives me the
output which lines are deleted from latest version and which lines are
added in it and also if the first line no is same is details changed. (...)
it iterates through the first file but doest not enter the second
while loop after reading once onle i.e for the first line of first
file.

Learn the craft of debugging: You need to inspect the values
of loop-critical expressions at run time and then
understand, why they have these values.

For example, to see the run-time value of »v«, you can use:

java.lang.System.out.println( v );

. That might seem trivial, but many beginners just seem to
be unable to do it.

Then, later, you can deal with the delicacy of reasonable
diff algorithms.

http://en.wikipedia.org/wiki/Diff

 

[markspace]

it iterates through the first file but doest not enter the second
while loop after reading once onle i.e for the first line of first
file.

Besides the advice above on "how to debug," I think you need some
practice on making the algorithm in the first place.

Try to compare two files yourself, by hand. Write down each step as you
do it. Leave no detail out, no matter how small!

Then, try to write your steps as a flow chart. Review what decisions
you made at each step and include them on the flow chart. It's very
important to get these steps in something approximating an algorithm so
you can start to understand it better.

Next pseudo code is out. Pay attention here to basic optimization and
"clean" code, something that looks like an algorithm. Try here to get a
block structure pseudo code.

Then go back to the first step, where you just wrote down your steps,
and try some new inputs. Files with different things in them. Make
sure each of your steps still works. If not, then change to so it does.
Check your flowchart for the same files. Make sure the flow chart
works. Then check your pseudo code; did it also work or not?

Taking the difference of two files is actually a hard problem. You
should expect to make a considerable effort to get it right.

 

[Gene Wirchenko]

[snip]

I've written a web page on the subject of how to debug,
http://www.patriciashanahan.com/debug

Nice page.

How did you come up with that example? It is very good. The
problem with cooking up examples like that is that one already knows
what the problem is so any "detective work" is suspect.

Sincerely,

Gene Wirchenko

 

[Gene Wirchenko]

On 12/23/2011 9:18 AM, Gene Wirchenko wrote:
[snip]

How did you come up with that example? It is very good. The
problem with cooking up examples like that is that one already knows
what the problem is so any "detective work" is suspect.

I took a common student problem that needs a little attention to detail,
and wrote a Java implementation as fast as I could type, making minimal
changes to fix compile-time errors. I then went straight to test and
debug, writing up the debug steps as I went along, without doing any
desk checking.

Normally, my programming keystroke rate is a lot slower than my raw
typing rate. Suppressing self-checking and thinking about details in
favor of typing speed made a good collection of mistakes statistically
likely, but without giving me any knowledge of what the mistakes were.

I hoped the result would be a more realistic example and debug process
than if I had consciously inserted errors in an otherwise carefully
written program, and then pretended to find them.

It is more reasonable that consciously inserting errors since you
actually did not design the errors. You appear to have hit some good
ones, too. That you had more than one is even better, because it
helps make the point that one should not stop after finding the first
error.

I have bookmarked the page, and I will likely point beginners to
it. It really is a good treatment.

Sincerely,

Gene Wirchenko