Comments on: The One True Iterator Declaration http://blog.froglogic.com/2007/04/the-one-true-iterator-declaration/ A company weblog Fri, 29 Aug 2008 08:04:18 +0000 http://wordpress.org/?v=2.5 By: synss http://blog.froglogic.com/2007/04/the-one-true-iterator-declaration/#comment-4930 synss Thu, 29 Nov 2007 14:38:11 +0000 http://blog.froglogic.com/2007/04/the-one-true-iterator-declaration/#comment-4930 The BOOST_FOREACH thing is precisely what I was looking for, though to shorten the line and increase genericity BOOST_FOREACH(my_map::value_type &data, my_map) { /* ... */ } is better. The BOOST_FOREACH thing is precisely what I was looking for, though to shorten the line and increase genericity

BOOST_FOREACH(my_map::value_type &data, my_map)
{
/* … */
}

is better.

]]> By: jbo5112 http://blog.froglogic.com/2007/04/the-one-true-iterator-declaration/#comment-1418 jbo5112 Wed, 15 Aug 2007 17:44:05 +0000 http://blog.froglogic.com/2007/04/the-one-true-iterator-declaration/#comment-1418 okay, trying to do this without getting mangled (need a preview or edit button)... using namespace std; typedef string map_key_type; typedef string map_value_type; map<map_key_type, map_value_type> my_map; BOOST_FOREACH( pair<const map_key_type, map_value_type> &data, my_map ) { // do your work on each pair here... } okay, trying to do this without getting mangled (need a preview or edit button)…

using namespace std;

typedef string map_key_type;
typedef string map_value_type;

map<map_key_type, map_value_type> my_map;

BOOST_FOREACH( pair<const map_key_type, map_value_type> &data, my_map )
{
// do your work on each pair here…
}

]]> By: jbo5112 http://blog.froglogic.com/2007/04/the-one-true-iterator-declaration/#comment-1417 jbo5112 Wed, 15 Aug 2007 17:38:12 +0000 http://blog.froglogic.com/2007/04/the-one-true-iterator-declaration/#comment-1417 Sorry to dig up an old discussion, but this method is too cool! Of course you can skip the typedefs and name them manually (I'm just doing it here so my example is generic enough, easy to follow, easy to change and actually works). I can't tell you the hours I've wasted trying to get something like this to work, and please note the first data type in the pair has to be const. using namespace std; typedef string map_key_type; typedef string map_value_type; map my_map; BOOST_FOREACH( pair &data, my_map ) { // do your work on each pair here... } Sorry to dig up an old discussion, but this method is too cool! Of course you can skip the typedefs and name them manually (I’m just doing it here so my example is generic enough, easy to follow, easy to change and actually works). I can’t tell you the hours I’ve wasted trying to get something like this to work, and please note the first data type in the pair has to be const.

using namespace std;

typedef string map_key_type;
typedef string map_value_type;

map my_map;

BOOST_FOREACH( pair &data, my_map )
{
// do your work on each pair here…
}

]]> By: Max Howell http://blog.froglogic.com/2007/04/the-one-true-iterator-declaration/#comment-357 Max Howell Tue, 01 May 2007 17:14:45 +0000 http://blog.froglogic.com/2007/04/the-one-true-iterator-declaration/#comment-357 I tend to just go for all in one lines nowadays, since screens got bigger it's acceptable IMO. But then again I hate huge variable declarations as they clutter the code and make parsing the code less quick by eye. Hence I never use the STL if I'm writing a Qt app :) In the above example I'd prolly use the two liner. But I find most people, including myself miss double definitions of variables in this form. Not the end of the world, but it can be frustrating when trying to locate a variable's type. And KDevelop still doesn't help with a tooltip there. I tend to just go for all in one lines nowadays, since screens got bigger it’s acceptable IMO.

But then again I hate huge variable declarations as they clutter the code and make parsing the code less quick by eye. Hence I never use the STL if I’m writing a Qt app :)

In the above example I’d prolly use the two liner. But I find most people, including myself miss double definitions of variables in this form. Not the end of the world, but it can be frustrating when trying to locate a variable’s type. And KDevelop still doesn’t help with a tooltip there.

]]> By: Jason Voegele http://blog.froglogic.com/2007/04/the-one-true-iterator-declaration/#comment-264 Jason Voegele Mon, 23 Apr 2007 19:19:41 +0000 http://blog.froglogic.com/2007/04/the-one-true-iterator-declaration/#comment-264 You must be very careful with style #3. If the loop body modifies the container it is possible that the iterator held in the end variable will have been invalidated and your program will likely crash. It is best not to use this style unless it is guaranteed that the loop body will not invalidate the iterator, and profiling indicates that it is worth performing this optimization (it probably is not in most circumstances). For this reason (among others) I prefer style #1, or using a standard algorithm if possible. You must be very careful with style #3. If the loop body modifies the container it is possible that the iterator held in the end variable will have been invalidated and your program will likely crash. It is best not to use this style unless it is guaranteed that the loop body will not invalidate the iterator, and profiling indicates that it is worth performing this optimization (it probably is not in most circumstances).

For this reason (among others) I prefer style #1, or using a standard algorithm if possible.

]]> By: Victor T. http://blog.froglogic.com/2007/04/the-one-true-iterator-declaration/#comment-261 Victor T. Mon, 23 Apr 2007 16:50:45 +0000 http://blog.froglogic.com/2007/04/the-one-true-iterator-declaration/#comment-261 In all proposals till now I'm missing the fact that "end" could be declared constant: const map::const_iterator end = map.end(); I tend to agree with Scott Meyers that everything that might be declared constant also should be declared constant. It might even help some (not-too-bright) compilers to generate better code. And obviously it also catches possible coding errors, as for instance a (wrong) assignment to "end" later on in the source code. In all proposals till now I’m missing the fact that “end” could be declared constant:

const map::const_iterator end = map.end();

I tend to agree with Scott Meyers that everything that might be declared constant also should be declared constant. It might even help some (not-too-bright) compilers to generate better code. And obviously it also catches possible coding errors, as for instance a (wrong) assignment to “end” later on in the source code.

]]> By: ryan http://blog.froglogic.com/2007/04/the-one-true-iterator-declaration/#comment-247 ryan Sat, 21 Apr 2007 22:13:45 +0000 http://blog.froglogic.com/2007/04/the-one-true-iterator-declaration/#comment-247 I prefer to put things in a transform, for_each, or something like that. THe ugly is that the function has to be declared outside. C++ could really use 1) lambda expressions and 2) inline function declarations. Functional programming techniques rule. And no, boost::lambda and FC++ do not suffice. I prefer to put things in a transform, for_each, or something like that. THe ugly is that the function has to be declared outside. C++ could really use 1) lambda expressions and 2) inline function declarations. Functional programming techniques rule. And no, boost::lambda and FC++ do not suffice.

]]> By: Anonymous http://blog.froglogic.com/2007/04/the-one-true-iterator-declaration/#comment-240 Anonymous Sat, 21 Apr 2007 09:40:03 +0000 http://blog.froglogic.com/2007/04/the-one-true-iterator-declaration/#comment-240 BOOST_FOREACH( std::map::value_type i, myMap ) { } BOOST_FOREACH( std::map::value_type i, myMap ) {

}

]]> By: Herbert Graeber http://blog.froglogic.com/2007/04/the-one-true-iterator-declaration/#comment-237 Herbert Graeber Fri, 20 Apr 2007 22:34:04 +0000 http://blog.froglogic.com/2007/04/the-one-true-iterator-declaration/#comment-237 Who says ther are no line breaks allowed inside the head of the for? So, what about for ( map::const_iterator it = map.begin(); it != map.end(); ++it ) { ... } Who says ther are no line breaks allowed inside the head of the for?
So, what about

for (
map::const_iterator it = map.begin();
it != map.end(); ++it
) {
…
}

]]> By: Esben Mose Hansen http://blog.froglogic.com/2007/04/the-one-true-iterator-declaration/#comment-235 Esben Mose Hansen Fri, 20 Apr 2007 20:50:49 +0000 http://blog.froglogic.com/2007/04/the-one-true-iterator-declaration/#comment-235 for_each, tranform, accumulate and copy + boost::lambda handles a lot of the common cases (and would probably handle more for me if I could wrap my head around them) I do sort of like the style that declares the end part in the first part of the for look. Never thought about that. Am I the only one who suspects that I have a harder time with the captchas than a good OCR program would? ;) for_each, tranform, accumulate and copy + boost::lambda handles a lot of the common cases (and would probably handle more for me if I could wrap my head around them)

I do sort of like the style that declares the end part in the first part of the for look. Never thought about that.

Am I the only one who suspects that I have a harder time with the captchas than a good OCR program would? ;)

]]>