From: Kuba Ober <ober.14@osu.edu>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Hash clash in polymorphic variants
Date: Fri, 11 Jan 2008 08:30:29 -0500 [thread overview]
Message-ID: <200801110830.29988.ober.14@osu.edu> (raw)
In-Reply-To: <003a01c853d1$718d8730$9201a8c0@countertenor>
> > > > 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
next prev parent reply other threads:[~2008-01-11 13:30 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-10 17:09 Jon Harrop
2008-01-10 20:35 ` [Caml-list] " Eric Cooper
2008-01-10 21:24 ` Jon Harrop
2008-01-10 21:40 ` David Allsopp
2008-01-11 13:30 ` Kuba Ober [this message]
2008-01-11 13:48 ` Jon Harrop
2008-01-11 16:14 ` Kuba Ober
2008-01-11 18:40 ` David Allsopp
2008-01-14 12:20 ` Kuba Ober
2008-01-14 14:44 ` Stefan Monnier
2008-01-14 14:56 ` [Caml-list] " Kuba Ober
2008-01-14 15:37 ` David Allsopp
2008-01-14 15:44 ` Kuba Ober
2008-01-14 16:03 ` David Allsopp
2008-01-14 15:45 ` Stefan Monnier
2008-01-15 3:36 ` [Caml-list] " Jacques Garrigue
2008-01-15 4:59 ` Jon Harrop
2008-01-15 9:01 ` Jacques Garrigue
2008-01-15 18:17 ` Jon Harrop
2008-01-15 19:20 ` Gerd Stolpmann
2008-01-15 22:04 ` Jon Harrop
2008-01-16 13:48 ` Kuba Ober
2008-01-16 15:02 ` Dario Teixeira
2008-01-16 19:00 ` Jon Harrop
2008-01-17 13:09 ` Kuba Ober
2008-01-18 5:33 ` Kuba Ober
2008-01-18 5:19 ` Kuba Ober
2008-01-18 5:39 ` Kuba Ober
2008-01-16 3:26 ` Jacques GARRIGUE
2008-01-16 3:34 ` Yaron Minsky
2008-01-16 3:42 ` Jon Harrop
2008-01-16 4:40 ` Jon Harrop
2008-01-16 16:03 ` Eric Cooper
2008-01-16 10:50 ` Richard Jones
2008-01-14 17:14 ` Jon Harrop
2008-01-14 17:36 ` Alain Frisch
2008-01-11 0:15 ` [Caml-list] " Jacques Garrigue
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200801110830.29988.ober.14@osu.edu \
--to=ober.14@osu.edu \
--cc=caml-list@yquem.inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox