You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently one have to construct/copy a second copy of transformation function for an end iterator what is unwanted and seems to be omission of the library design. For example, Boost.Range solves it via wrapping user functor with optional, unfortunately.
The text was updated successfully, but these errors were encountered:
Omitting the function object for an end iterator seems like a useful optimization, but the problem is that the end iterator can be made a non-end iterator by decrementing, and then the transform_iterator is expected to work.
I suppose, we could add a new factory function and create a specialized version of transform_iterator for an "end" iterator that will simply abort in runtime on increments, decrements and dereference. Unfortunately, this won't be caught at compile time as the respective operators need to be callable so that the iterator category is still correctly detected by the concepts.
Currently one have to construct/copy a second copy of transformation function for an end iterator what is unwanted and seems to be omission of the library design. For example, Boost.Range solves it via wrapping user functor with
optional
, unfortunately.The text was updated successfully, but these errors were encountered: