LeetCode 146: LRU Cache I
Use size_t for sizes
Although the LeetCode question specifies that the constructor takes an int capacity, using an int to hold a size is not appropriate for two reasons:

int might not be big enough to handle all possible sizes that fit into the available memory.
int is signed, and now you have to deal with potentially negative numbers.

Also note that the standard library uses size_t for things like .size(), and the result of the sizeof operator is also a size_t. So it's best to internally store the capacity as a size_t. This will avoid compiler warnings about comparisons between signed and unsigned values.
Use types consistently
The one place you use size_t is in std::list&lt;size_t&gt; lru. But here, the list is actually holding keys. Everywhere else you write int key, so you should write std::list&lt;int&gt; lru here, otherwise your cache might not work correctly when using negative numbers for keys. The LeetCode question does not say whether or not negative keys are allowed, it only mentions only positive values are stored.
Make helper functions private
Helper functions like update() and clear() are not part of the public API as specified by the LeetCode problem. So make them private.
Use proper names
The function clear(), despite its name and even the comment above it, does not erase the cache. Instead, it just removes the least recently used element. Make sure the name (and also the comment) reflects this. I would name it something like pop_lru(), or perhaps just pop().
Also, the name update() does not match the comment above it. I would remove the comment, and give a more descriptive name: make_most_recent().
Useless use of const
It does not make sense to have a function return const void. Just write void.