Live data from Hacker News

Show HN: A header only C++11 LRU Cache template class, with no dependencies

github.com

11–20 of 31 posts

Re: Show HN: A header only C++11 LRU Cache template class, with no dependencies

#13
post #6
post #5

Earlier 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.

Cool. Thanks for the edification.

Re: Show HN: A header only C++11 LRU Cache template class, with no dependencies

#14
post #8
post #2

Can 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…

Gotcha. Thanks for the detailed explanation.

Re: Show HN: A header only C++11 LRU Cache template class, with no dependencies

#15
post #10

Not 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 block the copy constructors.

Re: Show HN: A header only C++11 LRU Cache template class, with no dependencies

#17
post #12

So it's C++11 but still uses naked pointers...

the naked pointers are inside an internal kv namespace and are a convenience/carry over from the previous implementation (I've covered the justification for the way it's written in a comment above).

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

#19
post #15
post #10

Not 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…

You could have used std::list iterators instead of raw pointers to a node in the map to implement that.

Re: Show HN: A header only C++11 LRU Cache template class, with no dependencies

#20
post #19
post #15

Earlier 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.

yeah, saw the gist posted by quinnftw. that actually is a better way to do what I'm doing. Will update that along with the

cache.remove(const Key& k, F deleteCallback) method.

Thanks for the feedback

Post reply on HN