Was rather surprised to be deluged with warnings of the form "object of type `volatile X&' will not be accessed in statement" for practically every use of a volatile assignment operator. After much head-scratching, I found that it seems to be generated whenever a function returning a reference to volatile is called in a void context. It doesn't seem to be possible to disable this warning. From the long comment above convert_to_void() in gcc/cp/cvt.c, it appears that this behaviour is intentional. However, if the intention is indeed to reduce confusion, then IMHO it actually has the reverse effect. It also seems inconsistent to generate the warning for a reference but not a pointer. Release: 3.2 Environment: Debian GNU/Linux x86 unstable How-To-Repeat: Here's a simple snippet that demonstrates the problem:- volatile int& wibble(volatile int& x) { x = 0; return x; } volatile int v; void foo() { wibble(v); }
State-Changed-From-To: open->closed State-Changed-Why: not a bug. references to volatile objects are evil. For instance, your wibble function contains 'return x', which looks like a read of x - but it isn't. pointers are different, you have to put a * infront to dereference them
Can I ask you to reconsider? The usual assignment operator idiom requires returning a reference. Of course, it's perfectly possible to write volatile assignment operators to return void, but that's not the expected semantics. The return statement in the function definition doesn't generate any warning (and even if it did, explicitly casting to reference wouldn't be too onerous), but every call of the function does, and it can begin to drown out the rest of the output. Even if you decide to keep the warning, an option to disable it would be nice.
I actually agree with Nathan here, volatile causes you to think you are going to access it every time you write it out.
As a separate affected user, might I ask you guys to reconsider again? If you're writing a smart pointer class in C++, users expect that you will support all the same operators with all the same semantics. AFAICT, there is no way to do that without generating this warning. You must implement an operator= that returns a volatile reference to support assignment of your volatile smart pointer because the default generated assignment operator doesn't work for volatile objects.
(In reply to comment #5) > you're writing a smart pointer class in C++, users expect that you will support > all the same operators with all the same semantics. do you mean that users expect this? volatile SmartPtr& SmartPtr::operator=(const SmartPtr&) volatile; I'm not sure I agree
Right, I think that's what users expect, assuming you are in a situation where volatile smart pointers make sense in the first place (in my case they are smart pointers to addresses within a shared memory region -- a case in which I think they make sense but I've been wrong before ;). In general I can see how volatile references could make code more difficult to read, and this is the one place I use them, so maybe the warning could just be changed to make operator= return type an exception to the matching rule?
(In reply to comment #7) > smart pointers to addresses within a shared memory region then shouldn't that be "SmartPtr<volatile T>" rather than "volatile SmartPtr<T>" ? the former points to an object which might change due to effects outside the program, the latter implies that the smart pointer itself might change, which only makes sense if the smart pointer object exists in shared memory (as opposed to pointing to shared memory)
(In reply to comment #8) > (In reply to comment #7) > the former points to an object which might change due to effects outside the > program, the latter implies that the smart pointer itself might change, which > only makes sense if the smart pointer object exists in shared memory (as > opposed to pointing to shared memory) In this case both are true; I'm building linked lists in shared memory. So it's a volatile pointer to a volatile object.