Reputation: 3003
I have a series of three loops that each cout a row of \t
delimited values
#include <iostream>
#include <vector>
#include <cstdlib>
using namespace std;
struct the_struct {
float a_float;
the_struct() :a_float(0){}
};
class the_class {public: the_struct a_struct;};
int main ()
{
vector <the_class> v_objects;
for(int q=0; q < 30; q++)
v_objects.push_back(the_class());
srand(0);
int* int_dynamic_array = new int [30];
for(int q=0; q < 30; q++)
int_dynamic_array[q] = rand() % 30;
for(int q=0; q < 30; q++)
cout << q << "\t";
cout << "\n";
for(int q=0; q < 30; q++)
cout << v_objects[q].a_struct.a_float << "\t"; //at runtime, these are all zeros
cout << "\n";
for(int q=0; q < 30; q++)
cout << int_dynamic_array[q] << "\t"; //random values between 0 and 29
cout << "\n";
}
For some reason, this code only prints exactly 11 values from the 2nd loop, and randomly omits between 0 and 4 values from the third loop. The first loop never has problems. For example (without tabs):
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
0 0 0 0 0 0 0 0 0 0 0
4 7 2 9 7 4 3 1 6 5 26 12 8 28 13 11 22 7 19 2 26 13 9 12 15 24 8
Strangely, if I modify the tab string from "\t"
to "x\t"
, the program now outputs every value, but obviously with an x after each. For example:
0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x
Upvotes: 0
Views: 10149
Reputation: 279285
As discussed in comments under the question, this seems to be a bug/quirk in the Mac terminal (I'm thinking bug, but I don't know if the Posix spec says something weird about the allowable interaction between tabs and the right-hand-side of the terminal).
If the 11th value is single-digit (which 0 is), then at least on my terminal the tab stops are set such that you're outputting a tab when the terminal is exactly on the line-end. If the 11th value is two digits[*], then it breaks across the line, so the tab character isn't at line-end. Obviously this shouldn't be a problem, I just have a hunch that it might be.
I don't see the same result on my terminal (which isn't Mac, it's actually puttycyg on Windows) - for me outputting that tab moves the cursor to the next line, as you'd expect.
[*] Which 10 is, so is 0x, and so is 26, the 11th value you get out of rand() % 30
on your machine having seeded with srand(0)
Upvotes: 4
Reputation: 38176
the outputs are there, this is the problem with the command line output screen, if you just do
$ ./a.out > op.txt
and open the output file, you will see the output is very much there.
Also if you change the tab spacing to the new line
"\t" to "\n", then also you can see the output on screen.
But i agree there is some problem with the command line output screen when using the tab delimiter
EDIT:
The problem is with the size of the console window.
for size 62*40, number of zeros = 9
for size 90*40, number of zeros = 13
for size 120*40, number of zeros = 16
for size 150*40, number of zeros = 20
and using both my monitors, i get all of them...
for size 260*40, number of zeros = 30
Upvotes: 1
Reputation: 29021
Maybe you forgot the std::endl
or std::flush
at the end of the output. Simply outputing `\n'
is not enough to flush the output, so you'll end with a short output.
The case when adding the x
will work may be caused by the internal buffer to be full (and then output) because the x
increase the size of the output to a limit that causes the output of the current buffer (not happening when the buffer is shorter without the x
.)
EDIT:
As the author of the question says it does not work with flushing, then, the only thing that comes to my mind is that some of those fields are characters or strings thay may be empty, or have been unadvertedly filled with spaces. (This is why it is important that you show the definition of those types).
Upvotes: 0
Reputation: 1104
Although the problem seems to be about output, there may be another case which should be considered.
Here at v_objects[q], if v_objects is an instance of a class which overloaded [] operator that takes a reference to int, the value of q may be incremented/changed there which will cause for loop to be exited earlier than you expected.
for example:
some_type operator[] ( int &a )
{
// a can be incremented here
a++;
}
As you did not give the full source, we can not find the cause exactly.
Upvotes: 1