Page 2 of 2

Re: Binary file compare engine?

PostPosted: Wed Jun 17, 2009 9:28 pm
by matthias1955
Oh, I just remeber, in foldercompare we have all these infos avaibel. Only not in one we have same in two.
See parameter we use to detect codeing.
So latest till we show the result, the info value in two structures , where some are same, like filename.
Using those in one, can make it a little easier to handle, as space is same.

Re: Binary file compare engine?

PostPosted: Thu Jun 18, 2009 9:17 am
by kimmov
I can't understand what you are trying to say.

Re: Binary file compare engine?

PostPosted: Fri Jun 19, 2009 3:34 pm
by matthias1955
I think we should have

pathname /* original*/
encoding /*FileTextEncoding includeing binarys*/
stat /* File status from fstat() */
desc /* File descriptor */
handle /*Filehandle*/

we have these infos partly in FileLocation and the rest in file_data when we make the folder/file compare.
As all of these infos are used in all comparemethod, we can put these in one structure.
so we have all important infos at one place.

Re: Binary file compare engine?

PostPosted: Fri Jun 19, 2009 6:55 pm
by kimmov
matthias1955 wrote:As all of these infos are used in all comparemethod

You forgot by date/size compare... And perhaps other similar compare methods in future. Those methods don't use file handles etc.

I already got trouble with this when I created the date/size compare method as own compare engine. Couple of years ago I made the same mistake than you above and assumed certain compare options were used by all compare methods. But date/size compare methods are quite different. And many users prefer these since they are really fast. Perhaps even worth making the default as some other compare programs do.

Re: Binary file compare engine?

PostPosted: Fri Jun 19, 2009 7:01 pm
by kimmov
One very important thing when designing WinMerge features and code is to remember possible future expansions. We must try not to set unnecessary limits for the code or for users. Sooner or later we are in trouble again with those limits. All assumptions must be thought carefully.

It is not easy. But if we only look what happens now and only care about current code we really aren't developing anything. We must always prepare for future too. Refactor code so that future features and expansions are possible and easier. So never assume we can only have some data. In few months we may need more data. And nobody likes to rewrote code again in few months.