«

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<Collecti onItem>);
}

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 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<Collecti onItem>);
> }
>
> 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

On Feb 27, 11:35 am, "Victor Bazarov" <v.Abaza...@comAcast.net> 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<Collecti onItem>);
> > }
>
> > 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; }

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 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