Boost C++ Libraries: Ticket #3997: Can't use iterator_range as template argument in tokenizer

Steven Watanabe — Thu, 11 Mar 2010 20:54:37 GMT

This would probably be a bad idea, since the semantics of assign for containers are significantly different from what they would be for iterator_range.

anonymous — Fri, 12 Mar 2010 03:23:04 GMT

Steven, could you please elaborate on this? semantics of assign for example for string container does have such signature and since I want to use iterator_range as a container for boost::tokenizer I am forced (by tokenizer implementation) to have such assign method thanks, Roman

Steven Watanabe — Fri, 12 Mar 2010 04:28:28 GMT

Assign for containers makes a copy of all the elements. Clearly, iterator_range is not going to do this. I think it's a bad idea for iterator_range to try to mimic the mutable interface of containers, when the actual behavior is not consistent. While I appreciate that you want to use iterator_range with tokenizer, I think adding assign to iterator_range is probably the wrong solution. I think it would be better if tokenizer could be changed so that it doesn't rely on assign.

Fri, 12 Mar 2010 05:43:37 GMT

I see,and of course my assign method suggestion above doesn't make copy of elements, but rather "repoints" to new location by given iterators. However, I understand your point, that notion of assign for containers is different from iterator_range concept. Solution I think lies somewhere in the middle, since tokenizer takes as template argument Container and iterator_range isn't truly a container, thus there must be some way to interact between. So change to the tokenizer could be: it would take iterator_range as it's template argument as well?

owner changed

Neil Groves — Sat, 03 Apr 2010 21:30:54 GMT

owner changed from Thorsten Ottosen to Neil Groves

Reassigned since this is I am maintaining Boost.Range

status changed; resolution set

Neil Groves — Wed, 07 Apr 2010 23:54:01 GMT

status new → closed
resolution → invalid

The documented requirements for the Tokenizer argument are greater than those provided by the Range Concept. In particular the Tokenizer algorithm needs to be able to utilize container functions to resize / allocate etc. This is far outside of the scope of the Range Concept by design.

Since using a container appears an easy and optimal solution I am closing this issue.