|
Zac Howland wrote: Just an FYI, when you pass the function to an algorithm, the compiler immediately ignores the inline request.
An inspection of the machine code I posted for both examples, the function and the functor, shows that in both cases the code was inlined. And this was with MSVC6, newer compilers may do even better.
Steve
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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++)
{
}
See, but neither is "correct". Assume you are calling DoSomething(const whatever& w) for each iteration of the loop. The entire loop can be written as follows:
vector<whatever> vec;
for_each(vec.begin(), vec.end(), DoSomething);
Using iterators in place of the index doesn't buy you anything in terms of taking advantage of the pre-made algorithms STL gives you.
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
|
|
|
|
|
Zac Howland wrote: Why is it that so many people don't use the STL algorithms?
When I first started using STL for some time I just used the basic containers and looped over them. The VC++ 6 docs were good enough to get going with this kind of thing. Algorithms and function objects seemed rather mysterious. But once I found out what they were about then I started using them. The trigger for me was having to maintain code that used STL heavily. Then I was forced to understand it. I also bought Stroustup 3rd ed and Josuttis.
I didn't do CS at college. My background is in civil engineering. 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++.
Kevin
|
|
|
|
|
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++.
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), but 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. I can almost understand seeing it from someone still in college if they are a first or second year CS or CPE major. But 3rd year+?
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
|
|
|
|
|
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)
I fully agree. I was just reporting how these guys think.
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.
Doesn't say much for the state of CS courses does it?
Kevin
|
|
|
|
|
Kevin McFarlane wrote: Doesn't say much for the state of CS courses does it?
No, actually, it scares me. These guys are making my degree less valuable
Of course, then there are the colleges that stopped teaching C/C++ as the primary language for CS majors and switch over to Java. I have yet to meet one of them that understands basic (language-independent) design principles because Java doesn't force you to learn them.
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
|
|
|
|
|
Another interesting library is Boost.Foreach. See details here[^]
This enables you to write code like this:
foreach (int i, vecInts)
{
cout << i;
}
This assumes the following:
#include <boost/foreach.hpp>
#define foreach BOOST_FOREACH
Steve
|
|
|
|
|
he he. Java-stylee!
One of my favourite helper templates comes straight from Bjorn Karlsson, author of "Beyond the C++ Standard Library: An Introduction to Boost":
template <typename T, typename O> void for_all(T& t, O o)
{
std::for_each(t.begin(), t.end(), o);
}
e.g.:
vector<int> vec;
...
for_all(vec, func);
I use this everywhere.
I am also investigating boost::lambda, but it seems to get more complicated when using containers of smart pointers. Early days, but I am head over heels in love with Boost!
|
|
|
|
|
Robert Edward Caldecott wrote: I am also investigating boost::lambda, but it seems to get more complicated when using containers of smart pointers
It does. If you're just using bind, then use boost::bind - it can cope with smart pointers (the boost ones at least!). Otherwise, I've defined macros to do bind the smart pointers get method, as below
#define VALUE(PTR) bind(&Symbols::ValuePtr::get, PTR)
std::sort(allValues.begin(), allValues.end(),
bind(&Value::Address, VALUE(_1)) < bind(&Value::Address, VALUE(_2)));
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.
Best place to ask is on the Boost developers list, I guess...
|
|
|
|
|
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.
Several of the Boost libraries are being considered as additions to the next standard. 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 ... something I'll have to double check.
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
|
|
|
|
|
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[^]
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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?
|
|
|
|
|
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
|
|
|
|
|
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?
|
|
|
|
|
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
|
|
|
|
|
Steve, thanks again for another informative post! The value_type typedef is something I shall be using a lot more of in future.
|
|
|
|
|
Hello Experts,
I am involved into developement of Toolbar for IE.
In that I have one drop down menu- button.
I want the menu items of this menu to be hyperlinks.
A single menu item can have more than on words each poiting to
different websites.
These menutems are owner-drawn.
Please tell me how I put hyperlinks on MenuItems.
I am using WTL.
Still,if anyone knows how to do it in MFC,let me know.
I will port it to WTL myself!!!!!!!!
Thanks in advance
|
|
|
|
|
Hyperlinks in menus? Huh? I thought a menuitem was a hyperlink of sorts...
--
Mit viel Oktan und frei von Blei, eine Kraftstoff wie Benziiiiiiin!
|
|
|
|
|
Did you see hyperlink on menus in a application?
|
|
|
|
|
hi all i m using the fopen fclose in ATL and it work fine with debug version when i change the project configuration to the Releasewithmindependancy then following errrs occurs.
d:\_TasleemWork\_bho\BhoNew_src\BhoNew\BhoApp.cpp(71): error C3861: 'fclose': identifier not found, even with argument-dependent lookup
d:\_TasleemWork\_bho\BhoNew_src\BhoNew\BhoApp.cpp(80): error C3861: 'fclose': identifier not found, even with argument-dependent lookup
d:\_TasleemWork\_bho\BhoNew_src\BhoNew\BhoApp.cpp(76): error C3861: 'fopen': identifier not found, even with argument-dependent lookup
d:\_TasleemWork\_bho\BhoNew_src\BhoNew\BhoApp.cpp(67): error C3861: 'fopen': identifier not found, even with argument-dependent lookup
d:\_TasleemWork\_bho\BhoNew_src\BhoNew\BhoApp.cpp(69): error C3861: 'fwrite': identifier not found, even with argument-dependent lookup
i dont know why these are bcos i m new in ATL
Tasleem Arif
|
|
|
|
|
tasleem143 wrote: Releasewithmindependancy
This is your problem - fopen, etc. are part of the C runtime library and a "min dependency" release won't include it. You need to change the project settings and change "Minimize CRT use in ATL" to "No".
|
|
|
|