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: Andrey Upadyshev (oliora_at_[hidden])
Date: 2012-11-10 03:39:22

On Sat, Oct 27, 2012 at 1:19 AM, Beman Dawes <bdawes_at_[hidden]> wrote:

> 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
>

 No more top quotes from me, promise!

I got the problem with encoding. So std::basic_string<CharT> as path
element doesn't fit well. But it's possible to introduce some additional
class like path_segment or path_string which will be used internally in
path and return as path's element during the iteration of path. The will
break the strange behavior with infinite depth of path object.

Regards,
Andrey