From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15095 invoked by alias); 1 May 2015 19:38:21 -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 15078 invoked by uid 89); 1 May 2015 19:38:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 01 May 2015 19:38:20 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t41JcIbx017523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 1 May 2015 15:38:18 -0400 Received: from localhost (ovpn-116-62.ams2.redhat.com [10.36.116.62]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t41JcHmP022697; Fri, 1 May 2015 15:38:17 -0400 Date: Fri, 01 May 2015 19:38:00 -0000 From: Jonathan Wakely To: Daniel =?iso-8859-1?Q?Kr=FCgler?= Cc: libstdc++ , gcc-patches List Subject: Re: [patch] Implement ISO/IEC TS 18822 C++ File system TS Message-ID: <20150501193816.GJ3618@redhat.com> References: <20150430173236.GT3618@redhat.com> <20150501182223.GI3618@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-05/txt/msg00097.txt.bz2 On 01/05/15 21:28 +0200, Daniel Krügler wrote: >2015-05-01 20:22 GMT+02:00 Jonathan Wakely : >> On 01/05/15 19:03 +0200, Daniel Krügler 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. Yes, I agree that there's a bug here that could cause it to std::terminate. >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). Ah, I see what you mean (I thought you were suggesting some improvements to _Cmpt itself ... which might be possible so I'm glad you made me think about it :-) I think I wrote compare() like that because it was easier, and when I first implemented this we had COW strings so it wouldn't throw when copying. That isn't true now, so I need to change it.