views:

227

answers:

1

Yeah, the title can scare babies, but it's actually quite straightforward.

I am trying to store a function pointer to a specialized template function, namely boost::make_shared (boost 1.41), as illustrated:

boost::shared_ptr<int> (*pt2Function)() = boost::make_shared<int>;

However, it won't compile (GCC 4.4.1) due to the fact that boost::make_shared has the following two specializations which the compiler can't tell apart in this context:

template< class T > boost::shared_ptr< T > make_shared()
...
template< class T, class... Args > boost::shared_ptr< T > make_shared( Args && ... args )

The error, for reference:

In function ‘int main()’:
error: converting overloaded function ‘make_shared’ to type ‘class boost::shared_ptr<int> (*)()’ is ambiguous
boost/smart_ptr/make_shared.hpp:100: error: candidates are: boost::shared_ptr<X> boost::make_shared() [with T = int]
boost/smart_ptr/make_shared.hpp:138: error:                 boost::shared_ptr<X> boost::make_shared(Args&& ...) [with T = int, Args = ]

If I comment out the non-variadic variation, the code compiles fine.

Does anyone know the proper syntax for resolving the ambiguity between two argument-less functions like this?

+2  A: 

Variadic template arguments mean you take 0..n template arguments, thus both your versions are matches.
You could resolve the ambiguity by adding another template parameter to the second version, so that it takes 1..n arguments.
Something like this should work:

template< class T, class Arg1, class... Args > 
boost::shared_ptr< T > make_shared(Arg1&& arg1, Args && ... args )

But as UncleBens correctly pointed out, you don't even need two versions. The following should be enough in your case:

template< class T, class... Args > 
boost::shared_ptr<T> make_shared(Args && ... args );

If you use only one template argument (i.e. T), you get the 0-argument version of make_shared().

Georg Fritzsche
It seems unclear to me, why the first overload is needed in the first place - one can "forward" zero arguments just as well?
UncleBens
Good point. Is it ok with you that i just added that?
Georg Fritzsche
Of course. However, these functions come from (a newer version of) the boost library. Perhaps they should be informed of the glitch?
UncleBens
Ok, so there isn't any "proper" way to do this. There is a hint in the boost headers as to why they have this stuff btw:"// Zero-argument versions // Used even when variadic templates are available because of the new T() vs new T issue"Well, if nothing else, the forwarding approach will suit my needs. It's not all that pretty. It makes my code depend on variadic parameters capabilities (decreasing portability slightly), but I can live with that. It'll do for now.
BTW, I can't quite figure out how to actually use this answer to solve my problem. Just to be sure, is the suggestion that I modify the boost headers?
Yep, until they fix it you have to either fix it in the header or write your own wrapper. With the comment you mention you should use the first solution i proposed.
Georg Fritzsche
... and i see no way to select the first version unambigiously, so wrapping probably won't work :/
Georg Fritzsche
Thanks for the effort. Confirming that it can't be done is useful enough by itself. And in the meanwhile I found out a way to accomplish my goals without using boost::make_shared at all :)
I believe in actual C++0x, this should resolve to the first overload, because the first template is more specialized than the second. (using the template specializations function type, we deduce `shared_ptr<T>()` against `shared_ptr<T>(U...)`. Deduction for each of the types in `U...` against `()` (empty list) will fail, and deduction of `<T>` in the return type will succeed in both directions, and `()` against `(U...)` will succeed (with U being empty). Thus the first template is at least as specialized for each type, and more specialized for `()`, thus it's more specialized as a result).
Johannes Schaub - litb
(in fact, my G++4.4.3 accepts it)
Johannes Schaub - litb
Interesting, i'll have to look that up. So... this seems to have been a g++ bug then?
Georg Fritzsche
@gf, yes looks like it was a GCC bug.
Johannes Schaub - litb