On 11/5/2010 10:21 AM, Dominique Devienne wrote:
On Fri, Nov 5, 2010 at 3:31 AM, Alex Dubov
wrote: So the question is, how can one establish the size for this iterator adapter's internal storage so as to avoid match failures due to incomplete storage and avoid storing too much unnecessary data? I suppose, the storage can be reset when the match is reported. This, however, still leaves an open problem for situations where matches are separated by, possibly, gigabytes of non-matching data.
In the case of single-line matching, backtracking need only going back to the start of the current line, so I think the buffering only needs to be line based. For arbitrarily long multi-line matching, I don't know... --DD
In that case, the iterator may be backed up all the way to the beginning of the match, so if the iterator is caching the input, it would need to cache it all. There is no way to relax xpressive's iterator requirements. If you're using file streams, you could probably write an iterator that manipulates the stream's buffer, adjusting it appropriately when the buffer underflows on backtracking. Just a thought. -- Eric Niebler BoostPro Computing http://www.boostpro.com