[filesystem] issue with path::iterator
Hello, a momemnt ago, someone reported a problem on IRC regarding boost::filesystem::path::iterator. He basically has code like this: using boost::filesystem::path; path::iterator i = somepath.begin(); path::iterator j = i++; That code used to work but stopped working recently. Now, there is a compiler error saying that the value returned by i++ is not suitable for constructing j: error: conversion from ` boost::detail::postfix_increment_proxy<boost::filesystem::path::iterator>' to non-scalar type `boost::filesystem::path::iterator' requested I suspect the change was caused by a recent change to iterator adaptors. Investigation of the problem revealed that the documenation for path::iterator says it is a bidirectional iterator while the implementation uses single_pass_traversal_tag. This looks wrong to me. Regards, m
At Wednesday 2004-08-11 09:56, you wrote:
Hello,
a momemnt ago, someone reported a problem on IRC regarding
where on IRC? I should probably hang out in there
boost::filesystem::path::iterator. He basically has code like this:
using boost::filesystem::path; path::iterator i = somepath.begin(); path::iterator j = i++;
That code used to work but stopped working recently. Now, there is a compiler error saying that the value returned by i++ is not suitable for constructing j:
error: conversion from ` boost::detail::postfix_increment_proxy<boost::filesystem::path::iterator>' to non-scalar type `boost::filesystem::path::iterator' requested
I suspect the change was caused by a recent change to iterator adaptors.
Investigation of the problem revealed that the documenation for path::iterator says it is a bidirectional iterator while the implementation uses single_pass_traversal_tag. This looks wrong to me.
Regards, m _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Martin Wille <mw8329@yahoo.com.au> writes:
Victor A. Wagner Jr. wrote:
At Wednesday 2004-08-11 09:56, you wrote:
Hello,
a momemnt ago, someone reported a problem on IRC regarding where on IRC? I should probably hang out in there
EFNet/#boost and Freenode/#boost.
Can one IRC with a Windows client? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Martin Wille writes:
Victor A. Wagner Jr. wrote:
At Wednesday 2004-08-11 09:56, you wrote:
Hello,
a momemnt ago, someone reported a problem on IRC regarding
where on IRC? I should probably hang out in there
EFNet/#boost and Freenode/#boost.
Can one IRC with a Windows client?
Sure. There are several IRC clients for Windows around. Miranda with an IRC plugin or MIrc would be two (of probably many) options. MIrc had some security problems recently, so you probably want to use a different client. Regards, m
Martin Wille <mw8329@yahoo.com.au> writes:
EFNet/#boost and Freenode/#boost.
Can one IRC with a Windows client?
Sure. There are several IRC clients for Windows around. Miranda with an IRC plugin or MIrc would be two (of probably many) options. MIrc had some security problems recently, so you probably want to use a different client.
How do you get an account? http://efnet.info is absolutely useless to me as an interface for finding out. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
Martin Wille <mw8329@yahoo.com.au> writes:
EFNet/#boost and Freenode/#boost.
Can one IRC with a Windows client?
Sure. There are several IRC clients for Windows around. Miranda with an IRC plugin or MIrc would be two (of probably many) options. MIrc had some security problems recently, so you probably want to use a different client.
How do you get an account? http://efnet.info is absolutely useless to me as an interface for finding out.
Nevermind, I guess I worked it out, sort of. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Martin Wille <mw8329@yahoo.com.au> writes:
Hello,
a momemnt ago, someone reported a problem on IRC regarding boost::filesystem::path::iterator. He basically has code like this:
using boost::filesystem::path; path::iterator i = somepath.begin(); path::iterator j = i++;
That code used to work but stopped working recently. Now, there is a compiler error saying that the value returned by i++ is not suitable for constructing j:
error: conversion from ` boost::detail::postfix_increment_proxy<boost::filesystem::path::iterator>' to non-scalar type `boost::filesystem::path::iterator' requested
I suspect the change was caused by a recent change to iterator adaptors.
Investigation of the problem revealed that the documenation for path::iterator says it is a bidirectional iterator while the implementation uses single_pass_traversal_tag. This looks wrong to me.
The documentation must be wrong, because the implementation never included a decrement implementation. It might be possible to make the user's code compile for this case, but I'm not sure we would be doing him/her a service, considering that the concepts don't require X a = b++; to compile. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Martin Wille writes: ...
Investigation of the problem revealed that the documenation for path::iterator says it is a bidirectional iterator while the implementation uses single_pass_traversal_tag. This looks wrong to me.
The documentation must be wrong, because the implementation never included a decrement implementation.
It might be possible to make the user's code compile for this case, but I'm not sure we would be doing him/her a service, considering that the concepts don't require
X a = b++;
to compile.
Line 95 of path.hpp declares void decrement(), lines 669-679 in path_posix_windows implement it. Note, this is not the directory iterator. Regards, m
Martin Wille <mw8329@yahoo.com.au> writes:
David Abrahams wrote:
Investigation of the problem revealed that the documenation for path::iterator says it is a bidirectional iterator while the implementation uses single_pass_traversal_tag. This looks wrong to me. The documentation must be wrong, because the implementation never included a decrement implementation. It might be possible to make the user's code compile for this case, but I'm not sure we would be doing him/her a service, considering
Martin Wille writes: ... that the concepts don't require X a = b++; to compile.
Line 95 of path.hpp declares void decrement(),
Sorry, I was looking at operations.hpp. This is a different iterator?
lines 669-679 in path_posix_windows implement it.
Note, this is not the directory iterator.
OK, I agree with your analysis -- the traversal category appears to be wrong. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
At 12:56 PM 8/11/2004, Martin Wille wrote:
Hello,
a momemnt ago, someone reported a problem on IRC regarding boost::filesystem::path::iterator. He basically has code like this:
using boost::filesystem::path; path::iterator i = somepath.begin(); path::iterator j = i++;
That code used to work but stopped working recently. Now, there is a compiler error saying that the value returned by i++ is not suitable for constructing j:
error: conversion from ` boost::detail::postfix_increment_proxy<boost::filesystem::path::iterator>' to non-scalar type `boost::filesystem::path::iterator' requested
I suspect the change was caused by a recent change to iterator adaptors.
Investigation of the problem revealed that the documenation for path::iterator says it is a bidirectional iterator while the implementation uses single_pass_traversal_tag. This looks wrong to me.
I agree with your analysis. What is weird is that even though the single_pass_traversal_tag is given, the path_test.cpp regression test uses operator-- in tests, and they compile fine. So it looks like there is also a bug in iterator adaptors too, since I would think that the use of operator-- on a single pass iterator should fail. Thanks, --Beman
Beman Dawes <bdawes@acm.org> writes:
What is weird is that even though the single_pass_traversal_tag is given, the path_test.cpp regression test uses operator-- in tests, and they compile fine.
So it looks like there is also a bug in iterator adaptors too, since I would think that the use of operator-- on a single pass iterator should fail.
It's not a bug to provide more functionality than the category allows. If you supply a decrement() operation, operator-- will call it. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
At 05:17 PM 8/22/2004, David Abrahams wrote:
Beman Dawes <bdawes@acm.org> writes:
What is weird is that even though the single_pass_traversal_tag is given, the path_test.cpp regression test uses operator-- in tests, and they compile fine.
So it looks like there is also a bug in iterator adaptors too, since I would think that the use of operator-- on a single pass iterator should fail.
It's not a bug to provide more functionality than the category allows. If you supply a decrement() operation, operator-- will call it.
OK. Thanks for the clarification. I guess that means the filesystem test needs an additional case that would work for a bidirectional iterator but fail for a single pass traversal iterator which supplies a decrement() operator. Any suggestions? --Beman
Beman Dawes <bdawes@acm.org> writes:
At 05:17 PM 8/22/2004, David Abrahams wrote:
Beman Dawes <bdawes@acm.org> writes:
What is weird is that even though the single_pass_traversal_tag is given, the path_test.cpp regression test uses operator-- in tests, and they compile fine.
So it looks like there is also a bug in iterator adaptors too, since I would think that the use of operator-- on a single pass iterator should fail.
It's not a bug to provide more functionality than the category allows. If you supply a decrement() operation, operator-- will call it.
OK. Thanks for the clarification.
I guess that means the filesystem test needs an additional case that would work for a bidirectional iterator but fail for a single pass traversal iterator which supplies a decrement() operator. Any suggestions?
Try any std:: algorithm that requires forward iterators but is faster with random access iterators. binary_search comes to mind.
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
At 03:13 PM 8/22/2004, Beman Dawes wrote:
At 12:56 PM 8/11/2004, Martin Wille wrote:
Investigation of the problem revealed that the documenation for path::iterator says it is a bidirectional iterator while the implementation uses single_pass_traversal_tag. This looks wrong to me.
I agree with your analysis.
OK, path::iterator in CVS has been changed to use bidirectional_traversal_tag. I'll try to keep an eye on the regression tests as the change propagates to various systems. If anyone has any problems with user code, please post a report here. --Beman
participants (6)
-
Beman Dawes -
David Abrahams -
Jeremy Maitin-Shepard -
Martin Wille -
Victor A. Wagner Jr.