What is wrong in this code?
#include <map>
template<typename T>
struct TMap
{
typedef std::map<T, T> Type;
};
template<typename T>
T test(typename TMap<T>::Type &tmap_) { return 0.0; }
int _tmain(int argc, _TCHAR* argv[])
{
TMap<double>::Type tmap;
tmap[1.1] = 5.2;
double d = test(tmap); //Error: could not deduce template argument for T
return 0;
}
That is non-deducible context. That is why the template argument cannot be deduced by the compiler.
Just imagine if you might have specialized TMap as follows:
template <>
struct TMap<SomeType>
{
typedef std::map <double, double> Type;
};
How would the compiler deduce the type SomeType, given that TMap<SomeType>::Type is std::map<double, double>? It cannot. It's not guaranteed that the type which you use in std::map is also the type in TMap. The compiler cannot make this dangerous assumption. There may not any relation between the type arguments, whatsoever.
Also, you might have another specialization of TMap defined as:
template <>
struct TMap<OtherType>
{
typedef std::map <double, double> Type;
};
This makes the situation even worse. Now you've the following:
TMap<SomeType>::Type = std::map<double, double>. TMap<OtherType>::Type = std::map<double, double>. Now ask yourself: given TMap<T>::Type is std::map<double, double>, how would the compiler know whether T is SomeType or OtherType? It cannot even know how many such choices it has, neither can it know the choices themselves...
I'm just asking you for the sake of thought-experiment (assuming it can know the complete set of choices).
struct Foo { typedef int type; typedef char bogus; }; and stuct Bar { typedef int type; typedef double bogus; };. Now you want to specialize on T::type = int and use T::bogus. It just makes no sense. –
Denial T in typedef std::map <T, T> Type; and the one in template<typename T> struct TMap can be differents? I mean it seems obvious to me that if you call the test function with an argument of type TMap<double>::Type (tmap in the OP's example) then the prototype of the function test to be called is T test(typename TMap <double>::Type &tmap_) { return 0.0; }. Because the T in template<typename T> struct TMap and in typedef std::map<T, T> Type; are the same –
Lundell _tmain, tmap is defined to be of type std::map<double, double>. The second line doesn't matter, and the third line breaks for this reason (which I'm not sure anyone pointed out yet): the template definition test does NOT specify a binding that test's T template argument must always or ever be a double simply because it returns 0.0. The literal double return value 0.0 is semantically not connected to T. –
Phi T must be double and therefore test(tMap<double>::Type), a.k.a. test(std::map<double, double>) is to be instantiated, there is technically no evidence for the compiler to go ahead and instantiate it because the spec does not allow the compiler to deduce it from the 0.0. And, so I suppose this is a case of "eliminate potentially exponential time behavior in the compiler" which is a very sound strategy, but I do lament that this is getting close to the core of the notion that "TMP sucks" –
Phi Exactly what the compiler error message says: in
TMap<T>::Type, T is not deduceable according to the
standard. The motivation for this is probably that it isn't
technically possible to implement: the compiler would have to
instantiate all possible TMap<T> in order to see if one (and
only one) matched the type you passed. And there is an
infinite number of TMap<T>.
std::map is same or somehow depending on the type of the TMap. Its therefore not feasible. –
Batman test overloads and would have to analyse each parameter in turn, seeing that a Type typedef inside a TMap were required, and inversely-match that against the passed argument. In the final step, it could then match the template arguments used in TMap against the available types in the map parametrisation …. –
Raeraeann Type is defined in that expansion. (Note that Type could easily be something like typedef typename SomeOtherTemplate<T>::Type Type;, or even something more complex.) –
Agglutinative std::map doesn't depend on the type argument of TMap, how could that be possible? All possible types would be valid candidates for TMap, then. –
Batman A<N>::B so that B is typedef'ed to int iff N represents an algorithm that halts) –
Moskow Even you have:
TMap<SomeType>::Type = std::map<double, double>.
But before you call test(tmap)
TMap<double>::Type tmap;
tmap[1.1] = 5.2;
double d = test(tmap);
You already have it declared as
TMap<double>::Type tmap;
why this information can not be utilized. #typedef is not just simple string replacement.
I don't think "we can't do this" argument is correct. If we slightly modify this example, the compiler is happily deducing arguments for us.
template<typename T>
struct TMap //...
template <class T>
struct tmap_t : TMap<T>::Type {};
template<typename T>
T test(tmap_t<T> tmap) // ...
tmap_t<double> tmap; // ...
double d = test(tmap); // compiles just fine.
I don't see a huge difference between the original example and mine. The real issue here seems that C++ treats typedefs and type declarations differently
Is this a good thing?
© 2022 - 2024 — McMap. All rights reserved.
Tmap<T>::Typeis the most commonly known example of a non-deduced context. The linked Q&A explains this particular case in a lot of detail. – Feaster