![]() In the words of the C++ standard, clause 6.8: Istream in code#What's going on here? Basically, we're running across one of the painful rules that C++ inherited from C, to maintain C compatibility: If a piece of code can be interpreted as a declaration, it will be. What it actually declares is (take a deep breath here):Īn istream_iterator with a formal parameter name of cin,Īnd a function with no formal parameter name Why not? Because it doesn't actually declare a deque object named coll3. The big problem, though, is that the code doesn't actually do anything at all. This has one potential problem, and one actual problem: The potential problem is that cin is exhausted, so there's no input left to read as was probably intended, which may be a logical problem. The above code looks at first blush like it's trying to do the same thing as Example 1(a), namely create a deque of strings populated from the standard input, except that it's trying to do it using the syntax of Example 2(a), namely using the iterator range constructor. Example 2(c): Declaring yet another deque? The reason will become clear as we take a look at the last part of the code, which is unfortunately much more benign than some might think: You might wonder why I've belabored this syntax. The original code simply did it all using the constructor that takes an iterator pair, which probably (though not necessarily) does exactly the same thing under the covers. The (minor) difference is that coll2's default constructor is called first and then the elements are pushed into the collection as a separate step, using push_back(). Example 2(b): Almost the same as Example 2(a) The code so far in Example 2(a) is nearly equivalent to: That happens to correspond to "everything that's in coll1." In this case, we're initializing coll2 from an iterator range This code declares a second deque of strings called coll2, and initializes it using the deque constructor that takes a pair of iterators corresponding to a range from which the contents should be copied. In Example 1(b), the istream_iterator objects are named variables, and survive the copy() statement they won't be destroyed until the end of whatever scope surrounds the above code. The only difference is that in Example 1(a) the istream_iterator objects are created on the fly as unnamed temporary objects, and so they are destroyed at the end of the copy() statement. It then copies every whitespace-delimited string in the standard input stream ( cin) into the deque using deque::push_back(), until there is no more input available.Ĭopy( first, last, back_inserter( coll1 ) ) This code declares a deque of strings called coll1 that is initially empty. What must be changed to make the code do what the programmer probably expected? Most people know the famous quote: "What if they gave a war and no one came?" This time, we consider the question: "What if we initialized an object and nothing happened?" As Scarlett might say in such a situation: "This isn't right, I do declare!"Īssume that the relevant standard headers are included and that the appropriate using-declarations are made. The book versions also incorporate corrections, new material, and conformance to the final ANSI/ISO C++ standard (1998) and its Technical Corrigendum (2003). The solutions in the book have been revised and expanded since their initial appearance in GotW. See the book Exceptional C++ Style (Addison-Wesley, 2004) for the most current solution to this GotW issue. This is the original GotW problem and solution substantially as posted to Usenet. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |