From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21986 invoked by alias); 20 Dec 2018 22:19:33 -0000 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 Received: (qmail 21868 invoked by uid 89); 20 Dec 2018 22:19:32 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=2009, HX-Gm-Message-State:sk:AJcUukf X-HELO: mail-ot1-f51.google.com Received: from mail-ot1-f51.google.com (HELO mail-ot1-f51.google.com) (209.85.210.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 20 Dec 2018 22:19:31 +0000 Received: by mail-ot1-f51.google.com with SMTP id v23so3394023otk.9; Thu, 20 Dec 2018 14:19:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dh+mj9cPC0cmZPqy2V7bJp0k4LItMImefv/xQkUa3jU=; b=ZuWUq8iYeHz2o8Q7AFN+P2KvxHp+5hmnMtcAI1tUfNrCltTqIpiTzbG9FEZS6HkFWw DraYNhuXF0hB3YlnkcLkqQ20OZWQoPEDxf25+tWKywsSQiG9+/J4OS35ftWUhg1knL2O +diFUVSq2jZ5lkkRItks1otHu8Afaf9go3mlM9g8U8dEQgmijKtP50UHo93jl7ply/u9 plriMLuHhKopxHVmADkQAAzyS02obXEwv5HdqocwKXpT/w1OtoIzUcnhl7bEcFWTZWk9 UxTFv4FSbz9DzPnJQGLTmBttSoykH2pDWeJnq9ce84XxfJ0EqAkRcyd7E05fNpOteZzg iX/A== MIME-Version: 1.0 References: <366bf0a3-2daf-d5c5-7a09-f1260c9c405f@gmail.com> <8c9c47e8-84ac-3af6-9c5a-cfe81dc1df78@gmail.com> In-Reply-To: <8c9c47e8-84ac-3af6-9c5a-cfe81dc1df78@gmail.com> From: Ville Voutilainen Date: Thu, 20 Dec 2018 22:24:00 -0000 Message-ID: Subject: Re: Relax std::move_if_noexcept for std::pair To: =?UTF-8?Q?Fran=C3=A7ois_Dumont?= Cc: "libstdc++@gcc.gnu.org" , gcc-patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2018-12/txt/msg01511.txt.bz2 On Thu, 20 Dec 2018 at 23:53, Fran=C3=A7ois Dumont w= rote: > >> This is why I am partially specializing __move_if_noexcept_cond.= As > >> there doesn't seem to exist any Standard meta function to find out if > >> move will take place I resort using std::is_const as in this case for > >> sure the compiler won't call the move constructor. > > That seems wrong; just because a type is or is not const has nothing > > to do whether > > it's nothrow_move_constructible. > > Indeed, I am not changing that. Well, if you're not changing that, then I have no idea what is_const is doing in your patch. :) > > I don't understand what problem this is solving, and how it's not > > introducing new problems. > > > The problem I am trying to solve is shown by the tests I have adapted. > Allow more move semantic in associative container where key are stored > as const. I'm not sure what you're trying to achieve is doable. The element of an associative container is a pair, and it has pair's semantics. It's also a pair, and has those semantics. Those semantics are observable. > But if I make counter_type copy constructor noexcept then I also get the > move on the pair.second instance, great. I am just surprise to have to > make a copy constructor noexcept to have std::move_if_noexcept work as I > expect. Well, move construction/assignment via std::move or std::move_if_noexcept is not necessarily going to invoke just move constructors. Especially not for subobjects, like pair's members. > I think I just need to understand why we need std::move_if_noexcept in > unordered containers or even rb_tree. Couldn't we just use std::move ? I > don't understand what we are trying to avoid with this noexcept check. We are trying to avoid data corruption on exceptions; if you move a subobject and have to copy another, and then that copy operation throws, you can't reliably move the already-moved subobject back. See http://open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3050.html and also http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2855.html