From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21901 invoked by alias); 28 Oct 2011 10:00:32 -0000 Received: (qmail 21887 invoked by uid 22791); 28 Oct 2011 10:00:31 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 28 Oct 2011 10:00:17 +0000 From: "marc.glisse at normalesup dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/43813] [DR1234] vector(3, NULL) fails to compile Date: Fri, 28 Oct 2011 10:00:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: marc.glisse at normalesup dot org X-Bugzilla-Status: SUSPENDED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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: 2011-10/txt/msg02972.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43813 Marc Glisse changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marc.glisse at normalesup | |dot org --- Comment #9 from Marc Glisse 2011-10-28 09:59:58 UTC --- (In reply to comment #8) > Note: if the *only* way to change the behevior for the best requires using > enable_if on the user-level member functions (as, if I remember correctly, > pioneered by Howard at Metrowerks quite a few years ago), The resolution to 1234 has been adopted for C++11. The standard now says: "the constructor shall not participate in overload resolution", not that the call should be dispatched to an appropriate function. If there is an observable difference, that makes the dispatch technique wrong. > we have to make sure > we do it consistently over all the dispatchings in the containers, and check > what happens if a binary built with the headers using the old-style dispatching > is linked to a new one. In case, restrict the mechanism to C++0x mode. But > really, I'd rather wait for a resolution anyway, even as NAD but clearly > stating this is a QoI issue. I don't think adding an extra template parameter or an extra argument to the function (and removing the unnecessary functions) creates any incompatibility, but you have more experience with that. In C++11 mode (where libstdc++ has sfinae-friendly iterator_traits), we could check something like is_convertible::iterator_category, input_iterator_tag>.