Thread: Friends design

Not the whole file; not if it's like 100 MB.
That's why I chose the buffering approach - read a chunk of data, and when accessing it, check if we have read data up to that point, and if not, read it and buffer it.
I just chose to encapsulate this as an iterator.

I remember that thread. Basically, the read function is the fastest, and it's what I use for buffering.

Random-access iterators over files are of course a known problem for parsers, which is why I would expect a C++ parser library to have such an iterator.

Why, look, it does:
File Iterator

Originally Posted by CornedBee

Random-access iterators over files are of course a known problem for parsers, which is why I would expect a C++ parser library to have such an iterator.

Why, look, it does:
File Iterator

I've always admired the Spirit project's clean, orthogonal libraries. This is a great example of such a design. I think I'll be using this one a lot.

Originally Posted by Mario F.

Well, dunno Elysia.



The problem (not really a problem, mind you) is that an iterator class only makes sense in the presence of an aggregator class. The moment you try to protect aggregate functionality from the main class, your iterator becomes unintuitive. Personally, as a user of your class, I'd rather see it implementing it's own traversing functionality.

Of course it is all a matter of design. It's your choice what you want to do. Being that you still would want an iterator class, in order to better protect yourself from future changes, I'd probably partition your stream class roles with a mixin interface class that implemented the aggregate functionality of your stream class. Then, implement the iterator pattern from that aggregate.

If this is not an option because the stream class will always be used with a buffer, you'll probably be forced to indeed derive your iterator from the stream class. But that's really perverting the idea of a derived class. In any case, you are probably looking into a private inheritance with protected members in the stream class.

Really, I'd go back to anon initial post and suggest you consider your design. If I was to use your stream class, i'd be slightly annoyed if I had to go through an iterator to traverse what is essentially a non aggregate.

I had to revisit this now that I have time and somewhat understand what it means.
But I'm still not sure what you actually mean. I get the concept of aggregates somewhat.
But what would a non-aggregate class be?

Also, dunno if I mentioned this but, I derive my stream class from the standard library stream class (for input). This works fine, thankfully, since I won't need access to private members. Only add the actual buffer, open wrapper and of course begin/end functions for iterators.
So it should work just as a "normal" input stream, but with the option of getting input iterators from it, which would be specially made to support the whole buffering system.

Originally Posted by CornedBee

Random-access iterators over files are of course a known problem for parsers, which is why I would expect a C++ parser library to have such an iterator.

Why, look, it does:
File Iterator

Ah, I love that boost seems to have a solution for everything.
Unfortunately, I do have one gripe with it: read-only. It's not ideal, but it's certainly worth keeping mind, so thanks for the heads up.
However, reading (parsing) is only half the problem of what I'm thinking of designing. I want to write out data to the file, as well (albeit, this is the next step after the input is finished).
I suppose ostream iterators might work for this, though? I don't know what type of iterator they are, if they exist.

Ostream iterators (yes, they exist) are OutputIterators. You can write to them, but not read from them, and they support only a single pass over the sequence. (They're the pendant of InputIterators.)
I don't see why you would need random access on output anyway.

But I don't suppose they support seeking (ie += offset)?
It would a lot more efficient to write out parts instead of everything. Don't know if I can make that work, but if I could, that would be cool. It's an option anyway.

EDIT: C++ Reference says no, from what I can tell...
Gah. Stupid iterators.
We'll just have to do it the old fashioned way then, eh?