gotta be a better way than this?

hi,

this code prints out numbers like so.

1 2 (there should be a 25 space gap)
3 4
5 6 etc.

but i am not happy with my method of doing it . Could anyone show me a better alternative.

code.

#include <iostream>
#include <iomanip> // for use of set(x)
using namespace std;

int main ()

{

int count=1;
int num=0;

for(count = 1; count <= 20;count++)
{

num +=1;
cout << setw(3) << num ;
num +=1;
cout << setw(25) << num <<endl;
}
cout << endl;

return 0;

}

thanks

Code:

#include <iostream> 
#include <iomanip> // for use of set(x) 
using namespace std; 

int main () 

{ 
for (int count=1;count<41;count++)
{
if (count%2==1) cout<<setw(3)<<count;
if (count%2==0) cout<<setw(25)<<count<<endl;
}
return 0;
}

#include <iostream>
#include <iomanip> // for use of set(x)
using namespace std;

int main ()

{

int count=1;
int num=0;

for(count = 1; count <= 20;count++)
{

cout << setw(3) << (num += 1);
cout << setw(25) << (num += 1) <<endl; ;

}
cout << endl;

return 0;

}

dang

Code:

#include <iostream> 
#include <iomanip> // for use of setw(x) 
using std:: cout; 
using std::endl;

int main () 
{ 
   int count=1, num = 0; 

   for(count = 1; count <= 20;count++) 
   { 
      cout << setw(3) << ++num << setw(25) << ++num << endl; 
   } 

cout << endl; 

return 0; 
}

I originally tried it that way but the results are as follows:

2 1
4 3
6 5
8 7
10 9
12 11
14 13
16 15
18 17
20 19
22 21
24 23
26 25
28 27
30 29
32 31
34 33
36 35
38 37
40 39

Press any key to continue

At least that's what I get with Visual C++ 6.0 service pack 3.

I'm a little confused as to why that is and would love an explanation if someone has one.

Originally posted by Dang
I originally tried it that way but the results are as follows:



At least that's what I get with Visual C++ 6.0 service pack 3.

I'm a little confused as to why that is and would love an explanation if someone has one.

I see what you mean, same thing happened to me. I shortened the code to:

Code:

#include <iostream> 
#include <iomanip> // for use of setw(x) 
using std:: cout; 
using std::endl;
using std::setw;

int main () 
{ 
  for( int count = 0; count <= 20; ) 
  { 
     cout << setw(3) << count++ << setw(25) << count++ << endl; 
   } 

  cout << endl; 

  return 0; 
}

and that gives the results:
1 0
3 2
5 4
.
.
.
etc. I don't know why, I've tried initializing count to 1, to 0, using count++ and ++count. Did the same thing with my original code in the earlier post, same results. Dunno why. Did forget using std:setw; first time.

I am glad it also freaks you guys out. Dont you hate it when you think something should be just a simple little program and it turns out to be a bit of a headache. Still i suppose that is what programming is about and when one of the smarter guys gives a good explanation i think i will be quite enlightened (for a short while )

(response to last couple of messages.)

I'm a little confused as to why that is and would love an explanation if someone has one.

I suspect it's because the expression -

Code:

cout << setw(3) << ++num << setw(25) << ++num << endl;

is being evaluated from right to left.

This should give you the intended output using the above method -

Code:

 #include <iostream> 
#include <iomanip> // for use of setw(x) 

using std:: cout; 
using std::endl;
using std::setw;

int main () 
{ 
   int count=1, num = 0; 

   for(count = 1; count <= 20;count++) 
   { 
      cout << setw(3) << ++num; 
      cout << setw(25) << ++num << endl; 
   } 

cout << endl; 

return 0; 
}

Thanks Zen!

Zen is correct it is being evaluate from right to left. So if you really want to get that code to one line it can be done like this:

Code:

#include <iostream> 
#include <iomanip> // for use of setw(x) 

using std:: cout; 
using std::endl;
using std::setw;

int main () 
{ 
   int count=1, num2 = 0 , num1 = num2; 

   for(count = 1; count <= 20;count++) 
   { 
      cout << setw(3) << --num2  << setw(25) << ( num2 = num1 += 2 ) << endl; 
   } 

cout << endl; 

return 0; 
}

> cout << setw(3) << --num2 << setw(25) << ( num2 = num1 += 2 ) << endl;
Evaluation order has nothing to do with it - if you modify the same object twice in the same expression, the result is undefined - period.
http://www.eskimo.com/~scs/C-faq/q3.2.html

OK that was a bad example, but when chaining << operators on MSVC 6.0 the expression is evaluated from right to left, but is undefined and depends on the implementation (so not good practice) -

Code:

#include <iostream> 
#include <iomanip> // for use of setw(x) 
using std:: cout; 
using std::endl;
using std::setw;

int foo(int* i,char* a)
{
    cout << a;
    return (*i)++;
}

int main () 
{ 
   int count=1, num = 0; 
   
   for(count = 1; count <= 20;count++) 
   { 
      cout <<foo(&num,"first ") << "\t" <<foo(&num,"second ")<<endl; 
   } 

    cout << endl; 

    return 0; 
}

Originally posted by Salem
> cout << setw(3) << --num2 << setw(25) << ( num2 = num1 += 2 ) << endl;
Evaluation order has nothing to do with it - if you modify the same object twice in the same expression, the result is undefined - period.
http://www.eskimo.com/~scs/C-faq/q3.2.html

Ok. But my limited understanding of multiple <<'s is that it's a cascading operator, so that:

Code:

cout << ++num << ++num.....;

is really a series of function calls:

Code:

cout << ++num;
cout << ++num;
.....

At least that's what I get from studying overloaded operators (just starting that). Or is the problem with the ++ operators? Thanks.

But my limited understanding of multiple <<'s is that it's a cascading operator

Yes, if you were calling it like a normal function it would look something like this -

(cout.operator <<(++i)).operator <<(++i);

However, it is undefined as to what or which will be evaluated first. Check this link

Ok, I see from the link why the problem is occurring. The evaluation of the expression is undefined.
I guess the next question is why is expression evaluation in a case like this undefined? Wouldn't it have been better for Bjarne or whoever designs/updates/creates C++ to have the behavior defined? The undefined behavior is counter intuitive, and I don't see a reason behind it.