STL algorithms fiasco?

Discussion in 'C++' started by Diego Martins, Feb 27, 2007.

  1. each day, I am getting convinced the current STL algorithms (e.g:
    for_each) are only useful in few or trivial cases

    a good example is dealing with "private classes". let's imagine a
    Collection class which is responsible for creating and owning
    CollectionItem objects

    so, making Collection a friend of CollectionItem allows me to declare
    CollectionItem constructor and destructor private.
    with that, I am sure only Collection will create and destroy
    CollectionItem objects

    so, I have something like that:

    Collection ctor:
    {
    data.push_back(new CollectionItem);
    ....
    }

    Collection dtor:
    {
    for( int x = 0; x < data.size(); ++x ) {
    delete data[x];
    }

    this works fine, but it won't compile if I use for_each in dtor

    see:

    /** generic pointer deleter */
    template<typename T>
    inline void deleter(T * ptr) { delete ptr; }

    Collection dtor:
    {
    for_each(data.begin(),data.end(),&deleter<CollectionItem>);
    }

    it only will compile if CollectionItem dtor is made public :( :( :(

    do we have to wait until lambda or closure things appear? and will
    they work in the case presented above?

    Diego
     
    Diego Martins, Feb 27, 2007
    #1
    1. Advertising

  2. Diego Martins wrote:
    > each day, I am getting convinced the current STL algorithms (e.g:
    > for_each) are only useful in few or trivial cases
    >
    > a good example is dealing with "private classes". let's imagine a
    > Collection class which is responsible for creating and owning
    > CollectionItem objects
    >
    > so, making Collection a friend of CollectionItem allows me to declare
    > CollectionItem constructor and destructor private.
    > with that, I am sure only Collection will create and destroy
    > CollectionItem objects
    >
    > so, I have something like that:
    >
    > Collection ctor:
    > {
    > data.push_back(new CollectionItem);
    > ...
    > }
    >
    > Collection dtor:
    > {
    > for( int x = 0; x < data.size(); ++x ) {
    > delete data[x];
    > }
    >
    > this works fine, but it won't compile if I use for_each in dtor
    >
    > see:
    >
    > /** generic pointer deleter */
    > template<typename T>
    > inline void deleter(T * ptr) { delete ptr; }
    >
    > Collection dtor:
    > {
    > for_each(data.begin(),data.end(),&deleter<CollectionItem>);
    > }
    >
    > it only will compile if CollectionItem dtor is made public :( :( :(
    >
    > do we have to wait until lambda or closure things appear? and will
    > they work in the case presented above?


    A note: if you make 'deleter' a [static] member of 'Collection',
    it should work, no?

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Feb 27, 2007
    #2
    1. Advertising

  3. On Feb 27, 11:35 am, "Victor Bazarov" <> wrote:
    > Diego Martins wrote:
    > > each day, I am getting convinced the current STL algorithms (e.g:
    > > for_each) are only useful in few or trivial cases

    >
    > > a good example is dealing with "private classes". let's imagine a
    > > Collection class which is responsible for creating and owning
    > > CollectionItem objects

    >
    > > so, making Collection a friend of CollectionItem allows me to declare
    > > CollectionItem constructor and destructor private.
    > > with that, I am sure only Collection will create and destroy
    > > CollectionItem objects

    >
    > > so, I have something like that:

    >
    > > Collection ctor:
    > > {
    > > data.push_back(new CollectionItem);
    > > ...
    > > }

    >
    > > Collection dtor:
    > > {
    > > for( int x = 0; x < data.size(); ++x ) {
    > > delete data[x];
    > > }

    >
    > > this works fine, but it won't compile if I use for_each in dtor

    >
    > > see:

    >
    > > /** generic pointer deleter */
    > > template<typename T>
    > > inline void deleter(T * ptr) { delete ptr; }

    >
    > > Collection dtor:
    > > {
    > > for_each(data.begin(),data.end(),&deleter<CollectionItem>);
    > > }

    >
    > > it only will compile if CollectionItem dtor is made public :( :( :(

    >
    > > do we have to wait until lambda or closure things appear? and will
    > > they work in the case presented above?

    >
    > A note: if you make 'deleter' a [static] member of 'Collection',
    > it should work, no?
    >
    > V


    you're right.
    in this case, I'll have to abandon this generic function and put it
    inside collection.
    or put a friend declaration to the deleter...

    I think this is excessive verbose for using a STL algorithm :(

    many languages have a construct similar to this:
    for each Item in Collection {
    use Item;
    }

    a std::transform could be generalized like that:
    // sum algorithm
    for each (Item1, Item2, Item3) in (Col1,Col2,Col3) { Item1 =
    Item2+Item3; }

    :(
     
    Diego Martins, Feb 27, 2007
    #3
  4. Hello,

    Diego Martins wrote:

    >
    > many languages have a construct similar to this:
    > for each Item in Collection {
    > use Item;
    > }


    The thing coming closest would be boost::lambda or similar libraries,
    there are functors in the current STL as well.

    >
    > a std::transform could be generalized like that:
    > // sum algorithm
    > for each (Item1, Item2, Item3) in (Col1,Col2,Col3) { Item1 =
    > Item2+Item3; }


    I cannot make any sense out of this. Does it mean that that every
    element in Col1 is assigned the sums of any element in Col2 and any
    element in Col3? Why so many assignments to the same place, why
    assigning all elements in Col1 the sum of the last elements of Col2 and
    Col3?

    STL has taken the way of ranges (begin,end), not the "item in Container"
    idiom, because ranges can be done without language extensions, and they
    extend pointer ranges in a natural way, so it can even be used with
    pointers, which comes handy at times, e.g. initialization.

    Bernd Strieder
     
    Bernd Strieder, Feb 27, 2007
    #4
  5. Diego Martins

    Piyo Guest

    Bernd Strieder wrote:
    > Hello,
    >
    > Diego Martins wrote:
    >
    >> many languages have a construct similar to this:
    >> for each Item in Collection {
    >> use Item;
    >> }

    >
    > The thing coming closest would be boost::lambda or similar libraries,
    > there are functors in the current STL as well.
    >
    >> a std::transform could be generalized like that:
    >> // sum algorithm
    >> for each (Item1, Item2, Item3) in (Col1,Col2,Col3) { Item1 =
    >> Item2+Item3; }

    >
    > I cannot make any sense out of this. Does it mean that that every
    > element in Col1 is assigned the sums of any element in Col2 and any
    > element in Col3? Why so many assignments to the same place, why
    > assigning all elements in Col1 the sum of the last elements of Col2 and
    > Col3?
    >
    > STL has taken the way of ranges (begin,end), not the "item in Container"
    > idiom, because ranges can be done without language extensions, and they
    > extend pointer ranges in a natural way, so it can even be used with
    > pointers, which comes handy at times, e.g. initialization.
    >
    > Bernd Strieder
    >

    He is trying to advocate python-like syntax in C++. That construct
    means, take each element in each collection and put them in
    a tuple (Item1, Item2, Item3) where Item1 is an element of Col1,
    Item2 is an element of Col2, etc. Then process them. To some degree
    I do find it convenient to use such a syntax but then again, this is
    not python. I am a strongly-typed person :)
     
    Piyo, Feb 27, 2007
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    1
    Views:
    436
    jlowery05
    Mar 24, 2006
  2. Boris
    Replies:
    5
    Views:
    1,098
    Fei Liu
    Apr 19, 2006
  3. Steve Folly
    Replies:
    3
    Views:
    479
    James Kanze
    Apr 20, 2007
  4. anon
    Replies:
    0
    Views:
    450
  5. Andrea Crotti

    Static initialization fiasco!

    Andrea Crotti, Nov 16, 2010, in forum: C++
    Replies:
    1
    Views:
    361
    Victor Bazarov
    Nov 16, 2010
Loading...

Share This Page