Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rt::io: Add Bytes iterator for Reader #8935

Closed
wants to merge 2 commits into from
Closed

rt::io: Add Bytes iterator for Reader #8935

wants to merge 2 commits into from

Conversation

bluss
Copy link
Member

@bluss bluss commented Sep 2, 2013

An iterator that simply calls .read_bytes() each iteration.

I think choosing to own the Reader value and implementing Decorator to
allow extracting it is the most generically useful. The Reader type
variable can of course be some kind of reference type that implements
Reader.

In the generic form the Bytes iterator is well behaved itself and does not read ahead.
It performs abysmally on top of a FileStream, and much better if a buffering reader is inserted inbetween.

An iterator that simply calls `.read_bytes()` each iteration.

I think choosing to own the Reader value and implementing Decorator to
allow extracting it is the most generically useful. The Reader type
variable can of course be some kind of reference type that implements
Reader.
@bluss
Copy link
Member Author

bluss commented Sep 2, 2013

We could add further basic support for Iterator<char> and UTF-8 readers https://github.com/blake2-ppc/rust/compare/reader-iter but it is all too simple (needs to fit into the scheme of buffering, text layer, encoding support?)

@brson
Copy link
Contributor

brson commented Sep 3, 2013

Added an issue for buffering #8953

@brson
Copy link
Contributor

brson commented Sep 3, 2013

Thanks! I'm glad you are continuing to push rt::io forward. I haven't had time to work on it much myself lately.

@bluss
Copy link
Member Author

bluss commented Sep 3, 2013

If you think it's ok I think ByteIterator is the better version of that. Also clarified the doc comment on iteration -- conditions make the IO iterators more interesting than the others, but at the moment (PR #8276) there is no stronger guarantees needed for an iterator.

@brson
Copy link
Contributor

brson commented Sep 4, 2013

@anasazi This overlaps the work you are doing with iteration.

bors added a commit that referenced this pull request Sep 4, 2013
An iterator that simply calls `.read_bytes()` each iteration.

I think choosing to own the Reader value and implementing Decorator to
allow extracting it is the most generically useful. The Reader type
variable can of course be some kind of reference type that implements
Reader.

In the generic form the `Bytes` iterator is well behaved itself and does not read ahead.
It performs abysmally on top of a FileStream, and much better if a buffering reader is inserted inbetween.
@bors bors closed this Sep 4, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants