Hi all,
First of all thanks to Alberto Ganesh Barbati for being so kind to
explain the binding in various phases.
After leaving the code alone for one day, a solution occurred to me,
that is not really pretty, but at least it is working as expected.
Here is the revised code:
----------------------------------------------------------------------
// Code included from DefaultImplementation.hpp
namespace default_impl {
struct DefaultType { /* ... */ };
template<typename T>
void func(T const&);
template<>
inline void func(DefaultType const&) {
// .. do something ...
}
}
// Code included from Algorithm.hpp
namespace algorithm {
template<typename T>
void cool_algorithm_1(T const& value) {
using default_impl::func;
// ...
func(value);
// ...
}
template<typename T>
void cool_algorithm_2(T const& value) {
// ...
default_impl::func(value);
// ...
}
}
// Code included from Working.hpp
struct Working { /* ... */ };
namespace default_impl {
template<>
inline void func(Working const&) {
// .. do something else ...
}
}
// Code from Main.cpp
int main(int, char**) {
Working working;
algorithm::cool_algorithm_1(working);
algorithm::cool_algorithm_2(working);
return 0;
}
----------------------------------------------------------------------
My understanding of why this works as expected is that both calls to
func() bind to the primary template forward declaration of func(),
because "Specializations don't overload" (see [1]).
At link time the individual (implicitly specialized) calls to func()
resolve to the explicitly specialized versions of the function and the
code links flawlessly.
As I said in the introduction, this solution is not very pretty. The
first reason is the somewhat unintuitive semantics of function template
specializations (again "Specializations don't overload"), as explained
by Herb Sutter in his article "Why Not Specialize Function Templates?"
[1], and the second reason is that missing specializations are only
detected at link time and thus don't produce compiler errors as one
would expect, but rather linker errors that might be hard to track down.
If I have some time to spare I'll probably restructure the whole thing
to make use of the nice workaround mentioned in the abovementioned
article.
Best regards,
Kimon
[1] http://www.gotw.ca/publications/mill17.htm
--
[ See http://www.gotw.ca/resources/clcm.htm
for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
