2009/8/8 Björn Karlsson

template <typename U> T operator()(const std::pair& element) const { return element.second; } };

To enable writing to the element.second, shouldn't that 'second' extractor return a reference? - Rob. -- ACCU - Professionalism in programming - http://www.accu.org

...and now that we've seen the fundamental mechanics involved in using transform_iterator for this problem, here's a really terse version using two other useful libraries; Boost.Bind and Boost.Function.

1) Write a function object that extracts the second element of the pair. 2) Use the transform iterator adaptor to provide you with the type of the iterators for your class. 3) Use the helper function make_transform_iterator in your begin() and end() methods to create the iterators.

#include <list> #include <utility> #include "boost/iterator/transform_iterator.hpp" #include "boost/function.hpp" #include "boost/bind.hpp" class some_class { public: typedef std::list > container_type; typedef boost::transform_iterator< boost::function, container_type::iterator> iterator_type; iterator_type begin() { return boost::make_transform_iterator( container_.begin(), boost::bind(&container_type::value_type::second, _1)); } iterator_type end() { return boost::make_transform_iterator( container_.end(), boost::bind(&container_type::value_type::second, _1)); } private: container_type container_; }; We use boost::function to parameterize a very general unary function for transform_iterator. Then we use Boost.Bind to create a compatible function object that binds to the member second in std::pair. The advantages of this approach are that it's short, elegant, and all the logic is locally defined. (It's also quite cool.) However, you must know your audience -- not everyone is comfortable reading and understanding code like this. Cheers, Bjorn Karlsson www.skeletonsoftware.net

Hello Rob,

However I'm more interested in different takes on your final comment, "..., you must know your audience...".

Yes, this is one of the most important lessons I've learned the last decade or so.

I do struggle with this one at work sometimes - I'm generally inclined to write the kind of code you present, because it's good code, because it's the right solution, and because to do otherwise would be condescending and patronising to my colleagues. However, I sometimes find myself criticised for writing overly complex code, and by extension for not being a team player.

Any thoughts?

The code I presented can only be thought of as good code if programmers who need to understand it also know about: * STL (beyond spelling std::list) * Boost.Iterator * Boost.Function * Boost.Bind When my peers think I write overly complex code they are always right. There are two probable reasons: 1) I write overly complex code. 2) I'm wielding tools (in the language, libraries, or in the domain model) that are currently beyond them. The great opportunity here is to teach my peers about the tools I'm using. Or, if I find that there are no such tools, realize that I've written overly complex code and simplify it. Bjorn Karlsson www.skeletonsoftware.net

2009/8/12 Robert Jones

That seems at odds with 'best of breed' ideologies.

Can you elaborate on this? I'm sure I'm wrong, but for me it sounds like "if I'm different, I'm better". Roman Perepelitsa.

Hello Rob,

Taken to its logical extreme that would suggest that we should always be writing at the lowest common denominator of all participating programmers.

That seems at odds with 'best of breed' ideologies.

I agree, and that's why I advocate this approach: * Write the best code you possibly can using the best tools you have. (Boost has lots of magnificent tools.) * When your code and tools are too complex for your peers to understand, teach them what you know. My point regarding "when my peers think I write overly complex code they are always right"? It's that I have the power to change their minds by teaching them things I know that they previously didn't. Or I can learn from them how to write code that's only as complex as it needs to be. (It should be duly noted that I all too often fail to follow my own advice.) This is a very interesting topic and I've just published an article covering the Boost question we're talking about. It's called "Good Code && Good Advice", is packed with Boost usage, and you'll find it on www.skeletonsoftware.net/downloads.aspx. I guess this thread is slowly drifting off topic, but thank you for bringing it up! Cheers, Bjorn Karlsson

Hello Rob,

Nice article, and btw, it was your book that got me started with Boost, so it's all your fault really!

I gladly accept responsibility for that. :-)

ps, How about volume two, covering a few more libraries?

Yes, I'm currently planning a new Boost book. There's massive potential in these wonderful libraries, yet relatively little coverage in literature; that needs to change. I would love to know what everyone here wants from a new (general) Boost book. (Feel free to contact me off list with your thoughts.) Bjorn Karlsson www.skeletonsoftware.net

Björn Karlsson writes: [...]

I would love to know what everyone here wants from a new (general) Boost book. (Feel free to contact me off list with your thoughts.)

I can usually find detailed API docs online OK, and often code samples. What can be hard is getting a high-level overview of what's available, learning scenarios that the different classes were designed for, and finding the details that would let you decide which to use. For example, I can easily find the methods for shared_ptr, but what are the circumstances where I might want to use that? And when do I use auto_ptr vs. shared_ptr? Things that I know now after using both for awhile, but didn't know when I first started out. Basically, what would be useful to me would be the advice of an experienced C++/Boost programmer on how to get the most out of boost. As far as individual libraries, thorough documentation on asio would be very useful. Hope this feedback is helpful! -----Scott.

I would like to see Not too complex or complete 'use cases' with ASIO Regular expressions Spirit file io, threads documentation and logging frameworks serialization It would be good if each one of those examples, actually 'repeat' the use of some fundamental stuff -- so that reader of the book can get the taste of how shared pointers, functors, lambda functions, etc get to be applied in all of those examples. I had difficulties understanding how serialization works on std::set of shared pointers, for example, I would have not been able to use ASIO without the help of PION library (threaded http server built on top of asio) Examples of how to use thread local data storage were not intuitive to me either, typically thread local data storage is used to bind something like a File or DB connection to a thread -- and an example of such concept would be nice. Spirit is extremely useful thing to have, but of course has some learning curve, it has some good examples. However introducing the users to it 'lightly' in the context of the book would be nice. Things that are really 'unnatural' to do with regular expressions like 'balanced' parenthesis matching/etc are a lot more natural with Spirit. It would help users to understand the difference between a regular expressions and a full blown parser. There are several constant questions on the list about what I consider horrible omission of C++ standard UTF-8/16, Database access, JSON,XML parsing, RMI (remote method invocation) (surprisingly almost all of these things require to have 'Reflection' functionality in the core language). I know those things are not covered by Boost, but perhaps mentioning them and recommending a comparative overview of what's out there -- would be nice. Because Boost is not considered just as 'yet-another library' -- instead it is for us, the poor C++ programmers, that are bombarded with 'why not Java or C#' -- an escape, a show-case and a standard what C++ could be -- if would not be managed by ISO standardization committee all these years. On Fri, 14 Aug 2009 23:33 -0400, "Scott Gifford" wrote:

Björn Karlsson writes:

[...]

...

I would love to know what everyone here wants from a new (general) Boost book. (Feel free to contact me off list with your thoughts.)

I can usually find detailed API docs online OK, and often code samples. What can be hard is getting a high-level overview of what's available, learning scenarios that the different classes were designed for, and finding the details that would let you decide which to use.

For example, I can easily find the methods for shared_ptr, but what are the circumstances where I might want to use that? And when do I use auto_ptr vs. shared_ptr? Things that I know now after using both for awhile, but didn't know when I first started out.

Basically, what would be useful to me would be the advice of an experienced C++/Boost programmer on how to get the most out of boost.

As far as individual libraries, thorough documentation on asio would be very useful.

Hope this feedback is helpful!

-----Scott. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users -- Vlad P author of C++ ORM http://github.com/vladp/CppOrm/tree/master

-- http://www.fastmail.fm - mmm... Fastmail...

In any new edition of the boost book, I would like to see a strong emphasis on algorithms, containers, and utility functions. Stuff that *everyone* can make use of in a wide variety of projects. variant, boost, thread, filesystem, multi_array, any, accumulators, bind, function, circular_buffer, date_time, exception, foreach, random, enable_if, and probably a few others. This could in theory take up about half the book. For the next 25% I would like to see some discussion of libraries that are slightly less widely applicable, but still extremely useful and greatly simplifying when you need them. asio, flyweight, iostreams, signals, numeric conversion, etc. Note that use of asio implies neither asynchronous, nor i/o, despite the name. The documentation and examples of asio also applies almost exclusively to i/o related tasks on the network. It would be useful to extend this to other things, for example asynchronous file reading / writing, or asynchronous computation, or a generic pipeline. The last 25% I think could be dedicated to more specialized / advanced libraries. graph, math, MPL, fusion, spirit, etc. I'd also like to see a new edition of the book be about 50% longer than the first edition, and have a hardback edition available if possible.

Roland Bock wrote:

I agree with the above, except for the relative amounts of pages. I would rather think of a three volume collection. The reason is that the complex/specialized/advanced topics are, well, complex, specialized, advanced. And because they are, they always seem to be squeezed in last, not covered in enough detail.

For instance, currently I think I could make good use of MPL, but the tutorial looks rather abstract to me, and somehow I do not really get a grasp on it. I would love to see a more down-to-earth introduction (although maybe that is an oxymoron?).

Regards, I agree with this. MPL and other meta-programming related libraries (MPl, type_traits,fusion,proto) are not for the faint of heart when you have no idea what they are for.

-- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

On Thu, Aug 27, 2009 at 11:29 AM, dariomt wrote:

PS: when i try to propose using boost I always get: 'Hum... what's the overhead compared to doing it by hand?'

As ever the answer is to measure it. I have huge sympathy with this post tho', as it's an issue I often have to address too. Unfortunately, when I have done measurements it has generally shown that there is some performance penalty to be paid for use of bind/function combinations. OTOH, there is some performance penalty to paid for using C/C++ rather than assembler too, so where do you draw the line? The payback of course is clarity of expression, and cleaner representation of idioms and algorithms. I'd very much rather code a for_each algorithm than a for-loop, but that's because it seems to me to be better. Sometimes my colleagues don't share my perspective. I'd be interested if you find answers to any of these things. - Rob. -- ACCU - Professionalism in programming - http://www.accu.org