Hello, Wednesday, September 8, 2004, 10:04:24 AM, you wrote:
Pavol Droba wrote:
[snip]
Ok, noted. Though what I have now:
vector<string> parts; split(parts, p.options[i].string_key, is_any_of(".")); if (parts.size() > 2) modules.insert(parts[1]);
has roughly the same size.
split has a slightly bigger overhead, since it must make a copy of each part. With the iterator, you are traversing the input and it is up to you what will you do with it. Anyway, for your example, it does not matter too much probably.
BTW, looking at
http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/class.boost....
I don't see any explanation what's FinderT. Maybe the phrase
Split iterator encapsulates a Finder
I see. It seems like a good idea, unfortunately I don't know how to do it. Documentation is doxygen generated and I don't know how to make a link from the reference to the main docs :(
should include a link to the definition of the 'Finder' concept? Also, the name 'token_finder' is a bit misleading. I associate it with item returned by the lexer, which can have several characters. From the docs it seems that the 'token_finder' searches for a single character, so maybe it should be 'char_finder'? It looks like the word 'token' is used in just a couple of places.
It does not always search for a single character. If token_compress_mode is enabled, adjancent characters are combined to a single match. I think, that you are right, that token_finder is not the best name for this entity. However, I'm not sure if char_finder is the best fit either. I will think about it for a while. Regards, Pavol.