Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > STL algorithms fiasco?

Reply
Thread Tools

STL algorithms fiasco?

 
 
Diego Martins
Guest
Posts: n/a
 
      02-27-2007
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

 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      02-27-2007
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


 
Reply With Quote
 
 
 
 
Diego Martins
Guest
Posts: n/a
 
      02-27-2007
On Feb 27, 11:35 am, "Victor Bazarov" <(E-Mail Removed)> 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; }



 
Reply With Quote
 
Bernd Strieder
Guest
Posts: n/a
 
      02-27-2007
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

 
Reply With Quote
 
Piyo
Guest
Posts: n/a
 
      02-27-2007
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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
STL algorithms and output iterators Generic Usenet Account C++ 1 10-05-2007 03:19 AM
STL Vector and unique/sort algorithms Suma C++ 2 11-15-2005 12:58 PM
STL sorting algorithms Ark C++ 1 02-21-2005 01:25 PM
std::map::iterator with STL algorithms rg C++ 1 07-22-2004 10:31 AM
Table with complexity of all STL structures, algorithms... Gawelek C++ 0 11-23-2003 06:35 PM



Advertisments