Show HN: A header only C++11 LRU Cache template class, with no dependencies
11–20 of 31 posts
Re: Show HN: A header only C++11 LRU Cache template class, with no dependencies
#12Re: Show HN: A header only C++11 LRU Cache template class, with no dependencies
#13Earlier quoted context omitted.
So in this case, headers-only is really just an approach to avoid compiling a separate library? More akin to literally including the source code in your source code, in the eyes on the compiler. All in the same object/library.
mostly: yes! :) Also, keep in mind that most of the library is templates, which need to go in the header files. BTW, most of boost is header-only :) e.g. boost/noncopyable.hpp would give you a header only equivalent of the NoCopy class I wrote. I've always felt weird about having to include some big-arse library for just using a simple container, so for things like this I prefer to write header-only versions.
Re: Show HN: A header only C++11 LRU Cache template class, with no dependencies
#14Can someone explain how this is headers-only? C/C++ are not my forte, but my limited interpretation of a "headers only" thing would be more along the lines of: it's only type definitions and preprocessor macros. It looks like there's plenty of actual method implementations being filled out there, but they just happen to be in a .hpp file instead of a .cpp file.
It means all the code is defined in-line in the header file, inside the class definition, instead of the more traditional method of using a header and an associated cpp file. A lot of the C++ standard library (STL) and Boost are header only (but not all) This means to use the code, all you need to do is #include the header file wherever you need it, rather than including a header file and either building a separate s…
Re: Show HN: A header only C++11 LRU Cache template class, with no dependencies
#15Not really sure why they reimplemented std::list. Also that NoCopy base class adds a vptr for no reason. And so do all those other virtual destructors. I personally wouldn't trust this code at first glance.
The reason for the specific implementation is to get constant time removal and remove-add_to_end operations. Truth be told, it is a hold-over from the previous implementation. I shall be writing benchmarks for this next up and shall revisit the decision on whether or not to use std::list soon-ish :)
The : private NoCopy is just to block the copy constructors.
Re: Show HN: A header only C++11 LRU Cache template class, with no dependencies
#16https://gist.github.com/Quinny/09e34afb1d187e43dea2f3c3b0c04...
Re: Show HN: A header only C++11 LRU Cache template class, with no dependencies
#17So it's C++11 but still uses naked pointers...
the TL;DR is that it is written the way it is to achieve constant time remove/remove_and_add_to_end operations which is not an erase+append but more like an unlink/relink operation.
Re: Show HN: A header only C++11 LRU Cache template class, with no dependencies
#18Not really sure why they reimplemented std::list. Also that NoCopy base class adds a vptr for no reason. And so do all those other virtual destructors. I personally wouldn't trust this code at first glance.
Re: Show HN: A header only C++11 LRU Cache template class, with no dependencies
#19Not really sure why they reimplemented std::list. Also that NoCopy base class adds a vptr for no reason. And so do all those other virtual destructors. I personally wouldn't trust this code at first glance.
the kv::List is not intended as a generic linked list implementation like std::list. The reason for the specific implementation is to get constant time removal and remove-add_to_end operations. Truth be told, it is a hold-over from the previous implementation. I shall be writing benchmarks for this next up and shall revisit the decision on whether or not to use std::list soon-ish :) The : private NoCopy is just to bl…
Re: Show HN: A header only C++11 LRU Cache template class, with no dependencies
#20Earlier quoted context omitted.
the kv::List is not intended as a generic linked list implementation like std::list. The reason for the specific implementation is to get constant time removal and remove-add_to_end operations. Truth be told, it is a hold-over from the previous implementation. I shall be writing benchmarks for this next up and shall revisit the decision on whether or not to use std::list soon-ish :) The : private NoCopy is just to bl…
You could have used std::list iterators instead of raw pointers to a node in the map to implement that.
cache.remove(const Key& k, F deleteCallback) method.
Thanks for the feedback