包装递归可变参数模板类会更改行为。 为什么？

Question

Hopefully this will intrigue some in the community. Hope it's not too obvious, because I'm not sure what's going on. I created variadic template class with a recursive definition, mostly as an interesting self-challenge. Sort of like a tuple, this class creates unordered_maps of unordered_maps, to arbitrary depth and with with arbitrary key types at each layer. So you could, for example, create nested_map<int, std::string, float, int> and then set it with map["fred"][3.4][42] = 35; Here's the code - not too crazy.

template<typename T, typename K, typename ... KS> struct nested_map_base : std::unordered_map<K, T>
{
  T &operator[](const K &key)
  {
    // just to verify we get to the bottom of things recursively
    std::cout << "base: key = " << key << std::endl;

    return this->std::unordered_map<K, T>::operator[](key);
  }
};

template<typename T, typename New_K, typename K, typename ... KS>
struct nested_map_base<T, New_K, K, KS ...>
: std::unordered_map<New_K, nested_map_base<T, K, KS...>>
{
  nested_map_base<T, K, KS...> &operator[](const New_K &new_key)
  {
    // just for debugging and to demonstrate that it's working
    // for purposes of this question
    std::cout << "midway: key = " << new_key << std::endl;

    return this->std::unordered_map<New_K, nested_map_base<T, K, KS...>>::operator[](new_key);
  }
};

Works OK. Running the following code, get's the expected output -

std::cout << "Method1:" << std::endl << std::endl;
nested_map_base<int, std::string, double, int> test_nest;
std::cout << "insert" << std::endl;
test_nest["leonard"][4.8][45] = 111;
std::cout << "retrieve" << std::endl;
int &answer = test_nest["leonard"][4.8][45];
std::cout << "Aanswer should be 111. Answer is " << answer << std::endl << std::endl;

produces -

Method1:

insert
midway: key = leonard
midway: key = 4.8
base: key = 45
retrieve
midway: key = leonard
midway: key = 4.8
base: key = 45
Aanswer should be 111. Answer is 111

Neat. Then I thought I'd like to wrap it in an outer class to keep the implementation private, so I just started like this -

template<typename datum_type, typename ... keys> class nested_map
{
private:
  nested_map_base<datum_type, keys ...> backing_store;

public:
  template<typename Base_key, typename ... KS> auto operator[](const Base_key &key)
  {
    return backing_store[key];
  }
};

Nothing much there, and at first it seemed to work, but the following code produces different results -

std::cout << "Method2:" << std::endl << std::endl;
nested_map<int, std::string, double, int> test_nest;
std::cout << "insert" << std::endl;
test_nest["leonard"][4.8][45] = 111;
std::cout << "retrieve" << std::endl;
int &answer = test_nest["leonard"][4.8][45];
std::cout << "Answer should be 111. Answer is " << answer << std::endl << std::endl;

It produces this -

Method2:

insert
midway: key = leonard
midway: key = 4.8
base: key = 45
retrieve
midway: key = leonard
midway: key = 4.8
base: key = 45
Answer should be 111. Answer is 0

Recursive variadic template meta-programming is filled with pitfalls, and there are reasons things don't get wrapped very often, so I wasn't shocked that the wrapped one didn't work, but what did surprise me is HOW it didn't work. It recursed as expected, right down to the std::unordered_map that contained the terminal datum type. In the debugger a reference to an int was recovered from the terminal map, and it was set to 111 in the simple test code. The fact that you see the keys being recursed a second time indicates that the retrieval process seemed to be working as well, but the reference was to a zero-valued int. Curious.

I'm digging deeper in the debugger to see if, for example, the actual address value of the set reference is the same as the reference used to retrieve. The only way that they could be different I would think is if for example, the penultimate recursive layer was returning a temp of the final layer, in stead of a reference to the one in the data structure. Or maybe in the wrapped case they're all temps in stead of references... something like that, but it the wrapping is so light, it doesn't seem possible. So I'll add comments if I find out more, but I thought I'd throw it out to the community to see if there is something that different sets of eyes can tease out by inspection.

Answer 1

There is a section on auto-returning functions in the Cppreference page on Template Argument Deduction that describes the rules when auto is used as return for functions.

Template argument deduction is used in declarations of functions, when deducing the meaning of the auto specifier in the function's return type, from the return statement.

For auto-returning functions, the parameter P is obtained as follows: in T , the declared return type of the function that includes auto, every occurrence of auto is replaced with an imaginary type template parameter U . The argument A is the expression of the return statement, and if the return statement has no operand, A is void() . After deduction of U from P and A following the rules described above, the deduced U is substituted into T to get the actual return type.

That would explain why auto& works and auto does not.