[Development] RFC: new moc feature

Marc Mutz marc.mutz at kdab.com
Mon Dec 7 15:28:17 CET 2015


On Monday 07 December 2015 13:15:13 Knoll Lars wrote:
> On 05/12/15 21:37, "Development on behalf of Marc Mutz" <development-
bounces at qt-project.org on behalf of marc.mutz at kdab.com> wrote:
> >On Saturday 05 December 2015 20:20:27 Sean Harmer wrote:
> >> I was
> >> just wondering if we could get it down to the theoretical ideal of a
> >> single integer comparison mapped into the finite set of strings in use.
> >> Seems not, without some non-neglible effort.
> >
> >man 1 gperf ?
> 
> Just as a side note: While perf ensures there’s no collisions between valid
> keys in the hash table, you still end up doing one string comparison in
> the end to ensure that your input string matches the key.

As you always must, because every hash function that maps an infinite-domain 
object such as a string into an object with finite domain (e.g. int) must 
exhibit collisions which need to be handled by comparing the actual objects.

AFAIU, the original idea was to assign an enum value for each unique string (= 
property = property name) automatically, and use the enums instead of the 
strings inside the implementation. In that case, the validation would happen 
at the point of converting the string or whatever is left as a non-ID ID to 
the enum value, and further code could depend on enum value equality alone.

But if you use strings in the implementation, and use the IDs only for quick 
comparision, you cannot rule out that two properties' IDs collide. The 
compiler won't help, since in general the collision may not be from objects at 
the same depth of hierarchy, so the compiler may not see the collision, as the 
equal values then appear in separate switch statements.

But it could be that I misunderstand the situation completely :)

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts



More information about the Development mailing list