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
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