<algorithm> transform modification

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Jerry Coffin

    #16
    Re: &lt;algorithm&g t; transform modification

    In article <f9b47917.03092 10613.16373a9b@ posting.google. com>,
    s.z.s@web.de says...[color=blue]
    > Jerry Coffin <jcoffin@taeus. com> wrote in message news:<MPG.19d6d cde10e03cd0989b 0a@news.clspco. adelphia.net>.. .[color=green]
    > >
    > > See $ 17.4.3.1/1 for the exact requirements.[/color]
    >
    > Where do I find that?[/color]

    That's section 17.4.3.1, paragraph 1, of the C++ standard. If you don't
    have a copy, you can get one as a PDF file for $18US from
    webstore.ansi.o rg (this requires a credit or debit card they'll accept).

    The DIN only seems to sell the paper version, at a much less attractive
    price (242,70 Euros). You can also get it direct from the ISO (in
    either PDF or paper format) for 364 CHF, which is roughly typical for a
    paper copy, but clearly pretty high for a PDF.

    Various other national bodies sell it as well, but I don't know of any
    that sell the PDF for less than ANSI does. If you decided to get the
    paper version, shipping costs would probably favor buying locally.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.

    Comment

    • Howard Hinnant

      #17
      Re: &lt;algorithm&g t; transform modification

      In article <3f6de554@news. greennet.net>,
      "Fraser Ross" <fraserATmember s.v21.co.united kingdom> wrote:
      [color=blue][color=green]
      > > You might try out std::bind2nd in <functional> and stick with the
      > > std::transform:
      > >
      > > std::transform( v.begin(), v.end(), v.begin(),
      > > std::bind2nd(st d::multiplies<i nt>(), 3));[/color]
      >
      > Is there a reason for not using for_each? I have been wondering if for_each
      > is faster.[/color]

      I think it would be a matter of convenience rather than performance.
      for_each could certainly be used here. But the use of for_each looks
      more complicated to me than does transform.

      On the inside transform will do something like:

      *target = op(*source);

      whereas for_each will do something like:

      op(*source);

      In our example, we're wanting to do:

      *target = *target * 3;

      or maybe:

      *target *= 3;

      So to use for_each you have to cook up a functor that takes a single
      argument and performs the desired operation (both times and assign, or
      the combined *=). There is no std::multiply_a ssign, but you could roll
      your own:

      template <class T, class U = T>
      struct multiply_assign
      : public std::binary_fun ction<T, U, T>
      {
      T& operator()(T& t, const U& u) const
      {return t *= u;}
      };

      Then you could use this with for_each and bind2nd like:

      std::for_each(v .begin(), v.end(),
      std::bind2nd(mu ltiply_assign<i nt>(), 3));

      I would expect this example to have the same performance as the
      transform version, but I have not tested that expectation.

      -Howard

      Comment

      • Fraser Ross

        #18
        Re: &lt;algorithm&g t; transform modification

        transform might be as fast if return value optimisation is used. I would
        prefer another algorithm for when the output iterator is the same as an
        input iterator and two ranges are used. That isn't the situation the OP
        has. e.g.

        template <class ForwardIterator , class InputIterator, class BinaryOperation >
        BinaryOperation transform_each (ForwardIterato r first1, InputIterator last1,
        InputIterator first2, BinaryOperation binary_op) {
        while (first1 != last1) {
        binary_op(*firs t1, *first2);
        ++first1, ++first2;
        }
        return binary_op;
        }


        Fraser.


        ---
        Outgoing mail is certified Virus Free.
        Checked by AVG anti-virus system (http://www.grisoft.com).
        Version: 6.0.520 / Virus Database: 318 - Release Date: 18/09/2003


        Comment

        • Steffen Brinkmann

          #19
          Re: &lt;algorithm&g t; transform modification

          Sorry, pressed the wrong key.[color=blue]
          >
          > Is there a reason for not using for_each?[/color]

          As I said, I'd have to write sth like

          void f(double val){ val+=2.;}

          and then call

          for_each(v.begi n(),v.end(),f() );

          What, if it is noct 2. but a value that is calculated at runtime?

          Steffen

          Comment

          • red floyd

            #20
            Re: &lt;algorithm&g t; transform modification

            Steffen Brinkmann wrote:
            [color=blue]
            > Sorry, pressed the wrong key.
            >[color=green]
            >>Is there a reason for not using for_each?[/color]
            >
            >
            > As I said, I'd have to write sth like
            >
            > void f(double val){ val+=2.;}
            >
            > and then call
            >
            > for_each(v.begi n(),v.end(),f() );
            >
            > What, if it is noct 2. but a value that is calculated at runtime?
            >
            > Steffen[/color]

            use a functor... There's probably a standard one that I can't remember at this time, but here's one,
            and I realize I may have the syntax/semantics of for_each() slightly messed up. Please have pity, gurus!

            struct add_value {
            double val;
            add_value (val_) : val(val_) { }
            double operator()(doub le& d) { return d += val; }
            }

            then you can call:

            for_each(v.begi n(), v.end(), add_value(some_ calculated_valu e_here));


            Comment

            • Steffen Brinkmann

              #21
              Re: &lt;algorithm&g t; transform modification

              Hi!

              Thank you all for your postings and learned a lot.
              My solution is to use bind2nd(..) and only the stl without specialisation.

              Thanks again

              I'm out of here, Steffen

              Comment

              Working...