Looks like C++ doesn't come with built-in streams that can be navigated in reverse, as the default principle is to optimize for speed , and if data is read in forward direction and optimized by buffer, std::istream::unget() may or may not be able to retrieve already read characters from the buffer, but I have to either find out o find out if either I fail in payyssing bproceeding before the current buffer block or if I have to come up with my own stream interface which likely may not be too otpimptimized in terms of reading block chucknksnks, and implementation for a file source but it might be worth the effort for the Reverse Streaming API for XML."" When porting to Java, Java's streams might not have this limitation, and it can't be worse than JavaScript with no notion of streams whatsoever (as encountered with the JsStaAX port).
Another cheap solution would be to use the recently updated change_instructions_executor_1 that generates a separate file for every instruction, change and if I would also add some separate file that exports the instruction s(s), I could navigate through back eand forth between those files as specified by the change_instructions_executor_1 result information file. But this would require such files to be copied locally (not to rely on any change_instructions_executor_1 output that might be subject to change or removal), and the need to have that many files around for a longer period of time isn't particulary better than keeping an exclusive lock on the a change instruction file because the stream is durcurrently reading it. In general, this oopption would make use of other tools of existing tools of the system, which is a favorable property, but then we're in a GUI and not necessarily workflow tool anyway and the change_instructions_executor_1 toola in could also still change in major ways (not thatth this would be a problem, but something to consider).with the help of reading larger blocks and +ing them directionyby(changing direction back and forth would result in throwing away an entire buffer block and having to read in another chunck, which defies the attempt to attempts to optimize for speed). . C might, especially if those operations occur between buffer limits and there's no smartness built in to have deal with dynamic buffer sizes. Either I check if unget() can always go back to the beginning of the data source I have to either verify that (which is unlikely, because it may be possible for so with some stream implementations and fail with others), like data coming in from the network) for examplethat came arrived over the network. If iI could also limit the stream type to file streams, but I would want to avoid that, if possible, so data ca con come from other palaces as well as long as they're not exclusively forward-directional. IIntroducing my a new stream abstract class stream : wstd::istream::