This is the mail archive of the
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: <email@example.com> <DDFD17CC94A9BD49A82147DDF7D545C5424EE4@exchange.ZeugmaSystems.local> <firstname.lastname@example.org>
On Thu, 2007-11-01 at 08:35 +0900, Miles Bader wrote:
> "Kaz Kylheku" <email@example.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
> 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
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