This chapter is from the book
This chapter is from the book
This chapter is from the book
Footnotes
-
Note that I'm kind of creating my own problem to solve in this specific case, because I tend to extend STL in this way. It is possible in many cases to follow the example of istream_iterator and encapsulate the start of the enumeration in the constructor of the nondefault iterator; Boost's file-system enumeration component works in this way. But this is a logical disconnect that troubles me too much to follow the lead—you may well see it differently.
-
This is the approach taken by John in his Boost-compatible implementation of RangeLib, although he relies more on the explicit qualification of the RangeLib algorithm namespace boost::rtl::rng::for_each.
-
Much hard-won experience with Java's import x.* also contributes to my loathing for the indiscriminate introduction of names into namespaces. Herb Sutter and I have an ongoing difference of opinion on this point. Fortunately for Herb, he is vastly more knowledgeable and erudite on C++ than I am. Fortunately, for me, this is my book and I can write what I like.
-
This applies to all templates, not just template algorithms and functors.
-
If those three tell you your code is wrong, the odds are good that you're doing something wrong.
-
There were a few weeks between starting this chapter and doing the final version. In that short time I forgot how this worked, and I wrote it!
-
You can fit more angels on the head of a pin than you can find software engineers who wouldn't argue over a blade of grass. Notwithstanding that, John and I are in a reasonable state of agreement. You can see the differences in our interpretation of the concept, and understand the different design principles and implementation mechanisms in our implementations, because John's expansive and impressive Boost-compatible implementation of the Range concept is included on the CD along with my own STLSoft version.
-
Except if we were to point it high into the top of memory and then iterate until it reached 0, but this would result in an access violation on many platforms, so the issue is moot.
-
This is a general implementation naming policy, which helps to avoid clashes that can occur when the "outer" function and the implementing "inner" functions have the same name, and there are multiple overloads of the "outer" function. Different compilers have different aptitudes for resolving such things, so the simplest solution is to avoid it, and name the implementing "inner" functions unambiguously.
-
Although you'll have noted that I managed to overcome my squeamishness in Chapter 25.