using for_each

I prefer for_each or transform. (transform over for_each, actually, as it's more explicit in what it does.)

I agree. for_each is like a fallback when you want to iterate over a range but nothing else comes to mind.

transform being the non-destructive version.

It can be destructive too, if the output range is the input range.

Originally Posted by CornedBee

You're not linking against the standard C++ library. Make sure you call g++, not gcc, to compile the code.

Thanks, indeed I was using gcc. I thought it was the same as g++ and it was easier to type. guess I was wrong. (-:

g++ is the same as gcc, except that it has some default options for C++. The most important among them is -lstdc++.

Originally Posted by laserlight

It depends on what the function does. In general, you should prefer non-member non-friend (i.e. free) functions to member functions or friend functions.

Why? because it is easier to compile?
I want to adopt a proper style. Is it really the common/good practice to make functions/functors which are passed to STL, free?
Surely it should be free if it can be reused but what about functions/functors that are specific to a class container?

In this case, the function does not access any members of the class, so it really is best as a free function.

Never mind this case. This is not a real example. just a small program to try to figure out how to pass functions/functors to STL algorithms.

Why? because it is easier to compile?

No. I suggest reading GotW #84: Monoliths "Unstrung".

I want to adopt a proper style. Is it really the common/good practice to make functions/functors which are passed to STL, free?
Surely it should be free if it can be reused but what about functions/functors that are specific to a class container?

Refer to GotW #84.

Originally Posted by laserlight

No. I suggest reading GotW #84: Monoliths "Unstrung".

Thanks, that was very interesting.

But how do we prevent namespace pollution?
Should I put all those nonmembers in some header and have it included when needed?
I know this might seem a silly question, but I really like to know.

Originally Posted by kroiz

But how do we prevent namespace pollution?

That article has a paragraph about that:

Namespace pollution. Because empty() is such a common name, putting it at namespace scope risks namespace pollution -- after all, will every function named empty() want to have exactly these semantics? This argument is also valid to a point, but weakened in two ways: First, by noting that encouraging consistent semantics for functions is a Good Thing; and second, by noticing that overload resolution has turned out to be a very good tool for disambiguation, and namespace pollution has never been as big a problem as some have made it out to be in the past. Really, by putting all the names in one place and sharing implementations, we're not polluting that one namespace as much as we're sanitizing the functions by gathering them up and helping to avoid the gratuitous and needless incompatibilities that Meyers mentions (see above).

Originally Posted by kroiz

Should I put all those nonmembers in some header and have it included when needed?

The free functions are still part of the public interface of your class, so it makes sense to put them in the same header as the class. Of course, if you are providing them as some optional extension to the basic functionality provided by your class, then it would be better to separate them into another header.

Got it. Thanks.