stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: HP aCC 3.63 compilation error in 21.string.append.stdcxx-438.cpp
Date Tue, 24 Jun 2008 22:32:35 GMT
Travis Vitek wrote:
>  
> 
>> Martin Sebor wrote:
>>
>> The test fails to compile with HP aCC 3.63. The error messages
>> point to the patch for the issue:
>>
>>   http://svn.apache.org/viewvc?view=rev&revision=629550
> 
> Actually, I think it was me that caused the problem, in the following
> change:
> 
>     http://svn.apache.org/viewvc?view=rev&revision=669747
> 
> The fix was for STDCXX-170 and friends, but break on every compiler when
> the Iterator::operator*() returns a temporary (which is legal).

That's what I thought was your objection to Farid's patch. Am I
to understand that the code somehow detects whether operator*()
returns a rvalue or lvalue and the branch with the cast is only
supposed to be entered for lvalues? (I'm still uncomfortable
with the cast and would like to understand why it's safe).

> 
> It looks like I'd need to do a special case when the iterator type is
> pointer. I don't see any way to legally check for no overlap without
> that, so the only option I can see then is to always make the copy and
> fix it with an overload selection trick (which would only be appropriate
> for 4.3.x).

I think it should be fine to optimize just the common case
(const_pointer) and leave the rest unoptimized (i.e., make
a copy). Or can you think of another common use that should
be optimized as well?

> 
> Travis 
> 
>> Looking at the patch I don't see how the reinterpret_cast to
>> const_reference can possibly be correct, and I'm not sure we
>> satisfactorily resolved the same question the first time it
>> was raised back in March:
>>
>>   http://markmail.org/message/eijfmt3wxhg25bvs
>>
>> Farid?
>>
>> Thanks
>> Martin
>>


Mime
View raw message