From: Mycroft Holmes on
On Mar 3, 5:34 pm, "Bo Persson" <b...(a)gmb.dk> wrote:
>
> In your case, I believe there is a workaround in using a pointer to
> function in place of the function itself. Hardly worth stopping the
> release while waiting for the real fix.
>

let me just point out that we have some cases where there's actually
_no_ workaround:
surely you can cast/store the function pointer, but this implies that
you know the exact function signature, which defeats the original
purpose of the example.

here's the shortest real usage case I was able to assemble: when you
erase an element from a container, but need to keep the iterator
valid, depending on the container you'd write i=c.erase(i) or c.erase(i
++).
in our library we have these lines somewhere:


template <typename container_t, typename iterator_t, typename base_t>
inline void erase_gap2(container_t& c, iterator_t& i, iterator_t
(base_t::*)(iterator_t))
{
i = c.erase(i);
}

template <typename container_t, typename iterator_t, typename base_t>
inline void erase_gap2(container_t& c, iterator_t& i, void (base_t::*)
(iterator_t))
{
c.erase(i++);
}

template <typename container_t>
inline void erase_gap(container_t& c, typename container_t::iterator&
i)
{
erase_gap2(c, i, &container_t::erase);
}

this example is not 100% relevant, because erase is not overloaded
with iterator&&, so it will work (well... I think...) even in VC2010.
however it's impossible to put an explicit cast around cont::erase.
From: Bo Persson on
Mycroft Holmes wrote:
> On Mar 3, 5:34 pm, "Bo Persson" <b...(a)gmb.dk> wrote:
>>
>> In your case, I believe there is a workaround in using a pointer to
>> function in place of the function itself. Hardly worth stopping the
>> release while waiting for the real fix.
>>
>
> let me just point out that we have some cases where there's actually
> _no_ workaround:
> surely you can cast/store the function pointer, but this implies
> that you know the exact function signature, which defeats the
> original purpose of the example.
>
> here's the shortest real usage case I was able to assemble: when you
> erase an element from a container, but need to keep the iterator
> valid, depending on the container you'd write i=c.erase(i) or
> c.erase(i ++).
> in our library we have these lines somewhere:
>
>
> template <typename container_t, typename iterator_t, typename
> base_t> inline void erase_gap2(container_t& c, iterator_t& i,
> iterator_t (base_t::*)(iterator_t))
> {
> i = c.erase(i);
> }
>
> template <typename container_t, typename iterator_t, typename
> base_t> inline void erase_gap2(container_t& c, iterator_t& i, void
> (base_t::*) (iterator_t))
> {
> c.erase(i++);
> }
>
> template <typename container_t>
> inline void erase_gap(container_t& c, typename
> container_t::iterator& i)
> {
> erase_gap2(c, i, &container_t::erase);
> }
>
> this example is not 100% relevant, because erase is not overloaded
> with iterator&&, so it will work (well... I think...) even in
> VC2010. however it's impossible to put an explicit cast around
> cont::erase.

Ok, I haven't tried your exact case, but was fiddling with the
std::thread interface, trying a constructor like

template<class _FunctionT, class _ArgT>
thread(_FunctionT&& _Function, _ArgT&& _Arg);

where thread(f, x) gave the same problem, but thread(&f, x) compiled
ok.



Bo Persson



From: Mycroft Holmes on
Hi again,

the problem has evolved into some sort of language dispute :)
I'm still convinced it's a bug, but I may need some help from a "T&&"
expert...

https://connect.microsoft.com/VisualStudio/feedback/details/536430/visual-studio-2010-compiler-bug-pointer-to-overloaded-member-function-with-t#tabs

From: David Lowndes on
>the problem has evolved into some sort of language dispute :)

It seems odd that Jonathan said it was a bug while Ulzii says it's (by
the dreaded) "by design" - perhaps he's saying that the design is
wrong :)

I'd reply and point out that Jonathan has already said it's a bug.

Have you tried a simple example with the Comeau online compiler - if
that will compile it ok, point that out in your reply to MS - it's
usually right.

Dave
From: Mycroft Holmes on
On Mar 30, 12:13 pm, David Lowndes <Dav...(a)example.invalid> wrote:

> I'd reply and point out that Jonathan has already said it's a bug.

good idea, I'll do.


> Have you tried a simple example with the Comeau online compiler - if
> that will compile it ok, point that out in your reply to MS - it's
> usually right.

no, because Comeau does not support rvalue references (afaik).