Hi Pavol, For upcoming 1.34.1 Any chance of making iter_find, iter_split documented. If no chance then can you consider allowing passing the FinderT Finder in iter_join(..., FinderT Finder) and iter_split(FinderT Finder) as parameters to find_all and split. or should we always just use find_iterator/split_iterator (bit more coding :-) and write our own wrappers around them... Thanks Shams --
Hi, If you document... Does this mean you officially approve of iter_find and iter_split to usuable in production code? How about renaming them to iterator_find and iterator_split then :-) Thanks Shams -- "Pavol Droba" <droba@topmail.sk> wrote in message news:464BF4B7.3030801@topmail.sk...
Shams wrote:
Hi Pavol,
For upcoming 1.34.1
Any chance of making iter_find, iter_split documented.
I will do it if I will be allowed to.
Question to release manager: Is it ok to commit documentation into RC_1_34_0 branch?
Regards, Pavol.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Shams wrote:
Hi,
If you document...
Does this mean you officially approve of iter_find and iter_split to usuable in production code?
This was alredy discussed a long time ago. I have nothing against. The whole point of hiding them was raise in the review, when iterator-base approach was considered to be superior. However from the user responses it seems, the iter_find/split approach is also quite useful.
How about renaming them to iterator_find and iterator_split then :-)
iter is an abrevation of iterative, not iterator. It has actualy nothing to do with iterators. Regards, Pavol.
participants (2)
-
Pavol Droba -
Shams