Re: [boost] filesystem::path passed to GTest's assertion leads to stack overflow because of infinite recursion

Subject: Re: [boost] filesystem::path passed to GTest's assertion leads to stack overflow because of infinite recursion
From: Beman Dawes (bdawes_at_[hidden])
Date: 2012-10-26 17:19:11

On Fri, Oct 26, 2012 at 4:36 PM, Beman Dawes <bdawes_at_[hidden]> wrote:
> On Fri, Oct 26, 2012 at 9:20 AM, Andrey Upadyshev <oliora_at_[hidden]> wrote:
>>
>> Why don't just present path's iterator value_type with
>> std::basic_string? This is (IMHO) more clear and nearer to "reality"
>> than path consisting of paths consisting of paths consising of paths
>> etc without the end :)
>
> std::basic_string<char> doesn't work well as the iterator value_type
> on platforms that may be using a native encoding for std::string that
> has doesn't have a representation for all possible characters. UTF-8
> would be a partial solution, but prone to errors for users who assume
> native encoding, and extra work for those who really want the native
> encoding.
>
> std::wstring, u16string, and u32string each have their own set of problems.
>
> What would really be helpful is an extended string type that was
> easily convertible to any of the std string types, with a way to
> specify the desired encoding when the value_type is char. The closest
> thing we have right now is type path itself.

An alternative design might be to make path::begin() and path::end()
member templates, parametrized on charT, traits, Allocator, and then
specify the value_type as basic_string<charT, traits, Allocator>.
Presumably encoding would with be dealt with as is done in other
functions. Or just provide string_begin()/string_end(),
wstring_begin()/wstring_end(), etc.

--Beman

--Beman