ATL / WTL / STL

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)
{
}