ATL / WTL / STL

Stephen Hewitt wrote:

typedef std::vector<whatever> collection_t;

collection_t coll;
// Fill 'coll' here...
for (collection_t::iterator i=vec.begin(); i!=vec.end(); ++i)
{
// Do stuff here...
}

Stephen Hewitt wrote:

This is an expression of the general design principle that one design decision should be expressed in only one place, if possible. In this case the choice of collection type only requires a change in one location and not scattered places throughout the code. STL and iterators don't make this happen automatically but they provide the abstractions to make this sort of thing possible.

Zac Howland wrote:

That still doesn't use STL's algorithms. Granted, it is reimplementing a for_each or a transform (depending on what you do in the loop), but the fact is it is still reimplementing it needlessly.

template <typename T>
struct square_plus_one : std::unary_function<T, T>
{
    T operator()(const T &v) const
    {
       return (v*v)+1;
    }
};
 
int main(int argc, char* argv[])
{
    typedef std::vector<int> collection_t;
 
    collection_t coll;
    // Fill 'coll' here...
    std::for_each(coll.begin(), coll.end(), square_plus_one<collection_t::value_type>());
 
    return 0;
}

typedef std::vector<int> collection_t;
 
collection_t coll;
// Fill 'coll' here...
for (collection_t::iterator i=vec.begin(); i!=vec.end(); ++i)
{
    *i = ((*i)*(*1))+1;
}

Zac Howland wrote:

Take a look at Scott Meyer's "Effective STL" for why this isn't really true.

Stephen Hewitt wrote:

Michael Dunn's objection to STL: having to write a "one off" functor.

template<class T> T square_plus_one(const T& i)
{
	return (i * i + 1);
}

int main()
{
	vector<int> intVec;
	// fill vector here
	transform(intVec.begin(), intVec.end(), intVec.begin(), square_plus_one<int> ) ;

	return 0;
}

Stephen Hewitt wrote:

What's not true? If I want to see if I get better performance or use less memory using a std::list I simply change one line - this is a fact. Not many people will think it's better to have to make multiple scattered changes and run the risk of introducing an error somewhere along the way. If you've got a specific point make it here as opposed to referring to a book but giving no clue to what to mean.

Zac Howland wrote:

You don't have to write a functor to use for_each, nor most of the other algorithms. Using your own example (and by the way, your for_each example actually does nothing but waste CPU cycles as written), the following works perfectly fine:

#include <iostream>
#include <vector>
#include <algorithm>
#include <iterator>
 
template <typename T>
T square_plus_one(const T& i)
{
    return (i * i + 1);
}
 
int main()
{
    // For notational convenience.
    using namespace std;
 
    vector<int> intVec;
 
    // Fill vector.
    for (int i=1; i<=10; ++i)
    {
       intVec.push_back(i);
    }
 
    // Transform the data.
    transform(intVec.begin(), intVec.end(), intVec.begin(), square_plus_one<int> );
 
    // Output the results.
    copy(intVec.begin(), intVec.end(), ostream_iterator<int>(cout, " "));
    cout << endl;
 
    return 0;
}

// Changed function so we compile and made inline.
inline int square_plus_one(int i)
{
    return (i * i + 1);
}
 
// Added a functor version for comparison:
struct functor_square_plus_one : std::unary_function<int, int>
{
    int operator()(int i) const
    {
       return (i * i + 1);
    }
};
 
// Altered transform:
transform(intVec.begin(), intVec.end(), intVec.begin(), square_plus_one) ;
 
// Added call to functor version:
transform(intVec.begin(), intVec.end(), intVec.begin(), functor_square_plus_one()) ;

// Using your method code is 0x2A bytes long.
//  transform(intVec.begin(), intVec.end(), intVec.begin(), square_plus_one);
004010DF   mov         ecx,dword ptr [esp+14h]
004010E3   mov         edx,dword ptr [esp+18h]
004010E7   mov         eax,ecx
004010E9   push        edi
004010EA   cmp         eax,edx
004010EC   mov         esi,edx
004010EE   je          main+89h (00401109)
004010F0   mov         edx,dword ptr [eax]
004010F2   add         eax,4
004010F5   mov         edi,edx
004010F7   add         ecx,4
004010FA   imul        edi,edx
004010FD   inc         edi
004010FE   cmp         eax,esi
00401100   mov         dword ptr [ecx-4],edi
00401103   jne         main+70h (004010f0)
00401105   mov         edx,dword ptr [esp+1Ch]
00401109
 
// Using my method code is identical.
//  transform(intVec.begin(), intVec.end(), intVec.begin(), functor_square_plus_one()) ;
004010DF   mov         ecx,dword ptr [esp+14h]
004010E3   mov         edx,dword ptr [esp+18h]
004010E7   mov         eax,ecx
004010E9   push        edi
004010EA   cmp         eax,edx
004010EC   mov         esi,edx
004010EE   je          main+89h (00401109)
004010F0   mov         edx,dword ptr [eax]
004010F2   add         eax,4
004010F5   mov         edi,edx
004010F7   add         ecx,4
004010FA   imul        edi,edx
004010FD   inc         edi
004010FE   cmp         eax,esi
00401100   mov         dword ptr [ecx-4],edi
00401103   jne         main+70h (004010f0)
00401105   mov         edx,dword ptr [esp+1Ch]
00401109

Zac Howland wrote:

What I meant is that the containers are not completely interchangible

Stephen Hewitt wrote:

Firstly in your example you've written a "one off" function instead of a "one off" functor, the same objection applies in this case.

Stephen Hewitt wrote:

Secondly, your code doesn't seem to work. Try compiling this: ... I'm not sure if this is a compiler bug or what (MSVC6) but regardless it's a problem.

Stephen Hewitt wrote:

As to the “wasted cycles” I concede that I made a mistake in that the results of my calculations are never used (oops). Functors are no less efficient in general however, consider the following. I've altered the code as follows:

Stephen Hewitt wrote:

inline int square_plus_one(int i)
{
return (i * i + 1);
}

Stephen Hewitt wrote:

From what I hear from experts there are cases in which the functor version is actually more efficient as many compilers find it easier to inline a functor then code via a function pointer.

Zac Howland wrote:

Just an FYI, when you pass the function to an algorithm, the compiler immediately ignores the inline request.

Steve Echols wrote:

This makes much more sense to me (but I'm old school):

vector<whatever> vec;
for (int i = 0; i < vec.size(); i++)
{
}

than

vector<whatever> vec;
vector<whatever>::iterator it;
for (it = vec.begin(); it != vec.end(); it++)
{
}

vector<whatever> vec;
// fill it somewhere
// DoSomething is declared and implemented somewhere
for_each(vec.begin(), vec.end(), DoSomething);

Zac Howland wrote:

Why is it that so many people don't use the STL algorithms?

Kevin McFarlane wrote:

I guess there are probably some old school C/C++ devs who cannot see any reason to move beyond what they consider to be tried-and-tested. This basically means when you maintain their code you are typically met with a mixture of error-prone C and old-style C++.

Zac Howland wrote:

I can understand that (even though I disagree with the reasoning, "I've always done it this way ..." -- that isn't a reason in my opinion)

Zac Howland wrote:

many of the questions I've seen are coming from either those that are still in college or those that are fresh out of college.

Kevin McFarlane wrote:

Doesn't say much for the state of CS courses does it?

foreach (int i, vecInts)
{
    cout << i;
}

#include <boost/foreach.hpp>
#define foreach BOOST_FOREACH

template <typename T, typename O> void for_all(T& t, O o)
{
	std::for_each(t.begin(), t.end(), o);
}

vector<int> vec;
...
for_all(vec, func);

Robert Edward Caldecott wrote:

I am also investigating boost::lambda, but it seems to get more complicated when using containers of smart pointers

#define VALUE(PTR) bind(&Symbols::ValuePtr::get, PTR)

   std::sort(allValues.begin(), allValues.end(), 
             bind(&Value::Address, VALUE(_1)) < bind(&Value::Address, VALUE(_2)));

Stuart Dootson wrote:

I suspect Boost.Lambda won't change to cope with smart pointers (I don't know how active its main developer Jaako Jarvi is?). However, Joel de Guzman's developed somethng very similar for Boost.Spirit (it's called Phoenix) and I'm sure I've heard talk of that being merged with lambda...or something.

Zac Howland wrote:

Many of them are already in tr1 (an std extension until the next standard is finalized). I know the smart pointers are already in there (I make use of them fairly heavily), and I think lambda is, but I'm not sure

Nemanja Trifunovic wrote:

Nope, lambdas are going to be included as a language feature, not a library.

(\x y -> 2*x + y)

(Num a) => a -> a -> a

std::map<int, int> m;
BOOST_FOREACH(std::pair<int, int> p, m)
{
}

std::map<int, int> m;
std::pair<int, int> p;
BOOST_FOREACH(p, m)
{
}

typedef std::map<int, int> collection_t;
collection_t m;
BOOST_FOREACH(collection_t::value_type p, m)
{
}

typedef std::map<int, int> collection_t;
collection_t m;
BOOST_FOREACH(const collection_t::value_type &p, m)
{
}