std:.transform 
Author Message
 std:.transform

the following is taken from MSVC7.1 documentation:
could please someone explain the last remark?
I don't see why it's necessary: if I have a vector of size 10, can I
transform (begin, begin+5) into (begin+1, begin+6)?

Transform

Applies a specified function object to each element in a source range or to
a pair of elements from two source ranges and copies the return values of
the function object into a destination range.

template<class InputIterator, class OutputIterator, class UnaryFunction>
   OutputIterator transform(
      InputIterator _First1,
      InputIterator _Last1,
      OutputIterator _Result,
      UnaryFunction _Func
   );

[...]

If _Result is set equal to _First1 in the first version of the algorithm,
then the source and destination ranges will be the same and the sequence
will be modified in place. But the _Result may not address a position within
the range [_First1 +1, _Last1).

--
 A solution is a solution.
-- Mycroft Holmes



Fri, 23 Dec 2005 18:59:13 GMT  
 std:.transform



Quote:
> the following is taken from MSVC7.1 documentation:
> could please someone explain the last remark?
> I don't see why it's necessary: if I have a vector of size 10, can I
> transform (begin, begin+5) into (begin+1, begin+6)?

No, becase that would probably overwrite the input before is was
processed. The restriction is there so that std::transform would not
be required to copy the input to protect it.

Bo Persson

Quote:

> Transform

> Applies a specified function object to each element in a source
range or to
> a pair of elements from two source ranges and copies the return
values of
> the function object into a destination range.

> template<class InputIterator, class OutputIterator, class
UnaryFunction>
>    OutputIterator transform(
>       InputIterator _First1,
>       InputIterator _Last1,
>       OutputIterator _Result,
>       UnaryFunction _Func
>    );

> [...]

> If _Result is set equal to _First1 in the first version of the
algorithm,
> then the source and destination ranges will be the same and the
sequence
> will be modified in place. But the _Result may not address a
position within
> the range [_First1 +1, _Last1).

> --
>  A solution is a solution.
> -- Mycroft Holmes



Fri, 23 Dec 2005 19:35:40 GMT  
 std:.transform

Quote:
> > I don't see why it's necessary: if I have a vector of size 10, can I
> > transform (begin, begin+5) into (begin+1, begin+6)?

> No, becase that would probably overwrite the input before is was
> processed. The restriction is there so that std::transform would not
> be required to copy the input to protect it.

Thanks.

So I guess I can transform (begin+1, begin+6) into (begin, begin+5)
--
 Every idea yields an answer
-- Abercrombie Smith



Fri, 23 Dec 2005 20:00:00 GMT  
 std:.transform

Quote:
> the following is taken from MSVC7.1 documentation:
> could please someone explain the last remark?
> I don't see why it's necessary: if I have a vector of size 10, can I
> transform (begin, begin+5) into (begin+1, begin+6)?

> Transform

> Applies a specified function object to each element in a source range
or to
> a pair of elements from two source ranges and copies the return values
of
> the function object into a destination range.

> template<class InputIterator, class OutputIterator, class
UnaryFunction>
>    OutputIterator transform(
>       InputIterator _First1,
>       InputIterator _Last1,
>       OutputIterator _Result,
>       UnaryFunction _Func
>    );

> [...]

> If _Result is set equal to _First1 in the first version of the
algorithm,
> then the source and destination ranges will be the same and the
sequence
> will be modified in place. But the _Result may not address a position
within
> the range [_First1 +1, _Last1).

Actually, the C++ standard does not seem to require that input and
output ranges not overlap. But it does not provide a reasonable behavior
for this case either. You can transform (begin, begin+5) into (begin+1,
begin+6), but it won't do what you probably expect it to do. It will
take an element at begin, apply the transformation, and save to begin+1.
Then it'll take an element at begin+1 (the one it has just written
there), transform it (so it becomes Func(Func(*begin)) ) and store at
begin+2. And so on. Original values at (begin + 1, begin + 5) are
irretrievably lost and have no effect on the result of the
transformation - probably a surprise.

You can use reverse iterators to process overlapped ranges like this.
Under the clarification given in DR 293 [1], transform is required to
process the elements in iterator order, from first to last. Use revese
iterators to process the range backwards.

[1] http://std.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#293

--
With best wishes,
    Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken



Fri, 23 Dec 2005 22:30:34 GMT  
 std:.transform

Quote:
> > > I don't see why it's necessary: if I have a vector of size 10, can I
> > > transform (begin, begin+5) into (begin+1, begin+6)?

> > No, becase that would probably overwrite the input before is was
> > processed. The restriction is there so that std::transform would not
> > be required to copy the input to protect it.

> Thanks.

> So I guess I can transform (begin+1, begin+6) into (begin, begin+5)

I don't see any obvious problems with doing that.  Like Igor said, you can
also process your original ranges using reverse iterators.

Ken



Fri, 23 Dec 2005 23:26:26 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. std::transform problem

2. error C2440 when using std::transform in a DLL

3. No std::min or std::max?

4. bug: VS7.0 (6.0) C++ std::auto_ptr conflict with std::vector

5. convert between std::string and std::wstring

6. convert non std::string to std::string

7. Warnings for std::vector<std::string>

8. export classes using std namespace (ex std::vector) in a DLL

9. typedef std::vector<std::string> Vector_String

10. VC6, STL, std::set_new_handler and std::bad_alloc

11. std::cout and std::cerr

12. std::ostream_iterator does not work with std::pair

 

 
Powered by phpBB® Forum Software