On Fri, Oct 26, 2012 at 9:20 AM, Andrey Upadyshev <oliora@gmail.com> 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