Browse thread
Hash clash in polymorphic variants
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Kuba Ober <ober.14@o...> |
| Subject: | Re: [Caml-list] Hash clash in polymorphic variants |
> > > > ISTR advice that constructors sharing the first few characters should > > > > be avoided in order to reduce the likelihood of clashing hash values > > > > for polymorphic variants. Is that right? > > > > > > I don't think it's worth worrying about. > > > > I'm interested in automatically translating the GL_* enum from OpenGL > > into > > polymorphic variants. So although it is generated code I have little > > I presume you're worried about the bindings clashing internally rather than > someone who uses the library happening to use a variant that clashes? > > You can do something about it - when you're generating your bindings, you > can use the hash_variant() C function to detect the collisions yourself. If > you detect one, you can either issue *your own* warning while generating > the bindings allowing you to specify specific renaming for the program > generating your bindings or you could append digits to the names until the > collisions disappear (which is likely, though not guaranteed, to happen > quickly). > > It's slightly ugly, but then the possibility of collisions in the first > place is IMHO ugly too! Are those collisions of any real importance? I mean, do they break anything? If all they do is imply linearly searching a list of a few elements, for the colliding entry, then it's a non-issue? Cheers, Kuba