This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [patch] Implement ISO/IEC TS 18822 C++ File system TS
- From: Daniel Krügler <daniel dot kruegler at gmail dot com>
- To: Jonathan Wakely <jwakely at redhat dot com>
- Cc: "libstdc++" <libstdc++ at gcc dot gnu dot org>, gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 1 May 2015 21:28:51 +0200
- Subject: Re: [patch] Implement ISO/IEC TS 18822 C++ File system TS
- Authentication-results: sourceware.org; auth=none
- References: <20150430173236 dot GT3618 at redhat dot com> <CAGNvRgAzHFMbsw3PLzEb4zprmGnZiLJux+vJCxY9kC-gCOhvLg at mail dot gmail dot com> <20150501182223 dot GI3618 at redhat dot com>
2015-05-01 20:22 GMT+02:00 Jonathan Wakely <jwakely@redhat.com>:
> 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. 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