deep typedefs causing a problem?
Burc Arpat
i receive a rather weird ( at least, imho ) error using intel c++ 7.1 and
gcc 3.2 using stlport ( although i did get similar errors using gcc's own
stl )
here's the situation: i have a template class called search_table_t<T1,T2>.
this class has an embedded struct called cell_type. search_table_t has-a
vector of vectors of cell_type. when i try to sort a sub-vector using
std::sort and a custom comparator, this is what i get ( i removed the
allocators from the error message for clarity ):
--- cut from here ---
no instance of function template
"pm::sehc::detail::search_table_cell_less_f::operator()" matches the
argument list
argument types are:
_STL::vector<pm::sehc::search_table_t<pm::real_t,
pm::index_t>::cell_type>::value_type,
_STL::vector<pm::sehc::search_table_t<pm::real_t,
pm::index_t>::cell_type>::value_type
--- cut from here ---
the comparator search_table_cell_less_f lives in pm::sehc::detail namespace
and is defined like this:
--- cut from here ---
struct search_table_cell_less_f {
template <
typename NodeT,
typename IndexT
>
bool
operator()(const typename search_table_t<NodeT, IndexT>::cell_type& _a,
const typename search_table_t<NodeT, IndexT>::cell_type& _b)
const {
return _a.node < _b.node;
}; // operator()
}; // search_table_cell_less_f
--- cut from here ---
although it was unlikely to be the reason, i tried defining operator()
without any const identifiers, etc. just to make sure. still didn't work.
this doesn't make any sense to me as the cited argument type, i.e. the
value_type of the std::vector should expand to the embedded cell type but
apparently it does not
strange enough, if i define search_table_cell_less_f like the this:
--- cut from here ---
struct search_table_cell_less_f {
template <class CellT>
bool
operator()(const CellT& _a,
const CellT& _b) const {
return _a.node < _b.node;
}; // operator()
}; // search_table_cell_less_f
--- cut from here ---
then it works w/o any problems. so, it basically looks like many levels of
typedefs and namespaces confuse the compiler. to check this, i tried
removing the detail namespace entirely but that didn't work either. so, the
question is, what is the problem here? am i doing something wrong or is it
just the compiler?
thanks in advance...
burc arpat
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Ben Hutchings
<snip>
The problem with this is that the compiler cannot deduce the template
arguments from the types of the function arguments. The error messages
show that it remembers where the type of the function arguments was
declared and so could in theory match them against the dependent types
given in the function template declaration, but in general it cannot know
that there are unique template arguments for which the function parameter
types would match the function arguments; furthermore the standard says
deduction is not done in this case.
> strange enough, if i define search_table_cell_less_f like the this:
>
> --- cut from here ---
> struct search_table_cell_less_f {
> template <class CellT>
> bool
> operator()(const CellT& _a,
> const CellT& _b) const {
> return _a.node < _b.node;
> }; // operator()
> }; // search_table_cell_less_f
> --- cut from here ---
This is not at all strange - the template parameter can trivially be
deduced in this case.
> then it works w/o any problems. so, it basically looks like many levels of
> typedefs and namespaces confuse the compiler.
<snip>
No. The standard says that template argument deduction for functions is
not done in cases such as the first operator() definition above.
Burc Arpat
so, i should just forget about doing it the way i originally coded it, then,
right? oh well, thanks for the explanation. would you mind letting me know
where the standard explains this so that i can have a look myself and learn
better? thanx...
burch
Ben Hutchings
> > "...furthermore the standard says deduction is not done in this case."
>
> so, i should just forget about doing it the way i originally coded it, then,
> right? oh well, thanks for the explanation. would you mind letting me know
> where the standard explains this so that i can have a look myself and learn
> better? thanx...
Section 14.8.2.4, paragraph 4.