From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28461 invoked by alias); 4 Aug 2012 15:34:27 -0000 Received: (qmail 28428 invoked by uid 22791); 4 Aug 2012 15:34:26 -0000 X-SWARE-Spam-Status: No, hits=-7.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_YE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 04 Aug 2012 15:34:12 +0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q74FYAc2024805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 4 Aug 2012 15:34:11 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q74FY9TO016760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Aug 2012 15:34:10 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q74FY9vV020842; Sat, 4 Aug 2012 10:34:09 -0500 Received: from [192.168.1.4] (/79.33.217.9) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 04 Aug 2012 08:34:08 -0700 Message-ID: <501D40ED.8090909@oracle.com> Date: Sat, 04 Aug 2012 15:34:00 -0000 From: Paolo Carlini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Marc Glisse CC: Ollie Wild , gcc-patches , Richard Smith , Diego Novillo , Paul Pluzhnikov , libstdc++ Subject: Re: Value type of map need not be default copyable References: <501B9C45.7010409@oracle.com> <501D0635.8050006@oracle.com> <501D0D6A.3090407@oracle.com> <501D3AD7.8060503@oracle.com> <501D3D89.7010505@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2012-08/txt/msg00244.txt.bz2 On 08/04/2012 05:27 PM, Marc Glisse wrote: > On Sat, 4 Aug 2012, Paolo Carlini wrote: > >> On 08/04/2012 05:16 PM, Marc Glisse wrote: >>> On Sat, 4 Aug 2012, Paolo Carlini wrote: >>> >>>> I'm not sure to understand which specific testcase you are >>>> discussing, but for sure we don't want regressions. I agree that we >>>> should assume a priori that the standard is right, but correcting >>>> the make_pair should not lead to failures elsewhere (unless a >>>> proper analysis establishes that the existing testcases are wrong) >>> >>> Let's say it currently works by accident. What I believe is needed >>> is to implement the missing emplace function, and then operator[] >>> and others can be made to use it. >> Are you really sure that emplace is involved? I'm not. The letter of >> the standard uses 'inserts'. > The font indicates it is "english" insert, not "function" insert. In > the testcase, value_type is not move constructible, so once you have > an object of type value_type, you can't do anything with it. First, I think we should add libstdc++ in CC. Thus, I would recommend people working in this area to begin with unordered_map, because in that case emplace is already available, assuming that's really the point (and therefore reverting the patch was a good idea, luckily an existing testcase helped us) At the same time an implementation of emplace is definitely welcome, in any case. Paolo.