Why not just keep a set containing all previously seen values? Then you can find duplicates with a linear scan.
--Sean Silva On Wed, Jul 18, 2012 at 6:11 PM, Richard Trieu <[email protected]> wrote: > On Wed, Jul 18, 2012 at 5:41 PM, Ted Kremenek <[email protected]> wrote: >> >> Hi Richard, >> >> I think this checking is quadratic, n(n+1)/2. > > Yes it is. It does perform a check between each enum in the worst case. > >> >> This might be fairly expensive on a large set of enums. Do you have any >> performance numbers? > > I haven't run any performance tests. I will try running some when I get the > chance. > >> >> I agree that it is a good checking, but the way it is implemented is >> likely to be noticeably slow on some (important) cases. > > How many elements in an enum would be in these important cases? >> >> >> Ted >> >> On Jul 18, 2012, at 4:46 PM, Richard Trieu <[email protected]> wrote: >> >> http://llvm.org/bugs/show_bug.cgi?id=6343 >> >> Warn on enum elements that are assigned values already in use. This is >> based on the misconception that elements not given a value will be given the >> next smallest, unused value. Instead, elements are assigned 1 more than the >> previous value. Some example code this warning will catch: >> >> enum { A, B, C, Aref = A, count }; >> Both B and count will have value 1. >> >> enum { A, B, C, D = -1, E, F }; >> A = E = 0 >> B = F = 1 >> >> This warning found one such issue in LLVM that was fixed in r160465. >> <duplicate-enum.patch>_______________________________________________ >> cfe-commits mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >> >> > > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
