This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/50160] vector<bool> comparison very slow (no specialisation)
- From: "marc.glisse at normalesup dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 23 Aug 2011 18:35:57 +0000
- Subject: [Bug libstdc++/50160] vector<bool> comparison very slow (no specialisation)
- Auto-submitted: auto-generated
- References: <bug-50160-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160
--- Comment #7 from Marc Glisse <marc.glisse at normalesup dot org> 2011-08-23 18:35:57 UTC ---
If I understand correctly, operator< is supposed to give a lexicographic order,
and vector<bool> stores {true,false,false} as 1 and {false,false,true} as 4, so
we can't just make operator< compare chunks. Reversing the order of the bits in
an unsigned long is a bit complicated, although it would still lead to code
faster than the current (easiest would be to compare byte by byte, and mirror
each byte using a table).
But you don't seem particularly interested in using the lexicographic order, is
that true? In that case you could try and specify some other order to std::map,
say comparing hashes ;-) I understand that the lexicographic order of the
chunks would be a fine order, but I don't think it can be exposed. I haven't
thought about the potential drawbacks of implementing vector<bool> backwards.