Discussion:
some bugs in VS2010 RC
(too old to reply)
Mycroft Holmes
2010-02-25 10:22:01 UTC
Permalink
Hi all,

we have a large template-based set of headers; they are pretty much
standard compliant and we cross-compile with VS2005, VS2008, the intel
compiler and some versions of gcc. A few days ago we tested VS2010 RC
and we found the following problems:

(1) if a class has swap(T&) and swap(T&&) then in some cases we cannot
take a pointer to swap(T&).
the following sample shows that in ordinary code, the pointer can be
taken, but in a template it can't.
if you remove AAA::swap(AAA&&) it works.


template <typename T>
void fff(T& x, void (T::*)(T&))
{
}

template <typename T>
void fff(T& x)
{
fff(x, &T::swap);
}



struct AAA
{
void swap(AAA&)
{}

void swap(AAA&&)
{}

};


int main()
{
AAA aa;

void (AAA::*F)(AAA&) = &AAA::swap;

fff(aa);
}




(2) sometimes the compiler is unable to fill-it default template
parameters, and it emits...well... bizarre error messages.
in the sample below, if you write "BBB<this_t, roll_t, LENGTH>" it
works, if you write "BBB<this_t, roll_t>" it does not compile.




template <typename r1_t, typename r2_t, int LENGTH1 = r1_t::length,
int LENGTH2 = r2_t::length>
class BBB;


template <typename r1_t, typename r2_t, int LENGTH>
class BBB<r1_t, r2_t, LENGTH, 1>
{
typedef BBB<r1_t, r2_t, LENGTH, 1> this_t;

public:

BBB(int = 0)
{
}

static const int length = LENGTH;

// bug: VS2010 RC will complain if LENGTH is omitted...
// it says that 'length' is undefined

template <typename roll_t>
inline BBB<this_t, roll_t, LENGTH> operator<<(roll_t) const
{
return 0;
}
};



struct E1
{
static const int length = 1;
};

struct E2
{
static const int length = 2;
};



int main(int argc, const char* argv[])
{
BBB<E2, E1> a;
a << E1();
}



(3) we noticed that in error messages, the "template stack" is not
fully unrolled, so most times it's not easy to understand where
exactly the offending code is. e.g. if you have std::pair<void*,
void*>(0,0) instead of (nullptr,nullptr), most times you'll get an
error ONLY in <utility>, not in the original .cpp, as it happens in
VS2008
Igor Tandetnik
2010-02-25 12:56:20 UTC
Permalink
Post by Mycroft Holmes
(1) if a class has swap(T&) and swap(T&&) then in some cases we cannot
take a pointer to swap(T&).
the following sample shows that in ordinary code, the pointer can be
taken, but in a template it can't.
if you remove AAA::swap(AAA&&) it works.
template <typename T>
void fff(T& x, void (T::*)(T&))
{
}
template <typename T>
void fff(T& x)
{
fff(x, &T::swap);
}
I think the compiler has difficulties with combining overload resolution and template parameter deduction. It does look like a bug to me, I think the code should work as written. As a workaround, try these:

fff<T>(x, &T::swap);
// or
void (T::*F)(T&) = &T::swap;
fff(x, F);
// or
fff(x, static_cast<void (T::*)(T&)>(&T::swap));
Post by Mycroft Holmes
(2) sometimes the compiler is unable to fill-it default template
parameters, and it emits...well... bizarre error messages.
in the sample below, if you write "BBB<this_t, roll_t, LENGTH>" it
works, if you write "BBB<this_t, roll_t>" it does not compile.
template <typename r1_t, typename r2_t, int LENGTH1 = r1_t::length,
int LENGTH2 = r2_t::length>
class BBB;
template <typename r1_t, typename r2_t, int LENGTH>
class BBB<r1_t, r2_t, LENGTH, 1>
{
typedef BBB<r1_t, r2_t, LENGTH, 1> this_t;
BBB(int = 0)
{
}
static const int length = LENGTH;
// bug: VS2010 RC will complain if LENGTH is omitted...
// it says that 'length' is undefined
template <typename roll_t>
inline BBB<this_t, roll_t, LENGTH> operator<<(roll_t) const
{
return 0;
}
};
Yes, looks like a bug, too. Comeau accepts this.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925
David Lowndes
2010-02-25 14:40:42 UTC
Permalink
Post by Mycroft Holmes
we have a large template-based set of headers; they are pretty much
standard compliant and we cross-compile with VS2005, VS2008, the intel
compiler and some versions of gcc. A few days ago we tested VS2010 RC
If you feel fairly certain it's a bug, please submit it on the MS
connect web site - that way MS will be aware of it.

Dave
Mycroft Holmes
2010-02-25 15:12:32 UTC
Permalink
Post by David Lowndes
Post by Mycroft Holmes
we have a large template-based set of headers; they are pretty much
standard compliant and we cross-compile with VS2005, VS2008, the intel
compiler and some versions of gcc. A few days ago we tested VS2010 RC
If you feel fairly certain it's a bug, please submit it on the MS
connect web site - that way MS will be aware of it.
Dave
I continuously forget the link for bug submissions... can you repost
it here?
TIA
--mh
David Lowndes
2010-02-25 15:32:36 UTC
Permalink
Post by Mycroft Holmes
I continuously forget the link for bug submissions... can you repost
it here?
connect.microsoft.com

Dave
Darko Miletic
2010-02-26 12:35:39 UTC
Permalink
Post by Mycroft Holmes
Post by David Lowndes
Post by Mycroft Holmes
we have a large template-based set of headers; they are pretty much
standard compliant and we cross-compile with VS2005, VS2008, the intel
compiler and some versions of gcc. A few days ago we tested VS2010 RC
If you feel fairly certain it's a bug, please submit it on the MS
connect web site - that way MS will be aware of it.
Dave
I continuously forget the link for bug submissions... can you repost
it here?
TIA
--mh
https://connect.microsoft.com/VisualStudio
Michael Goldshteyn
2010-03-03 14:59:54 UTC
Permalink
Post by Mycroft Holmes
Hi all,
we have a large template-based set of headers; they are pretty much
standard compliant and we cross-compile with VS2005, VS2008, the intel
compiler and some versions of gcc. A few days ago we tested VS2010 RC
and we found the following problems: ...
Wow! MS is refusing to fix this bug, saying it does not meet their "triage
bar." I would strongly recommend that anyone who uses the Visual C++
compiler go to the following link and up-vote this bug so that it gets fixed
before VS 2010 RTM is released:

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

Here is their reply on MS connect:

-----
Hi: I can confirm that this is a bug with Visual C++. Unfortunately it does
not meet the triage bar for the current release of Visual C++ - but we will
keep the issue in our database and we will look at it again during the
development phase of a future release of Visual C++.

Jonathan Caves
Visual C++ Compiler Team
-----
David Lowndes
2010-03-03 15:23:21 UTC
Permalink
Post by Michael Goldshteyn
Wow! MS is refusing to fix this bug, saying it does not meet their "triage
bar."
That darned bar is a real obstacle to jump over. I hate it ;)
At least you've had a reply from the man who'll probably get round to
fixing it as soon as he's allowed to :)

Dave
Bo Persson
2010-03-03 16:34:52 UTC
Permalink
Post by Michael Goldshteyn
Post by Mycroft Holmes
Hi all,
we have a large template-based set of headers; they are pretty much
standard compliant and we cross-compile with VS2005, VS2008, the
intel compiler and some versions of gcc. A few days ago we tested
VS2010 RC and we found the following problems: ...
Wow! MS is refusing to fix this bug, saying it does not meet their
"triage bar." I would strongly recommend that anyone who uses the
Visual C++ compiler go to the following link and up-vote this bug
I don't think you can get anything less than a super MEGA-bug fixed
between an RC and an RTM. Something like formatting the harddisk or
accidentally installing Linux.

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.


Bo Persson
Stephan T. Lavavej [MSFT]
2010-03-04 00:04:43 UTC
Permalink
Correct: a bug has to be setting kittens on fire *twice* in order for it to
be fixed between RC and RTM.

I've fixed exactly 1 bug in the STL between RC and RTM. (Those poor
kittens.) In the compiler front-end, where small changes can have drastic
effects, no bugs have been fixed between RC and RTM, and we're pretty sure
that's true for the compiler back-end and the linker as well. (I'd have to
ask about MFC and our other libraries.)

While you may disagree with an individual triage decision, you can surely
agree that last-minute fixes are potentially destabilizing. You don't want
us performing brain surgery right before shipping something that you'll have
to live with for years.

The best way to get bugs you care about fixed, helping yourself and helping
us, is to test betas as early and as thoroughly as possible. In each
successive beta period we can make fewer and fewer fixes (using VC10 as an
example: VC9 SP1 to VC10 CTP, CTP to Beta 1, Beta 1 to Beta 2, Beta 2 to RC,
RC to RTM), so the earlier you report bugs, the better.

We try to fix all of our bugs before shipping - that's what devs and testers
get paid to do, after all - but some will inevitably slip through. Only
you, by compiling and running your own code, can find out which bugs will
affect you. By reporting them, you're ensuring that we become aware of
common bugs earlier than we otherwise would have (for bugs that our devs,
our testers, or other customers would have run into later), and that we
become aware of obscure bugs affecting you when we otherwise wouldn't have
known about them.

Stephan T. Lavavej
Visual C++ Libraries Developer
Post by Bo Persson
Post by Michael Goldshteyn
Post by Mycroft Holmes
Hi all,
we have a large template-based set of headers; they are pretty much
standard compliant and we cross-compile with VS2005, VS2008, the
intel compiler and some versions of gcc. A few days ago we tested
VS2010 RC and we found the following problems: ...
Wow! MS is refusing to fix this bug, saying it does not meet their
"triage bar." I would strongly recommend that anyone who uses the
Visual C++ compiler go to the following link and up-vote this bug
I don't think you can get anything less than a super MEGA-bug fixed
between an RC and an RTM. Something like formatting the harddisk or
accidentally installing Linux.
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.
Bo Persson
Mycroft Holmes
2010-03-08 12:55:06 UTC
Permalink
Post by Bo Persson
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.
Bo Persson
2010-03-08 17:03:40 UTC
Permalink
Post by Mycroft Holmes
Post by Bo Persson
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
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 ++).
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
Mycroft Holmes
2010-03-30 10:04:00 UTC
Permalink
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
David Lowndes
2010-03-30 10:13:54 UTC
Permalink
Post by Mycroft Holmes
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
Mycroft Holmes
2010-03-30 10:48:59 UTC
Permalink
Post by David Lowndes
I'd reply and point out that Jonathan has already said it's a bug.
good idea, I'll do.
Post by David Lowndes
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).
David Lowndes
2010-03-30 13:24:01 UTC
Permalink
Post by Mycroft Holmes
no, because Comeau does not support rvalue references (afaik).
Now you mention it, I seem to recall trying that myself when you first
posted about this :)

Dave

Loading...