From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10829 invoked by alias); 11 Dec 2009 02:34:20 -0000 Received: (qmail 10801 invoked by uid 48); 11 Dec 2009 02:34:08 -0000 Date: Fri, 11 Dec 2009 02:34:00 -0000 Message-ID: <20091211023408.10800.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c++/36587] Feature: add warning for constructor call with discarded return. In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "kkylheku at gmail dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-12/txt/msg01099.txt.bz2 ------- Comment #4 from kkylheku at gmail dot com 2009-12-11 02:34 ------- (In reply to comment #3) > This would have prevented bugs I've dealt with where critical sections where > not protected: > { > lock_guard (mutex); > // mutex NOT locked here! > } > But I'm not convinced that doing this is always a mistake. Since we don't care about the object, we must care about the constructor side effect. I seem to be under the impression that ISO C++ allows the construction of temporary objects to be optimized away---even if there are side effects in the constructor or destructor! Therefore, it's hard to see a valid use case for this. Would the warning be > suppressed by casting to void? > (void) TypeWithSideEffectsInCtor(x); Not as implemented, I am afraid. The diagnostic is still produced that the object is discarded. This is can be regarded as a flaw; something explicitly requested by a cast should not be diagnosed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36587