From: Sebastien Martel (smartel_at_[hidden])
Date: 2005-06-08 16:16:20
Robert Zeh wrote:
> Sebastien Martel <smartel_at_[hidden]> writes:
>> 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.
> 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.
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk