Eric Lemings wrote:
>
>> Martin Sebor wrote:
>>
>> 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.)
I could agree that it shouldn't _need_ to be const given that it needs
no member data and it is just a placeholder type. But I'd be willing to
bet that this was an intentional design decision.
>
>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 following testcase works just fine (on acc-6.16, gcc-4.3.1 &
msvc-8.0)
namespace std {
struct _Ignore
{
template <class _TypeT>
void operator=(const _TypeT&) const
{
}
};
// should make this extern and define in a .cpp
const _Ignore ignore = std::_Ignore ();
} // namespace std
int main ()
{
std::ignore = 1;
std::ignore = 1.f;
std::ignore = std::ignore;
std::ignore = (void (*)(int))0;
return 0;
}
Perhaps you could post the error and a testcase?
>
>The only other recourse I can think of is to use remove_const on the
>element types where appropriate.
I'm sure the above strategy will work.
>
>Brad.
>
