filesystem::path passed to GTest's assertion leads to stack overflow because of infinite recursion
Hi all, I found an interesting bug with 'filesystem::path' used with GTest: https://svn.boost.org/trac/boost/ticket/7564 I just want to discuss the design of 'path' class which iterator contains the 'path' itself. Don't you think it's nice to fix thing? Best regards, Andrey Upadyshev P.S. Sorry if this is wrong mailing list. Just let me know and I'll repost the message to boost-users <boost-users@lists.boost.org> mailing list.
On Thu, Oct 25, 2012 at 7:16 AM, Andrey Upadyshev <oliora@gmail.com> wrote:
Hi all, I found an interesting bug with 'filesystem::path' used with GTest: https://svn.boost.org/trac/boost/ticket/7564
I just want to discuss the design of 'path' class which iterator contains the 'path' itself. Don't you think it's nice to fix thing?
I'm curious as to why you think this is a bug in path rather than a bug in GTest? Thanks, --Beman
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. 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 :) On 26.10.2012, at 0:24, Beman Dawes <bdawes@acm.org> wrote:
On Thu, Oct 25, 2012 at 7:16 AM, Andrey Upadyshev <oliora@gmail.com> wrote:
Hi all, I found an interesting bug with 'filesystem::path' used with GTest: https://svn.boost.org/trac/boost/ticket/7564
I just want to discuss the design of 'path' class which iterator contains the 'path' itself. Don't you think it's nice to fix thing?
I'm curious as to why you think this is a bug in path rather than a bug in GTest?
Thanks,
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
On Fri, Oct 26, 2012 at 4:36 PM, Beman Dawes <bdawes@acm.org> wrote:
On Fri, Oct 26, 2012 at 9:20 AM, Andrey Upadyshev <oliora@gmail.com> 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
On Sat, Oct 27, 2012 at 1:19 AM, Beman Dawes <bdawes@acm.org> wrote:
On Fri, Oct 26, 2012 at 9:20 AM, Andrey Upadyshev <oliora@gmail.com> 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
On Fri, Oct 26, 2012 at 4:36 PM, Beman Dawes <bdawes@acm.org> wrote: 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
participants (2)
-
Andrey Upadyshev -
Beman Dawes