From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116631 invoked by alias); 1 May 2015 19:28:56 -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 116602 invoked by uid 89); 1 May 2015 19:28:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-la0-f42.google.com Received: from mail-la0-f42.google.com (HELO mail-la0-f42.google.com) (209.85.215.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 01 May 2015 19:28:55 +0000 Received: by labbd9 with SMTP id bd9so69947921lab.2; Fri, 01 May 2015 12:28:51 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.205.225 with SMTP id lj1mr9291404lbc.27.1430508531419; Fri, 01 May 2015 12:28:51 -0700 (PDT) Received: by 10.25.42.203 with HTTP; Fri, 1 May 2015 12:28:51 -0700 (PDT) In-Reply-To: <20150501182223.GI3618@redhat.com> References: <20150430173236.GT3618@redhat.com> <20150501182223.GI3618@redhat.com> Date: Fri, 01 May 2015 19:28:00 -0000 Message-ID: Subject: Re: [patch] Implement ISO/IEC TS 18822 C++ File system TS From: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= To: Jonathan Wakely Cc: "libstdc++" , gcc-patches List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2015-05/txt/msg00096.txt.bz2 2015-05-01 20:22 GMT+02:00 Jonathan Wakely : > On 01/05/15 19:03 +0200, Daniel Kr=FCgler wrote: >> >> b/libstdc++-v3/src/filesystem/path.cc: >> >> - path::compare(const path& p) const noexcept: >> >> Shouldn't the implementation of this noexcept function not try to >> create copies of path objects? Couldn't _Cmpt just hold references to >> _M_pathname? > > All your other comments are definitely correct and I'll make the > relevant fixes soon, but I'm not sure what you mean here, could you > clarify? My remembrance of the difference in noexcept qualifications of int compare(const path& p) const noexcept; int compare(const string_type& s) const; int compare(const value_type* s) const; is that the latter are allowed to allocate memory to be implemented as the standard writes the corresponding functions for std::basic_string: int compare(const basic_string& str) const noexcept; int compare(const charT* s) const; Returns: compare(basic_string(s)). But if I read your implementation of path::compare(const path& p) correctly it *also* may allocate memory by copying _M_pathname into a _Cmpt object. I was wondering whether for this comparison there exists real need to *copy* _M_pathname (potentially exceeding the memory limits). Wouldn't it be possible to define a _CmptRef type that for the purpose of implementing compare(const path& p) just refers to references of the _M_pathname and therefore doesn't need to allocate any dynamic storage? (I should have spoken of a new type _CmptRef and not of your existing _Cmpt). > I think it would be possible to implement a path like: Actually I was not (yet) suggesting to change your API of path, I was only wondering whether given the existing ABI compare(const path& p) could be implementable without need of additional dynamic memory. This was more a kind of louder thinking, I have not fully thought whether this not possible without changing your currently suggested ABI. - Daniel