Robert Zeh wrote:

Sebastien Martel <smartel@real.com> writes:

...

Hello boosters,

Thank you for looking over the comments I posted.

I completely forgot to mention one important thing boost.tokenizer 1.32 introduced that broke us when we moved from boost 1.31 :

Here is my post on the matter on boost-users

http://tinyurl.com/bc4av

Essentially, the assign optimization (nice gains, thank you) adds requirements on the container type. We have a custom string classes that does not support it, but has a += member.

So any use of tokenizer on these fails to compile. I sadly had to revert back to 1.31 behavior until this gets resolved.

Thanks, -seb

...

--

You are welcome for the speed up.

I thought the only additional constraint was that the container needed a constructor that took two iterators --- is there a reason you can't add such a constructor to your custom string class?

Hmm, I am pretty sure that duck-typing for ::assign is the issue here, not the c'tor. I may be wrong. The string class is widely used in our codebase, accross several teams and through several projects. To use it with Tokenizer in my particular project, I created forward iterators with boost.iterator. It would be very difficult and impractical for me to change the string interface. If I did, I would have to add custom iterators to the class as well because I cannot expose any of boost in that particular interface. -seb

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost