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 16:36:37

On Fri, Oct 26, 2012 at 9:20 AM, Andrey Upadyshev <oliora_at_[hidden]> wrote:
> Strictly speaking there is a problem with GTest or my project settings
> which prevents GTest to pick up operator<< for 'path'. I'll dig it
> more deeply to fight the problem.

Please don't top quote. It is a violation of the Boost Discussion
Policy. See http://www.boost.org/community/policy.html#quoting

> But I've created a bug and send a mail for slightly different reason
> rather than solving this concrete bug (sorry if I was not clear
> enough). I try to discuss the current design of path class which acts
> like a container with infinite "depth" what smells not good for me.
> 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.

I'm not entirely satisfied with that situation, and would be happy to
see someone design such a universal string type. But that's just a
dream at the moment.

Thanks,

--Beman