This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: mutex failing (stupid C++!)
- From: skaller <skaller at users dot sourceforge dot net>
- To: Miles Bader <miles at gnu dot org>
- Cc: Kaz Kylheku <kaz at zeugmasystems dot com>, gcc-help at gcc dot gnu dot org
- Date: Thu, 01 Nov 2007 11:48:09 +1100
- Subject: Re: mutex failing (stupid C++!)
- References: <1193808489.8355.22.camel@rosella.wigram> <DDFD17CC94A9BD49A82147DDF7D545C5424EE4@exchange.ZeugmaSystems.local> <87r6jadfio.fsf@catnip.gol.com>
On Thu, 2007-11-01 at 08:35 +0900, Miles Bader wrote:
> "Kaz Kylheku" <kaz@zeugmasystems.com> writes:
> > This should be diagnosed by -Wunused, IMHO. You are calling a
> > constructor, but ignoring the return value.
> ...
> > into the program, -Wunused will give you a diagnostic. But if you
> > construct an object and ignore the result, you don't get a diagnostic.
>
> Of course constructors (and destructors) can have side-effects, and it's
> not that uncommon to create objects just for such side-effects. I'm not
> sure how common it is to use _unnamed_ objects in this way (I've never
> done it I think, and it seems ever so slightly dodgy), but obviously it's
> possible...
>
> I guess gcc could warn when there are obviously no side-effects but who
> knows how easy that is (and maybe the few cases it catches aren't worth
> the effort).
In this case that would not work, since the constructor does
have a side effect. What's more, the incorrect coding I used
has a useful side effect: locking and then unlocking a mutex
acts as a memory barrier. It just wasn't what the class was
designed for, it was supposed to hold the mutex in a longer
scope.
The 'explicit' keyword helps prevent some problems, but
I don't see that it useful here.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net