From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5322 invoked by alias); 9 Feb 2009 17:54:20 -0000 Received: (qmail 5223 invoked by alias); 9 Feb 2009 17:54:08 -0000 Date: Mon, 09 Feb 2009 17:54:00 -0000 Message-ID: <20090209175408.5222.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/39136] std::mem_fun_ref fails to accept a member function whose second argument with default value In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "fang at csl dot cornell dot edu" 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-02/txt/msg00801.txt.bz2 ------- Comment #8 from fang at csl dot cornell dot edu 2009-02-09 17:54 ------- Subject: Re: std::mem_fun_ref fails to accept a member function whose second argument with default value > ------- Comment #7 from paolo dot carlini at oracle dot com 2009-02-09 17:26 ------- > (In reply to comment #6) >> Was there a compelling reason to remove it in favor of the unified >> ::resize(size_type, const value_type& t = T)? > > Yes, is non-conforming! I thought it was clear at this point... Just try to > instantiate that version of std::vector with a non-DefaultConstructible Tp! At no point was vector::resize() ever instantiatable with a non-DefaultConstructible Tp, even with the old size_type-only member function. It would have failed on value_type() in the definition body. That doesn't make it any less conforming, does it? The default-tail-argument version of ::resize() (with = Tp()) just fails at the prototype in a concept-way, rather than through body instantiation. Is that the critical difference? Fang -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39136