Hi, I started using the filter/split-iterators from the string-algorithm. today, and liked them a lot. However, I think some improvements would make them even better: 1. Provide const overloads for make_foo_iterator funcs. Currently, I can't use those functions to search f.ex. a const std::string. Works fine when using the constructor directly though. 2. Make the filter_type public or templated (with boost::function as default). Simply because I'd like to avoid dynamic memory allocation when in functions creating those iterators. It feels a bit unnecessary and I can't create something of filter_iterator_base::finder_type, since it's protected. Does it sound reasonable? Cheers, /Marcus
Hi, Marcus Lindblom wrote:
Hi,
I started using the filter/split-iterators from the string-algorithm. today, and liked them a lot. However, I think some improvements would make them even better:
I assume, you mean find/split iterators.
1. Provide const overloads for make_foo_iterator funcs. Currently, I can't use those functions to search f.ex. a const std::string. Works fine when using the constructor directly though.
The make_foo_iterator functions can handle both const and non-const sequences. The resulting type depends on the constness of the input. So no special const overload is necessary.
2. Make the filter_type public or templated (with boost::function as default). Simply because I'd like to avoid dynamic memory allocation when in functions creating those iterators. It feels a bit unnecessary and I can't create something of filter_iterator_base::finder_type, since it's protected.
I'm not really sure what you are trying to achieve. boost::function is used to to handle the type erasure. As far as I know, it is not possible to do this without some dynamic allocation and virtualization. Without the type erasure, the find_iterators would have to be templated by the finder type. Regards, Pavol.
Pavol Droba wrote:
I assume, you mean find/split iterators.
Yes. Sorry about that.
1. Provide const overloads for make_foo_iterator funcs. Currently, I can't use those functions to search f.ex. a const std::string. Works fine when using the constructor directly though. The make_foo_iterator functions can handle both const and non-const sequences. The resulting type depends on the constness of the input. So no special const overload is necessary.
Indeed. I must've messed up my const definitions. I also confused range_result_iterator with range_iterator.
2. Make the filter_type public or templated (with boost::function as default). Simply because I'd like to avoid dynamic memory allocation when in functions creating those iterators. It feels a bit unnecessary and I can't create something of filter_iterator_base::finder_type, since it's protected.
I'm not really sure what you are trying to achieve. boost::function is used to to handle the type erasure. As far as I know, it is not possible to do this without some dynamic allocation and virtualization. Without the type erasure, the find_iterators would have to be templated by the finder type.
That was what I was thinking. They could be templated there, but using boost::function as a default template arg. This would provide type erasure by default, but allow higher performance where needed. Since it's already templated on one type, it might as well be on one more, or? It's a minor thing though. Sorry for the noise. /Marcus
Hi,
2. Make the filter_type public or templated (with boost::function as default). Simply because I'd like to avoid dynamic memory allocation when in functions creating those iterators. It feels a bit unnecessary and I can't create something of filter_iterator_base::finder_type, since it's protected.
I'm not really sure what you are trying to achieve. boost::function is used to to handle the type erasure. As far as I know, it is not possible to do this without some dynamic allocation and virtualization. Without the type erasure, the find_iterators would have to be templated by the finder type.
That was what I was thinking. They could be templated there, but using boost::function as a default template arg. This would provide type erasure by default, but allow higher performance where needed. Since it's already templated on one type, it might as well be on one more, or?
Without the type erasure, the usage of iterators would get less convenient. For example, you would not be able to compare iterators with different finders. This is manifested when using default constructed find iterator as end-of-search tag. Anyway, maybe the default template argument is a way to go. I will think about it.
It's a minor thing though. Sorry for the noise.
No problem. Every suggestion is worth consideration. Regards, Pavol.
Pavol Droba wrote:
Hi, [snip] Without the type erasure, the usage of iterators would get less convenient. For example, you would not be able to compare iterators with different finders. This is manifested when using default constructed find iterator as end-of-search tag.
You could perhaps make the == operator templated, forcing character but not finder equivalence? (Since you're only checking the position anyway?) (And provide a stronger equals() that checks the finder argument too?) Just tossing ideas. :) Cheers, /Marcus
participants (2)
-
Marcus Lindblom -
Pavol Droba