Re: Intoductory Boost Presentation
Matt - The corrected code is indeed much better. May I suggest using std::vector instead of vector? The typedef of FooPtr is fine, it turns out; it's the typedef of struct Foo that was the problem. I had declared Foo within main as well, and that blocks the use of boost::shared_ptr on it. As long as Foo is declared at global scope, all is well. As for the correct output, my compiler gives me 3, then 2, then 1. I talked it over with a friend, and I guess the order of the 2 vs 1 is undefined, and depends on your STL's implementation of std::vector. As for the crazy aunt in the basement, the comment was meant for an internal list that only 20-30 people are on, not meant for general consumption, and probably merits an extra thread by itself. Put simply, using boost can generate a surprising amount of code and overhead. This is true of STL as well. There are even some good books describing STL; I happen to like Plauger/Stepanov/Lee/Musser, as well as Jasoutis. But nowhere do I see any reference as to what the downsides are - and nowhere do I see any concise explanation of why an enormous amount of code (660 bytes in an optimized, no-symbols build) is generated when I say something as simple as void Testbed(void) { boost::function<void> SimpleFPtr(&Testbed); } When you say "I was trying to generate interest in these libraries and thus didn't want to focus too much on the negatives", I can understand your point of view, but what I see in real life is that people start using boost::function everywhere they used to use plain old function pointers, with nary a clue that their code size just exploded with no benefit. But like I said, it's worth a whole other thread. Thanks for fixing the code and responding so quickly! jorg -----Original Message----- From: "Matt S Trentini" <matt_s_trentini@hotmail.com> Reply-To: Boost Users mailing list <boost-users@lists.boost.org> Date: Tue, 11 Nov 2003 23:19:12 +1100 To: boost-users@lists.boost.org Subject: [Boost-users] Re: Intoductory Boost Presentation Heya Jon, Ah, the smart_ptr example, I knew that would come back to bite me! ;) I changed this example at the last minute in an effort to simplify but, as your co-worker correctly points out, there are many errors in it. The correct code is below though the graphic requires change (yes, I could have change the list.push_front() to a push_back but I like to see the variety!). int main() { typedef boost::shared_ptr<Foo> FooPtr; vector<FooPtr> foo_vector; list<FooPtr> foo_list; FooPtr foo_ptr( new Foo(1) ); foo_vector.push_back( foo_ptr ); foo_list .push_back( foo_ptr ); foo_vector.push_back ( FooPtr( new Foo(2) ) ); foo_list .push_front( FooPtr( new Foo(3) ) ); } You'll notice that I left the typedef in there. I can't find anything in the standard (or with google) about it being illegal in main, nor does my compiler emit any warnings. Can anyone shed some light on this? And I've got to disagree with your friend about the correct ordering - the expected output is 3, 1, 2 (Remember that foo_ptr gets deleted first). I'll endeavour to fix this example up and upload the changes over the next couple of days. As for these comments:
The rest of the pages have the classic boost downfall: they don't discuss any of the pitfalls, performance problems, or code bloat issues, which frankly, seem like the "crazy aunt in the basement" of boost.
I'll defend myself on two fronts. First, it's an introductory presentation - I was trying to generate interest in these libraries and thus didn't want to focus too much on the negatives. Secondly, I _did_ cover some of those points - like all good presentations not everything is contained in the bullet points. Thanks for the feedback though, it's helping to make this presentation better! Cheers, Matt PS If there are any other problems that you or your co-worker have found please don't hesitate to report them! _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users ------ End of Forwarded Message
Heya Jorg,
The corrected code is indeed much better. May I suggest using std::vector instead of vector?
I considered doing this but decided not to. I felt (and still feel) that in a presentation it just adds noise. The presentation is really there to show concepts about using the boost library, not all the implementation details. Having std there simply makes the example harder to read in my opinion. You'll notice I've fully qualified some other namespaces where I thought that there was ambiguity.
As for the correct output, my compiler gives me 3, then 2, then 1. I talked it over with a friend, and I guess the order of the 2 vs 1 is undefined, and depends on your STL's implementation of std::vector.
Yep, Ben Hutching made this clear to me too - I should have known better. Will fix! :)
As for the crazy aunt in the basement, the comment was meant for an internal list that only 20-30 people are on, not meant for general consumption, and probably merits an extra thread by itself. Put simply, using boost can generate a surprising amount of code and overhead. This is true of STL as well. There are even some good books describing STL; I happen to like Plauger/Stepanov/Lee/Musser, as well as Jasoutis. But nowhere do I see any reference as to what the downsides are - and nowhere do I see any concise explanation of why an enormous amount of code (660 bytes in an optimized, no-symbols build) is generated when I say something as simple as
void Testbed(void) { boost::function<void> SimpleFPtr(&Testbed); }
When you say "I was trying to generate interest in these libraries and thus didn't want to focus too much on the negatives", I can understand your point of view, but what I see in real life is that people start using boost::function everywhere they used to use plain old function pointers, with nary a clue that their code size just exploded with no benefit.
But like I said, it's worth a whole other thread.
You make a valid point but I don't underestimate my peers - they're pretty cluey people who will figure out the issues. Especially when the Boost community generally goes to a fair effort to make limitations known. Like you said it's a whole thread in its own right - my take is that you shouldn't worry about optimising too much until your profiler tells you otherwise (Herb Sutter would be proud!).
Thanks for fixing the code and responding so quickly!
No worries - thanks for taking the time to give feedback! Cheers, Matt PS I don't own the Plauger/Stepanov/Lee/Musser book though the Josuttis text, and Meyers Effective STL, come highly recommended for STL development.
"Jorg Brown" <jorg@microsoft.com> writes:
nowhere do I see any concise explanation of why an enormous amount of code (660 bytes in an optimized, no-symbols build) is generated when I say something as simple as
void Testbed(void) { boost::function<void> SimpleFPtr(&Testbed); }
a. What's your analysis of the reasons? b. Which compiler are you using? -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (3)
-
David Abrahams -
Jorg Brown -
Matt S Trentini