Re: [boost] Workaround for compiler bugs

Subject: Re: [boost] Workaround for compiler bugs
From: Edward Diener (eldiener_at_[hidden])
Date: 2010-12-06 16:38:31

On 12/6/2010 2:53 PM, Jim Bell wrote:
>
>
> On 1:59 PM, Edward Diener wrote:
>> On 12/6/2010 10:10 AM, Dave Abrahams wrote:
>>> At Mon, 06 Dec 2010 09:06:19 -0500,
>>> Edward Diener wrote:
>>>>
>>>> [...]
>>>>
>>>> Is this a valid NG for bringing such a compiler bug to light so that
>>>> other Boost developers are not only aware of the bug but might have a
>>>> solution, if they have not already developed one for themselevs ?
>>>>
>>>> [...]
>>>
>>> Gray area.  I say, if you need help getting over a Boost-related hump,
>>> ask here.  If it gets out of hand, moderators will step in.
>>>
>>
>> OK, understood. I have a possible candidate for a nasty compiler bug
>> in VC++ concerning [...]
>
> This seems like valuable input for boost.config.  Could you adapt it as
> a patch&  associated test(s)?

First of all, in the particular case which I am seeing, I do not have a 
workaround yet so there is no "patch" as I understand that you mean. 
Secondly the bug I am seeing may affect only what I am trying to do in 
the sandbox library and may never occur in whatever other area of Boost 
programming that exists, but still I do understand that having 
boost.config be aware of it under some sort of macro name might be 
valuable to Boost in general. Finally, although I can reproduce the bug 
within a certain well-defined context, the actual single construct where 
the bug is happening is still hard to define or reproduce, so a place 
where boost.config can identify the exact statement/construct in which 
the bug occurs is still elusive. But I will be trying to find a 
workaround and narrow down exactly why the bug is occuring as soon as I can.

Since I have said so much about this situation, I should point anyone 
who might be interested in what I have uncovered in VC++ while trying to 
achieve a goal in my sandbox library to both my error report to 
Microsoft and my post on Microsoft's online forums regarding the situation.

The error report to Microsoft is at 
https://connect.microsoft.com/VisualStudio/feedback/details/624757/incorrect-function-template-deduction-involving-pointor-to-member-data 
. The explanation and the attachment there should explain what is 
happening. Microsoft has not come back with much about it. I filed 
another similar bug report which I discovered, but for which I 
subsequently did find a workaround, at 
https://connect.microsoft.com/VisualStudio/feedback/details/618414/incorrect-deduction-when-using-a-pointer-to-member-type-in-a-template 
and Microsoft's only response beside acknowledging the bug was to say, 
as usual, they will not fix it. So I have little hope that they will fix 
this later one sometime in the future, as ridiculous as both bugs are, 
but if I call them up they are supposed to find a workaround for me. I 
just do not want to call them up and enter the Microsoft merry-go-round 
of supplying the end-user with a workaround ( once it took them over 3 
months ), until I absolutely have to do so.

The report about this bug in the Microsoft online forums is at 
http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/8091f43b-56d1-46b0-b047-36081cdc619b 
. A Microsoft moderator has responded about a week ago that he is 
looking at the issue, but I have heard nothing further from him, and 
somehow seriously doubt that he will find a workaround.

Perhaps someone here on this forums will find a workaround, but they 
would need to test under VC9 and VC10 at least ( I haven't tried it yet 
but I am guessing the bug is probably present in VC8 and VC7.1 also ). 
Needless to say the bug does not occur under gcc 4.0+.