Subject: Re: [boost] Any interest in Compile Time Hash Containers library?
From: John Maddock (jz.maddock_at_[hidden])
Date: 2019-01-24 08:49:24
While I don't personally have a use for it, I can see that someone will,
and besides, it's kind of cool that you can do that ;)
Question: would the interface be better specified with a constexpr
initializer-list constructor rather than templating on an array of
data?Â That way you would have complete control of memory layout as
well?Â Or am I misinterpreting things?
On 21/01/2019 13:39, Ivan Matek via Boost wrote:
> Hi everybody, my first message, I hope I do not mess this up.
> I was contemplating writing a Compile Time Hash Containers library and I
> wrote a test implementation for sets and benchmarked it against mostly
> ska:: sets since they are the best.
> Document is here:
> It is quite long, but it aims to provide a introduction to the problem for
> people unfamiliar with details of hashing, and also it goes into a lot of
> discussions, if you care just about the numbers you can skip the "boring
> My interpretation of benchmarks is that it performs very well in some
> cases, decently in others, but I am biased. :)
> Code is not available online since I do not want to dump a test project
> online without extensive documentation, but if somebody has a problem that
> may be benefited by this test implementation feel free to let me know, I
> would be happy to get some real world feedback on prototype.
> Limitations is that test implementation only works for sets, so no maps and
> if your objects are not integers you will probably not get much speedup.
> Also if your set has more than 100ish items GCC will run out of memory and
> VC++ does not compile code at all, so clang is the only way for most use
> cases today.
> One more disclaimer is that I do not want this library to be some beast
> like ranges that takes years to implement, so if after reading the document
> you consider implementation quite basic I won't be offended :) In other
> words I feel that library like this although relatively simple compared to
> regular Boost libraries can provide quite a lot of benefit for some
> usecases where people really really care about performance of hash
> containers where values are known during compile time.
> I know you can not predict the future of an unimplemented library, but I
> would be happy with some general feedback, and if you think this library
> would be nice boost proposal I would be interested in some pointers wrt how
> to proceed.
> If somebody wonders how user code looks at the moment:
> #include "cxhash_set.h"
> // also could be a result of constexpr function, no need for initializer
> static constexpr std::array<int, 20>
> int main()
> cxhash_set<ints> ints_set;
> // contains could(should be?) static, but for now it is "normal" member
> std::cout << std::boolalpha << ints_set.contains(21) << std::endl;
> std::cout << std::boolalpha << ints_set.contains(22) << std::endl;
> P.S. feel free to comment in the google doc, I actually find mailing lists
> quite limited when it comes to prolonged and or detailed discussions.
> Maybe we can ping Alexandrescu for an instance of dlang forums, so we get a
> better discussion tools, and he gets a way to convert us to D. :)
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk