incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: Another potential hole in the tuple specs
Date Tue, 08 Jul 2008 19:13:31 GMT
Eric Lemings wrote:
>  
> 
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com] 
>> Sent: Tuesday, July 08, 2008 10:52 AM
>> To: dev@stdcxx.apache.org
>> Subject: Re: Another potential hole in the tuple specs
>>
>> Eric Lemings wrote:
>>>  
>> [...]
>>> A const assignment operator?  Sounds unorthodox but I'll try it out.
>>>
>>> My current workaround is to declare std::ignore mutable (i.e.
>>> non-const).  A const assignment operator (if it works) would be
>>> preferable; no visible workaround required.
>> Remember that even the absence (or presence) of the const
>> qualifier on things like std::ignore can be detected by
>> conformance test suites so dropping it is not a viable
>> option.
> 
> Assuming the draft standard is actually correct, that is. 
> In this case,
> I don't think there is any real need for std::ignore to be a constant
> really.  (Thinking about asking whether std::ignore really needs to be a
> constant on the committee reflector.)

IMO, there is no need for it not to be, and being constant
is more efficient than not (can be stored in ROM).

> 
> I tried making std::ignore const and adding const to the internal
> assignment operator.  I also tried adding overloads for const and
> non-const assignment.  Still got errors in all cases.
> 
> The only other recourse I can think of is to use remove_const on the
> element types where appropriate.

ignore is declared const in Boost so there must be a way
to implement tie() without declaring the object non-const.

Martin

Mime
View raw message