STL Algorithms

[Zac Howland]

If it does, great ... just know that the compiler documentation says otherwise: MSDN[^]

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac

[Stephen Hewitt]

Well it seems to be a mistake or an oversimplification. From the code I posted here[^] it can be seen that:  1. Both the function and functor versions produce exactly the same code.  2. Both versions have no call instructions.  3. The add and imul instructions which do the actual math can be seen in place. I often find it enlightening to look at the code generated by the compiler. One surprise I had recently was when I was evaluating the Boost BOOST_FOREACH macro. Although when you look at the source there is a fair bit of code behind it, when I actually looked at the code generated in a release build it was actually smaller and more efficient then a hand written loop.

Steve

[Nemanja Trifunovic]

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

Nope, lambdas are going to be included as a language feature, not a library. See here[^]

Programming Blog utf8-cpp

[Zac Howland]

Nemanja Trifunovic wrote:

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

Looks like that is still a proposal. I'm not sure how I feel about that syntax ... the Boost lambda syntax is very easy to read, but that syntax seems to make it harder to read than writing a function or functor.

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac

[Stuart Dootson]

Mmmm - shame they don't combine type inference and lambda - then you could get rid of the type annotations, like with Haskell - but I guess you can't, 'cause you could end up with polymorphic functions, like this in Haskell:

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

will have a type of

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

, or, in pseudo-C++, a (a x, a y) where a is some numeric type.

[Lost User]

BTW, I am using Boost 1.33.1 and don't seem to have BOOST_FOREACH - is this included with the 1.34 RC version?

[Stephen Hewitt]

No, it's not in 1.33.1. It's only one file however and can be downloaded from here[^]. As you can see it will be "shipped" with 1.34. I use 1.33 but added this file manually.

Steve

[Lost User]

Thanks Steve. Having problems using BOOST_FOREACH with a std::map though. For example, this won't compile:

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

This does work however:

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

Is there a way to avoid declaring the pair before the FOREACH loop?

[Stephen Hewitt]

This is because BOOST_FOREACH is a macro. See here[^]. There are many ways to fix this including a typedef or an extra pair of brackets, but in this case the best is the following: typedef std::map<int, int> collection_t; collection_t m; BOOST_FOREACH(collection_t::value_type p, m) { } In general, with of without using BOOST_FOREACH, it's best to use a typedef to define an alias to the collection type, here collection_t. This allows us to change the type of collection used in one place. Once this is done we use the value_type typedef which is in every STL collection. I'd probably use a reference, const if possible, like this: typedef std::map<int, int> collection_t; collection_t m; BOOST_FOREACH(const collection_t::value_type &p, m) { } In both these examples the actual type name of the collection is only mentioned in one place and so can be easily changed. When for hash maps are added to STL, for example, this would mean that you can switch between a hash map or binary tree by changing only one line.

Steve

[Lost User]

Steve, thanks again for another informative post! The value_type typedef is something I shall be using a lot more of in future.