using and ambiguous call

[valoh]

Hi,

is this legal c++ code?

template <typename BaseTstruct A
{
BaseT& this_() { return *static_cast<BaseT*>(this); }

template <typename Tvoid Foo() { this_().Bar<T>(); }
template <typename Tvoid Bar() { }
template <typename Tvoid Bar(i32) { }
};

struct B : public A<B>
{
using A<B>::Bar;

template <typename Tvoid Bar() { }
};
//..

B test; test.Foo<int>();

when using such a construction I got mixed results on various
compiler. Often I get an ambiguous call to overloaded function error
(A<B>::Bar() vs B::Bar()). Sometime it seem to make a difference when
using template member function or non-template member function.

If it is not legal, why not? Any ideas for good workarounds? I have
template member functions for which i want default implementations and
helpers/wrappers in the base class. Several directly from this base
class derived classes only implementing a subset of the default
implementation. Any ideas?

[Victor Bazarov]

va***@krautgames.de wrote:

is this legal c++ code?

template <typename BaseTstruct A

'BaseT' is a bad name. I would probably call it 'WrappedT'.

{
BaseT& this_() { return *static_cast<BaseT*>(this); }

This can have undefined behaviour if 'BaseT' isn't related to
'A<BaseT>', you realise that of course...

>
template <typename Tvoid Foo() { this_().Bar<T>(); }

It seems that you're missing the keyword 'template' here:

... { this_(). template Bar<T>(); }
.. ^^^^^^^^

but I can be wrong.

template <typename Tvoid Bar() { }
template <typename Tvoid Bar(i32) { }
};

struct B : public A<B>
{
using A<B>::Bar;

template <typename Tvoid Bar() { }
};
//..

B test; test.Foo<int>();

when using such a construction I got mixed results on various
compiler. Often I get an ambiguous call to overloaded function error
(A<B>::Bar() vs B::Bar()). Sometime it seem to make a difference when
using template member function or non-template member function.

If it is not legal, why not? Any ideas for good workarounds? I have
template member functions for which i want default implementations and
helpers/wrappers in the base class. Several directly from this base
class derived classes only implementing a subset of the default
implementation. Any ideas?

Try it with all those compilers after adding the keyword 'template',
although I am not sure how it should affect the outcome. It's just
a hunch.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[valoh]

On Jan 9, 4:03 pm, "Victor Bazarov" <[e-mail]:

{
BaseT& this_() { return *static_cast<BaseT*>(this); }

This can have undefined behaviour if 'BaseT' isn't related to
'A<BaseT>', you realise that of course...

yes, but that's no problem for me. And this design/construction would
be extremely helpful if it would work :-(

template <typename Tvoid Foo() { this_().Bar<T>(); }

It seems that you're missing the keyword 'template' here:

... { this_(). template Bar<T>(); }
. ^^^^^^^^

but I can be wrong.

[...]

Try it with all those compilers after adding the keyword 'template',
although I am not sure how it should affect the outcome. It's just
a hunch.

doesn't change anything :-(

Any other ideas/workarounds? Any c++ standard gurus who can at least
verify if it should work?

[valoh]

On Jan 10, 10:14 am, James Kanze <[e-mail]:

Of the compilers I have available, two (g++ and Sun CC) have no
problems with your code, calling B::Bar(), as expected. VC++
seems to have problems with the using declaration, which results
in the ambiguity you mention. (It would seem that the compiler
is including all of the functions Bar from the base class,
rather than just those which aren't hidden.) Drop the using,
however, and it works. This is a bug, but the simple
work-around would be to drop the using, and also define Bar(i32)
in B.

Without all the member functions as templates it compiles on vc++,
too. But as vc++ is my main development platform it's really annoying.
The idea was to define default behaviour plus some wrappers in the
base class and only define a subset in several derived classes. When
dropping the using, the wrapper methods will not be resolved so again
copy-paste is needed which I wanted to prevent with this construction
in the first place :-)

Thanks for the help. At least I'm now convinced that this would be a
really nice pattern exactly fitting my needs and I have to see how to
convince the vc++ with a least worst workaround :-( well, nothing a
macro can't solve...