I agree. for_each is like a fallback when you want to iterate over a range but nothing else comes to mind.I prefer for_each or transform. (transform over for_each, actually, as it's more explicit in what it does.)
It can be destructive too, if the output range is the input range.transform being the non-destructive version.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
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++.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
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?
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.In this case, the function does not access any members of the class, so it really is best as a free function.
No. I suggest reading GotW #84: Monoliths "Unstrung".Why? because it is easier to compile?
Refer to GotW #84.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?
Look up a C++ Reference and learn How To Ask Questions The Smart Way
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.
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).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.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
Got it. Thanks.
