Для собственных нужд накидал LRU-cache, который вроде делает то, что мне нужно и так как мне нужно. Но так как я не часто пишу на C++ именно что библиотеки, а в то же время написание библиотек вообще сильно оттедельный навык, у меня есть некоторые сомнения в том, что все реализовано в соответствии с современными веяниями. Сам кеш тут, минимальный поддерживаемый стандарт C++11. Буду благодарен за дополнения и замечания
первое — контейнеры заменить на интрузивные.
второе — почему в 'get()' используется 'key_type', а в 'put()' шаблонный параметр '_PutK'?
третье — раз уж в 'put()' у нас в качестве ключа используется шаблонный параметр '_PutK', почему ниже используется 'forward()' с параметром 'key_type'? по поводу 'value_type' вопрос тот же.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>первое — контейнеры заменить на интрузивные.
Не затруднит обрисовать плюсы? Мне хотелось получить поведение схожее с STL контейнерами в данном случае.
X>второе — почему в 'get()' используется 'key_type', а в 'put()' шаблонный параметр '_PutK'?
потому-что perfect forwarding иначе работать не будет
X>третье — раз уж в 'put()' у нас в качестве ключа используется шаблонный параметр '_PutK', почему ниже используется 'forward()' с параметром 'key_type'? по поводу 'value_type' вопрос тот же.
Здравствуйте, kaa.python, Вы писали:
KP>Для собственных нужд накидал LRU-cache, который вроде делает то, что мне нужно и так как мне нужно. Но так как я не часто пишу на C++ именно что библиотеки, а в то же время написание библиотек вообще сильно оттедельный навык, у меня есть некоторые сомнения в том, что все реализовано в соответствии с современными веяниями. Сам кеш тут, минимальный поддерживаемый стандарт C++11. Буду благодарен за дополнения и замечания
Сильно вдумчиво не изучал, но глаз зацепился вот за этот фрагмент кода: ты повторно форвардишь key. Это не есть хорошо, поскольку после первого же раза от объекта может остаться один только панцирь. Ну и еще, я бы в подобном случае для реализации итератора использовал бы boost::iterator_adaptor — писанины меньше и результат надежнее.
P.S. Я не очень удачно выразился. Проблема, собственно, не в повторном форвардинге, а в том, что после форвардинга объект еще как-то используется.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, rg45, Вы писали:
R>Сильно вдумчиво не изучал, но глаз зацепился вот за этот фрагмент кода: ты повторно форвардишь key. Это не есть хорошо, поскольку после первого же раза от объекта может остаться один только панцирь.
Да, спасибо. Это уже было отловлено и поправлено на GitHub, тут забыл исправить
R> Ну и еще, я бы в подобном случае для реализации итератора использовал бы boost::iterator_adaptor — писанины меньше и результат надежнее.
Я знаю про него, но хотелось бы получить реализацию без каких бы то ни было внешних зависимостей.
Здравствуйте, kaa.python, Вы писали:
KP>Для собственных нужд накидал LRU-cache, который вроде делает то, что мне нужно и так как мне нужно.
Данная структура не является кэшем. Совсем. Я вижу лишь контейнер с ограниченным размером, который удаляет элементы с самым ранним доступом при помещении новых элементов чтобы не превысить установленный размер. Но это не кэш совсем. Такую структуру можно применять, например, для списка часто используемых файлов, но не для кэширования.
Теперь что такое кэш. Это — промежуточная структура данных для ускорения доступа к чему-либо за счёт более быстрого доступа или локального хранения часто используемых данных. Кэш может активно взаимодействовать с основными данными, для ускорения которых он предназначен, забирая новые порции при чтении, если их нету в кэше, или записывая обратно, если они вытесняются из кэша. Пример этого — кэш файловой системы или кэш данных БД, а также кэши ОЗУ в CPU.
Так что чтобы это превратить в кэш, надо как минимум добавить возможность взаимодействовать с основными данными.