[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] [merge-tracking] Code clarity fix

From: Kamesh Jayachandran <kamesh_at_collab.net>
Date: 2006-08-31 09:04:19 CEST

Daniel Berlin wrote:
>> >
>> I am not sure about the speed.
>> I thought copying 8 bytes at one shot should be faster than dereferncing
>> 4 integer items and assigning them.
> Again, the compiler will turn one into the other depending on a number
> of factors, including register pressure, etc.
>> If I understand this segment of code it just takes the 'forward merge
>> ranges', which this '*(*output) = *in1; ' should be more meaningful with
>> the associated commit message.
> At least to me, it's less meaningful to do structure copies in a lot
> of cases.
> Others may disagree.
Barring the (confusing???)structure copy stuff, the code segment
essentially assigns 'in1' or 'in2' to output.
Initially seeing a function having 6 else if blocks doing some checks
with 'in1' and 'in2's members and extracting the same and assigning to
some other structure, I felt bit difficult to differentiate this
particular 'else if' blocks with others on the first glance. After all
mental imaging of 'in1' and 'in2', I found that 'foo... this is just
avoiding revert the range'

What is our stance on 'revert range' combining.

Currently 'combine_ranges' for in1(5,9) in2(10, 6) sets *output to
(5,9), is it correct? I feel we should return FALSE without changing the
like we do for (5, 9) and (17, 26).

With regards
Kamesh Jayachandran

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 31 09:05:05 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.