Problem Ex8_09 bug??

GeorgeSnead · January 31st, 2009, 11:00 PM

Hello;

The downloaded version of problem, Ex8_09, does not deliver the correct output! So, you might suspect that the downloaded version differs from the textbook version and that difference accounts for the flaw. No! I've compared manually the downloaded source to that in the book and they are the same (human reliability: 80% :-).

I will show the statement which I suspect caused the failure and a correction I made which give the correct output. Then I have a question about precedence of operators which, I assert, accounts for the original flaw.

I wrap up my observations and questions below in the section marked, "Questions:".

Here is the flawed output that I got from the downloaded source. Note the flaw: that the array of names does not pair up properly with the ages of the people.
--------------------
Enter a first name or press Enter to end: Tom
Enter a second name: One
Enter Tom's age: 1

Enter a first name or press Enter to end: Bob
Enter a second name: Two
Enter Bob's age: 2

Enter a first name or press Enter to end: John
Enter a second name: Three
Enter John's age: 3

Enter a first name or press Enter to end:

The names you entered are:
Bob Two aged 1.

John Three aged 2.
aged 3.
Done!!
-------------------------

Here is the original logic which introduces the flaw in the function, listnames.

while(i<count && !names[i].empty())
cout << names[i] + " aged " + ages[i++] + '.' << endl;

Here is a modification which yields the desired result of pairing up persons with their age. Note that I simply ensure that the autoincrement of i happens after referencing the arrays with i :

while(i<count && !names[i].empty())
{
cout << names[i] + " aged " + ages[i] + '.' << endl;
i++;
}

Here is the output that my modification generates which is the desired output:
-------------------
Enter a first name or press Enter to end: Tom
Enter a second name: One
Enter Tom's age: 1

Enter a first name or press Enter to end: Bob
Enter a second name: Two
Enter Bob's age: 2

Enter a first name or press Enter to end: John
Enter a second name: Three
Enter John's age: 3

Enter a first name or press Enter to end:

The names you entered are:
Tom One aged 1.
Bob Two aged 2.
John Three aged 3.
Done!!
-------------------

Here's the loop which outputs the flawed results:

while(i<count && !names[i].empty())
cout << names[i] + " aged " + ages[

i++

] + '.' << endl;

I speculate that, in the downloaded source, the expression is evaluated in the order from right to left whereas the textbook version is performed left to right:

The flawed outcome I experienced would occur if the order of operation was as follows:
names[i] + (" aged " + ( ages[i++] + '.' ) ) //out give the flawed output I
//see.

And yet, the textbook presents output which asserts that the order of evaluation would be :
( ( (names[i]) + " aged " ) + ages[i++] + '.' ) //would give the desired
// output, but I don't get this.

Questions:
Does anyone dispute my interpretation that the actual behavior of the original program is to perform the several operations "+" in order from right to left, which caused flawed results? Try it yourself and see!

Author Horton displays correct output in the book from this same original program which give me flawed output. This asserts to me that his compiler interpreted his expression from left to right; while my program from the same source code evaluates from right to left and, consequently, outputs incorrect results?? This is entirely unreasonable, but seems to be happening anyway!

Is the order of operation for not determined? (Can the compiler can do the evaluation of the series of +'s in any order it wishes? in indeterminate order? Naw! Something is going on here! Could it have to do with overloading the + operator for strings????)

A further development:

The discussion of this program appears on p.475 of the book and suggests that the line in question can be replaced with this one:
cout << ((names[i].operator+(" aged ")).operator+(ages[i++])).operator+('.') << endl;

This replacement line will not compile for me and gives errors C2039 and c2228 and this message (What is this error and message trying to tell me?):

c:\beginning visual c plus plus examples\225905 code download\code from the book\ch8\ex8_09a\ex8_09a.cpp(21) : error C2039: '+' : is not a member of 'std::basic_string<_Elem,_Traits,_Ax>'
with
[
_Elem=char,
_Traits=std::char_traits<char>,
_Ax=std::allocator<char>
]
c:\beginning visual c plus plus examples\225905 code download\code from the book\ch8\ex8_09a\ex8_09a.cpp(21) : error C2228: left of '.+' must have class/struct/union
c:\beginning visual c plus plus examples\225905 code download\code from the book\ch8\ex8_09a\ex8_09a.cpp(21) : error C2228: left of '.+' must have class/struct/union

By the way, I'm using Microsoft Visual C++ 2008 Express Edition which seems to be part of this build:
Microsoft Visual Studio 2008
Version 9.0.30729.1 SP

I chose to disable pre-compiled headers and "#include "stdafx.h" does not appear in the Ex8_09.cpp source.

My headers are these in the source :

// Ex8_09.cpp
// Creating and joining string objects
#include <iostream>
#include <string>
using std::cin;
using std::cout;
using std::endl;
using std::string;
using std::getline;

// List names and ages
void listnames(string names[], string ages[], size_t count)
{
size_t i = 0;
cout << endl << "The names you entered are: " << endl;
while(i<count && !names[i].empty())
cout << ((names[i].operator+(" aged ")).operator+(ages[i++])).operator+('.') << endl;
}

...

jabney · February 1st, 2009, 04:07 AM

Hi George,

The Ex8_09 code issue is listed and corrected in the errata: http://www.wrox.com/WileyCDA/WroxTit...Cd-ERRATA.html. The solution given there is the same as the one you provided.

I just did a test and the evaluation order is indeed left to right, so I suspect that the evaluation of the '<<' operators for cout is idiosyncratic with regards to post incrementation.

Even if evaluation order is enforced, the result is the same: cout << (((names[i] + " aged ") + ages[i++]) + '.') << endl;

I can only guess that cout and its operators are somehow to blame.

Here's my test code:

Code:

#include <iostream>
using namespace std;

class eval;

ostream& operator<<( ostream& lhs, const eval& rhs )
{
    return lhs;
}

class eval
{
public:
    eval(){}

    const eval operator+( const char* rhs ) const 
    {
        cout << "Eval() char*" << endl;
        return eval();
    }

    const eval operator+( const char rhs ) const 
    {
        cout << "Eval() char" << endl;
        return eval();
    }

    const eval operator+( const eval& rhs ) const
    {
        cout << "Eval() eval" << endl;
        return eval();
    }
};

int main(void)
{
    eval e1, e2;

    cout << e1 + " char string " + e2 + 'c' << endl;
    return 0;
}

The following output results:
Eval() char*
Eval() eval
Eval() char

Old Pedant · February 1st, 2009, 04:48 AM

But your test case *seems* to indicate that the evaluation order is indeed left to right!

I'd be more interested to see a test case that more clearly demonstrates what is going on with the post-increment!! It certainly flies in the face of logic.

jabney · February 1st, 2009, 05:13 AM

It does... ;-)

Well here's another clue, I think.

The operators are defined externally to the string class, so this type of call DOESN'T work:

Code:

cout << names[i].operator+(" aged ").operator+(ages[i++]).operator+('.') << endl;

In the above case, the operators would be evaluated from left to right, and the incrementation would occur last. However, the string class's operator+ function is defined externally to the class, so it's actually called this way:

Code:

cout << operator+( operator+( operator+( names[i], " aged " ), ages[i++] ), '.' ) << endl;

In this case, the evaluation needs to take place right to left, with the results of the innermost function call given as a parameter of the next, and so on. Here the increment happens FIRST, and this is exactly what's being observed by George. It looks like a bug (or some sort of undefined behavior) but it isn't.

So the order of evaluation will depend on the definitions of the operators, whether they are straight function calls (right to left) or member function calls (left to right).

Unless I'm mistaken, the moral of the story is: don't increment in a cout statement unless you're sure how the operators are defined, and even then try to avoid it.

jabney · February 1st, 2009, 05:20 AM

OK scratch that, I'm back to confusion... :?

EDIT: my best guess is that ages[i++] gets pushed onto the stack last and evaluated before names[i]. I'm no assembly expert, but it's either that or a bug. The apparent ambiguity of the chained operator+() calls makes clear that these situations should be avoided!!!! =D

EDIT2: the order of evaluation for the above cases is left to right, in both cases, regardless of how the operators are defined.

GeorgeSnead · February 3rd, 2009, 12:06 AM

Thank you jabney for your code which clarifies the evaluation order.

GeorgeSnead · February 3rd, 2009, 12:20 AM

Quote:

Originally Posted by jabney

It does... ;-)

So the order of evaluation will depend on the definitions of the operators, whether they are straight function calls (right to left) or member function calls (left to right).

Thank you jabney for this very helpful insight!

jabney · February 3rd, 2009, 12:30 AM

Quote:

Originally Posted by jabney

So the order of evaluation will depend on the definitions of the operators, whether they are straight function calls (right to left) or member function calls (left to right).

Hi George,

This isn't actually the case. A closer look at that code shows that my initial impression was mistaken. In both cases, the evaluation occurs left to right.

The strange behavior of the incrementor stands, and seems inexplicable. It looks like a bug. I may report it and see what Microsoft says.

jabney · February 4th, 2009, 01:48 AM

This issue is considered "by design" according to Microsoft. This is because the C++ standard does not insist on an order of evaluation, thus it's left to the discretion of the vendor (in this case, Microsoft).

For those interested, the bug and the resolution can be viewed here (you'll need to use IE): https://connect.microsoft.com/Visual...dbackID=410377

Old Pedant · February 4th, 2009, 04:17 AM

Thanks much for going to the trouble to track this down. Maybe we can all sleep nights, now. <grin/>