Bug in visual c++ 2010 with standard conforming code.

Started by
15 comments, last by dmail 12 years, 7 months ago

So sue me for trying to help you get in touch with someone who could give you an authoritative answer dry.gif


Move away from the keyboard and go have some fun.
[size="1"]
Advertisement
[font="Verdana"]Hi, I think there's a possible bug in the c++ compiler that ships with vs 2010. I tried the same code in gcc and it worked fine (unless I was compiling it wrong...). The bug can be reproduced with the following code:
[/font]
[font="Verdana"]
template <typename T> struct A { void f1(){} void f1() const {} };
template <typename T> struct B : A<T> { using A<T>::f1; };
struct __declspec(dllexport) C : B<int> {};[/font][/quote][font="Verdana"] [/font][font="Verdana"]


template <typename T> struct [/font][font="Verdana"]__declspec(dllexport) [/font][font="Verdana"]A { void f1(){} void f1() const {} };
template <typename T> struct [/font][font="Verdana"]__declspec(dllexport) [/font][font="Verdana"]B : A<T> { using A<T>::f1; };
struct __declspec(dllexport) C : B<int> {};
[/font][font="Verdana"]I have no clue what happens here, or whether it's a bug or not. The best I can deduce is that A<T>::f1 is invalid as per spec and should be A::f1. But that aside:
[/font]
[font="Verdana"]
Export everything explicitly. There might be an issue with declspec being applied automatically and somehow breaking something.[/font]
The text editor seems to be completely messed up, it just implodes on quotes, sources and everything.

Put __declspec in front of A and B as well.

Just wish some people wouldn't nit pick.


Bug in visual c++ 2010 with standard conforming code.
[/quote]
This a moronic claim; calling you on that isn't a nitpick. First off you claim that the code that you used was the same, and then admit that you did in fact use different code on the different compilers. It's a severe logic error that different code on a different compiler is supposed to tell you how vendor specific code on another compiler is supposed to work to the extent that you claim that it's a bug in their compiler. Furthermore, you obviously don't understand what the standard is and is supposed to do. If you don't want to learn, fine, but don't try to claim that your misused terminology isn't to blame for communication problems. If you want discussion to focus on your code, then don't aggressively claim that the first place people should be looking is for standards compliance problems in a compiler implementation. Instead of claiming up front that this code should work and it's a bug in the compiler that it doesn't, simply say the code doesn't work and ask why.

Basically saying "Way to miss the point" when you made it abundantly clear that you thought the problem was standards compliance is just acting like a dick. And then trivializing your communications errors as other people nitpicking continues that trend. Rate --.
https://connect.micr...ember-functions

Issue created on connect, it would have been nice if the OP updated the post to reflect this.

Put __declspec in front of A and B as well.


Yeah it works then (also just if you put it in front of B), but then it produces compiler errors somewhere else. Only solution right now is to make wrappers.


Issue created on connect, it would have been nice if the OP updated the post to reflect this.


Aw common dude. I just saw that MS acknowledged my feedback!! I was not monitoring that thing 24/7 you know... :/ And I was not going to post here that the issue was posted there before I was sure it was actually something solid. But yeah it turns out it's a bug in VC and it'll be resolved in the next version. It would be interesting to see what was going wrong on the backend though.

Ok, now for that mod dude...


This a moronic claim; calling you on that isn't a nitpick. First off you claim that the code that you used was the same, and then admit that you did in fact use different code on the different compilers. It's a severe logic error that different code on a different compiler is supposed to tell you how vendor specific code on another compiler is supposed to work to the extent that you claim that it's a bug in their compiler. Furthermore, you obviously don't understand what the standard is and is supposed to do. If you don't want to learn, fine, but don't try to claim that your misused terminology isn't to blame for communication problems. If you want discussion to focus on your code, then don't aggressively claim that the first place people should be looking is for standards compliance problems in a compiler implementation. Instead of claiming up front that this code should work and it's a bug in the compiler that it doesn't, simply say the code doesn't work and ask why.

Basically saying "Way to miss the point" when you made it abundantly clear that you thought the problem was standards compliance is just acting like a dick. And then trivializing your communications errors as other people nitpicking continues that trend. Rate --.



Wow that's amazing, I love how you take15 words from a 200 word post of mine and choose to highlight 5 words that completely work against me. Completely! Impressive. Though, the other part of the title which you conveniently ignore reads bug in visual studio 2010. Which also makes it abundantly clear that I thought the problem was in MSVC, not in the code, but since I wasn't a 100% sure, I posted here.

Claim? Admit? What? Are we in a court room? I'm not claiming anything (aggressively or otherwise). I was just asking if the code is supposed to produce an error or not. I assumed people would know that you create libraries in different ways depending on the platform - maybe because I don't assume people are morons (as you so eloquently put it). So when I said standard conforming code I was implicitly referring to the actual c++ code (which declspec is not a part of) and wondering if there was anything wrong with it.

I can tell from your tone that you're one of those guys who thinks they're always right, but chill out will ya, and do something productive instead of chucking around insults. If you don't mind, I'm going skip the part where I provide a retort to you calling me a dick and a moron since someone has to keep things civil.

[size=2]aliak.net
Chill. ;)

There is enough meaningful negativity about Windows and how things work (or don't) with MS tools. In fairness you must admit that your original post could have come across as one of those.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.


Aw common dude. I just saw that MS acknowledged my feedback!! I was not monitoring that thing 24/7 you know... :/ And I was not going to post here that the issue was posted there before I was sure it was actually something solid. But yeah it turns out it's a bug in VC and it'll be resolved in the next version. It would be interesting to see what was going wrong on the backend though.


FYI the bug report had not been acknowledged as a bug when I added that link. What I am saying is that people suggested to file a bug report and instead of wasting peoples time (as the issue was being looked at by MS) then to state this is what you did. By linking to that report if also allows potential future viewers to see what the outcome was.

This topic is closed to new replies.

Advertisement