pass a vector to a void function?

[John Brawley]

Hello once more....
I'm trying to learn vectors, by recoding my working program that uses
array[]s.
In order to know if it's doing what it's supposed to, I have to write a file
from the values in the vector, to feed to a separate graphic display
program.
I don't get it: nothing appears in the file.
I *know* for sure the array[] is proper, and full: I can see its values
using cout<<.
I've tried everything I could find on the web; my code should be right; the
vector itself works right, but I can't get the filewriter to write anything
into the file it creates....

//Outside of main() I make the vector:

using namespace std;
vector<double> pdbv;
long int pNum;
int endless=1;

//Here's the filewriter function:

void it8vout(const vector<double> &pdbv) {
ofstream it8vfil;
it8vfil.open ("it8vrawc.3d");
if (it8vfil.is_open()) {
for (long int k=0; k<(pNum*5); k+=5) {
double a=pdbv[0+k];
double b=pdbv[1+k];
double c=pdbv[2+k];
it8vfil<<a<<" "<<b<<" "<<c<<"\n"; }
}
it8vfil.close();
}

I'm calling it like this:

main() {
while (endless==1) {
//assume sane things happen (eternal loop)
if (kbhit()) { ch=getch(); switch(ch) {
case 's': it8vout(pdbv); cout<<"wrote snapshot files\n";break;
// (I hit 's' to call the filewriter........)
case ' ': cout<<pHi<<" "<<gRad<<" "<<x1<<" "<<y1<<" "<<z1<<"\n";break;
case 'q': goto Donedone;
default: cout << "Not a valid key.\n";
} } }

Donedone:
//......and again for a final write:
it8vout(pdbv);
return 0;
}

The program compiles, runs, I can see the values changing in the vector as
they're supposed to, but the filewriter just creates an empty file....
What'm I doing wrong?
Thanks

 

[John Brawley]

correction:

Hello once more....
I'm trying to learn vectors, by recoding my working program that uses
array[]s.
In order to know if it's doing what it's supposed to, I have to write a file
from the values in the vector, to feed to a separate graphic display
program.
I don't get it: nothing appears in the file.
I *know* for sure the ****array[]**** is proper, and full: I can see its

values

****I know for sure the _vector_ is proper....****
(sorry)

using cout<<.
I've tried everything I could find on the web; my code should be right; the
vector itself works right, but I can't get the filewriter to write anything
into the file it creates....

//Outside of main() I make the vector:

using namespace std;
vector<double> pdbv;
long int pNum;
int endless=1;

//Here's the filewriter function:

void it8vout(const vector<double> &pdbv) {
ofstream it8vfil;
it8vfil.open ("it8vrawc.3d");
if (it8vfil.is_open()) {
for (long int k=0; k<(pNum*5); k+=5) {
double a=pdbv[0+k];
double b=pdbv[1+k];
double c=pdbv[2+k];
it8vfil<<a<<" "<<b<<" "<<c<<"\n"; }
}
it8vfil.close();
}

I'm calling it like this:

main() {
while (endless==1) {
//assume sane things happen (eternal loop)
if (kbhit()) { ch=getch(); switch(ch) {
case 's': it8vout(pdbv); cout<<"wrote snapshot files\n";break;
// (I hit 's' to call the filewriter........)
case ' ': cout<<pHi<<" "<<gRad<<" "<<x1<<" "<<y1<<" "<<z1<<"\n";break;
case 'q': goto Donedone;
default: cout << "Not a valid key.\n";
} } }

Donedone:
//......and again for a final write:
it8vout(pdbv);
return 0;
}

The program compiles, runs, I can see the values changing in the vector as
they're supposed to, but the filewriter just creates an empty file....
What'm I doing wrong?
Thanks


--
Peace
JB
(e-mail address removed)
Web: http://tetrahedraverse.com

 

[Default User]

John Brawley wrote:

I've tried everything I could find on the web; my code should be
right; the vector itself works right, but I can't get the filewriter
to write anything into the file it creates....

[code snipered]

The program compiles, runs, I can see the values changing in the
vector as they're supposed to, but the filewriter just creates an
empty file.... What'm I doing wrong?

Please most COMPLETE minimal code that demonstrates the problem. As
shown, you have no headers included, and most of your variables are
undeclared.

I also don't see anywhere in the code where pdbv has any values added
to it.

Get rid of the platform-specific stuff like kbhit() until you have a
working portable version.

Don't use goto. You are not experienced enough for that. When you are
experienced enough, you won't want to.



Brian

 

[John Brawley]

I've tried everything I could find on the web; my code should be
right; the vector itself works right, but I can't get the filewriter
to write anything into the file it creates....

[code snipered]

The program compiles, runs, I can see the values changing in the
vector as they're supposed to, but the filewriter just creates an
empty file.... What'm I doing wrong?

Please most COMPLETE minimal code that demonstrates the problem. As
shown, you have no headers included, and most of your variables are
undeclared.

Problem:
I posted what wasn't working... The filewriter function was complete enough,
the problem stated. HOWever:
I shortened everything to minimum, and this works:

#include <vector>
#include <fstream>
#include <ostream>
#include <cstdlib>
using namespace std;

vector<double> vec;

void writfil(const vector<double> &vec) {
ofstream it8vfil;
it8vfil.open ("it8test.3d");
if (it8vfil.is_open()) {
for (int k=0;k<33;k++) {
double a=vec[0+k];
double b=vec[1+k];
double c=vec[2+k];
it8vfil << a << " " << b << " " << c << "\n"; }
}
it8vfil.close();
}

main() {
for (int i=0;i<33;i++) {
double val=rand()%1000*0.001;
vec.push_back(val);
}
writfil(vec);

return 0;
}

Get rid of the platform-specific stuff like kbhit() until you have a
working portable version.

I have one, using array[]s where I'm trying to use vectors.

Don't use goto. You are not experienced enough for that. When you are
experienced enough, you won't want to.
Brian

There's no choice, really.
Search archives on my name, find out why....
(There's only one goto, which jumps out of the switch() statement and
terminates the program. Since it's never supposed to stop running until the
user demands so, the goto makes sense here (and perhaps *only* here, since
otherwise you are quite right).

NOW I have the problem that the densified example above works perfectly: the
file has content, but the main program's _apparently_identical_ filewriter
and function call, those relevant pieces extracted and put into my first
message, doesn't.

Posting the entire program would be both badndwidth, and embarassing...
If no one can figure out what was wrong with the code in my first (well,
second...) message, when it's identical in structure, function and purpose
to this *working* piece, well, I don't know where else to turn....

Thanks.

 

[Default User]

NOW I have the problem that the densified example above works
perfectly: the file has content, but the main program's
_apparently_identical_ filewriter and function call, those relevant
pieces extracted and put into my first message, doesn't.

Well, it should give you a starting point.

Posting the entire program would be both badndwidth, and
embarassing... If no one can figure out what was wrong with the code
in my first (well, second...) message, when it's identical in
structure, function and purpose to this working piece, well, I don't
know where else to turn....

There's not much we can do. If the only complete code you can post
works, and the code the doesn't work you can't post . . . you see the
problem.

I'd try to cut down the other program by pieces until it works (or add
parts to the one that does until it breaks.



Brian

 

[John Brawley]

"Default User"

Well, it should give you a starting point.

It did. The problem has got to be inside the function.
At bottom, I post two snippets:
2) an altered version of the *working* one, and
1) a heavily experimented-upon cut-and-paste of the one that doesn't.
You'll notice that the vector is getting into the function, and is usable
there, just not in the way I have to use it...

I'd try to cut down the other program by pieces until it works (or add
parts to the one that does until it breaks.

It makes no sense to me, since the function is essentially independent of
the program (it's a void filewriter only, whose array[] version works fine),
so it should not care about what it gets so long as it gets what it needs
from the function call, and it *is* getting everything it needs:

The nonworking function, notated:
(All else is the same as the working version, same headers, same sort of
call from within main(), etc.)

void it8vout(const vector<double> &pdbv){
ofstream it8vfil;
it8vfil.open ("it8vrawc.3d");
if (it8vfil.is_open()) {
for (long int k=0; k<pNum*5; k+=5) {
double a=pdbv[0+k];
double b=pdbv[1+k];
double c=pdbv[2+k];
cout<<"notice me!"<<c<<"\n"; //Nothing
it8vfil<<a<<" "<<b<<" "<<c<<"\n"; //Nothing
}
cout<<"dis "<<a<<" is "<<b<<" nuts "<<c<<"\n"; //Outputs correct numbers
it8vfil<<"disis"<<pdbv[2]<<"nutsalso\n"; //Outputs to file
//if the above closing brace is here }, Nothing from all four.
}
it8vfil.close();
}

So, how can it be that the function reads the right numbers from vector
pdbv, as is seen by the fact that they can be output from outside of the
critical brace, but inside it where it needs to do tjose things, it doesn't
do them? I'm frazzled by this; it *ought* to work, and what's worse, the
stripped-down model of exactly the same thing, *does* work.

The working version, modified:

#include <vector>
#include <fstream>
#include <ostream>
#include <cstdlib>
#include <iomanip>

using namespace std;

vector<double> vec;
int pNum=5;
void writfil(const vector<double> &vec) {
ofstream it8vfil;
it8vfil.open ("it8test.3d");
if (it8vfil.is_open()) {
for (long int k=0;k<pNum*5;k+=5) {
double a=vec[0+k];
double b=vec[1+k];
double c=vec[2+k];
it8vfil << a << " " << b << " " << c << "\n"; // Works
cout<<a<<" "<<b<<" "<<c<<"\n"; } //check same ##s? =Yes.
}
it8vfil.close();
}

main() {
for (int i=0;i<pNum*5;i++) {
double val=rand()%10000*0.000314159;
vec.push_back(val);
cout<<val<<" ";//check same ##s? Yes.
}
cout<<"\n\n";

writfil(vec);

return 0;
}


.......I can't fathom this.
It cannot be that there's something utterly unrelated --and *unconnected*--
to either the function or its call, that can cause this to screw up inside
the function *right between* correct extraction of numbers from the vector,
and an immediate write-to-file....
....Can it? How?

 

[happyasaclam111]

Don't use goto.

"One of the few sensible uses of goto in ordinary code is to break out
from a nested loop or switch-statement." -Bjarne Stroustrup [TC++PL
3rd 6.3.4]

My money is on pNum either being uninitiliazed or so large that pNum*5
causes an overflow resulting in a negative value. If that is the case
you can easily change the for-condition to "k/5 < pNum" (and probably
should anyway). Of course, this wouldn't make sense if the program
worked before with plain arrays. In fact, I can't imagine how using
vectors could cause this problem if you know for sure that the vector
is populated (and being passed properly). Maybe I just need a better
imagination.

Also, try having your file-writer print to standard output just to
take file writing out of the equation. Comment out all the lines that
have to do with file access. If nothing prints out then you know that
the problem is in accessing the vector. If it prints correctly then
it is a problem with file access.

Use a debugger. Is it entering the if-clause? Is it entering the for-
loop? The answers to these questions should tell you a lot about the
problem.

 

[John Brawley]

<[email protected]>

Don't use goto.

"One of the few sensible uses of goto in ordinary code is to break out
from a nested loop or switch-statement." -Bjarne Stroustrup [TC++PL
3rd 6.3.4]
My money is on pNum either being uninitiliazed or so large that pNum*5
causes an overflow resulting in a negative value. If that is the case
you can easily change the for-condition to "k/5 < pNum" (and probably
should anyway). Of course, this wouldn't make sense if the program
worked before with plain arrays. In fact, I can't imagine how using
vectors could cause this problem if you know for sure that the vector
is populated (and being passed properly). Maybe I just need a better
imagination.
_I_ need one.
--pNum is initialized, and given a new value early in main().
--pNum*5 is necessary because each "record" I'm making is five entries long,
an X, a Y, a Z, a radius and a color (all doubles), so the program has to
read three (for use in distance calculations). The next two (4 and 5) can
be ignored, but the next XYZ read has to occur 5 entries down the line (and
so on . . .). Iteration skips by 5s.
--pNum in the array[] version can be as large as machine memory allows. I
used the array[] version last week to 'pack' 100,000 points, hence pNum*5
was half a megabyte of memory (no overflow).
Now, this next is interesting:
Also, try having your file-writer print to standard output just to
take file writing out of the equation. Comment out all the lines that
have to do with file access. If nothing prints out then you know that
the problem is in accessing the vector. If it prints correctly then
it is a problem with file access.
It prints correctly (!!)
I didn't think to comment-out the file accesses, since a) I've never had a
problem working with files and b) the "pure model" program (see my prior
message) uses exactly the same layout, and it *does* work right --prints to
cout<< *and* to the file. Same syntax, same everything. (Both filewriters
are in that message. Compare 'em: it totally doesn't make sense, and NOW
this doesn't make sense either: What could possibly screw up file access
when the *same*sort* of file access works fine in the other snippet???
Use a debugger. Is it entering the if-clause? Is it entering the for-
loop? The answers to these questions should tell you a lot about the
problem.
It has to be entering both, if the values get extracted from the vector. I
couldn't print them anywhere --file *or* cout<<, if they were not.
Now I have to ask/figure out what's wrong with file access in the one case,
but not in the other, when the methods and syntax are the same....
(But thanks for the hint. It at least pointed me in a different
direction....)

 

[John Brawley]

<happyasaclam111

Don't use goto.

from a nested loop or switch-statement." -Bjarne Stroustrup [TC++PL
3rd 6.3.4]
causes an overflow resulting in a negative value. If that is the case

<snip>
(See my just-earlier for context)
You also said:Also, try having your file-writer print to standard output just to
take file writing out of the equation. Comment out all the lines that
have to do with file access. If nothing prints out then you know that
the problem is in accessing the vector. If it prints correctly then
it is a problem with file access.
Since your suggestion panned out, and at a loss to know what could possibly
screw up file access, and *sheerly* guessing, I took the numeral out of all
the places it was in:

ofstream it8vfil; became ofstream itvfil;,
it8vfil.open became itvfil.open; it8vfil<<
and the function name itvout( ) instead of it8vout( ),
(etc....only nine places) ,

.........and the problem went away.

I only took the 8s out, that's _all_. I did nothing else.
That's weird enough, since I ought to be able to use a numeral in any name
or label so long as it is not the first character in the name or label, but
it's weirder than that:
I put all the 8s *back where they were*, and it still worked right.
I even checked my backup copy, thinking I could have messed up the order of
the characters in one of the label, but *no*: every label was the same.

So, good sir, I now have a working filewriter (which was the important
thing), but now I also have to go through life believing that computers and
programming *don't* always do the exact-precise-nonmysterious-hardcore
thing. Sometimes they do things that are, to a sane person, flatly
impossible.
I have a new Myth; the effect of .......
"Crazy 8s"

(I'm really not kidding. That's all it took, and now it's working, with
everything *exactly* the same as it was when it was *not* working.

Thanks for the hint, but I suspect you'll also have to credit the Great
Mystery with something as well.
This was _nuts_.
It's still nuts.
I'll not sleep soundly this night....

 

[happyasaclam111]

I'll not sleep soundly this night...
Don't worry about it. Stuff like that happens to me all the time.
Perhaps you moved something? Changed a file permission? Forgot to save
before a compile? Removed a file lock? Rebooted? Closed another copy
of your program that was running in the background? Some other
program accessing the file? The possibilities are truly endless. I
can assure you that it was not the *direct* result of removing the 8s
from the variable names. When something like that happens, I know
it's time to get some sleep.

Actually, if the OS was denying your program access to the file, then
it might have been some program (a text editor?) that you were using
to verify the output. I know I've run into weird stuff like that on
Windows. Then, if you changed the file name (to remove the 8) it
would have written just fine. You would then have redirected your
text editor, model viewer or whatever to the new file, thus allowing
you to write to the old file. In other words, your program could have
been working the whole time.

Or maybe not. But hey! It could happen...

 

[Krice]

for (int k=0;k<33;k++) {
double a=vec[0+k];
double b=vec[1+k];
double c=vec[2+k];

Doesn't this like cause a buffer overrun or what?

 

[John Brawley]

"Krice"

for (int k=0;k<33;k++) {
double a=vec[0+k];
double b=vec[1+k];
double c=vec[2+k];

Doesn't this like cause a buffer overrun or what?

That looks like part of the test program I wrote, that worked.
But aside from that, no, it doesn't, if I've hardcoded the number of entries
into the vector at 3*11 (hence 33 items to read), which I think I did to
test the problem I was having.

In my older, working program using array[]s, the for loop is
for (long int i; i < (pNum*5); i++) { //do stuff

....with the user at runtime deciding what "pNum" is (at least 2, up to
machine installed memory, which might allow millions)
So that allocated memory (with new *) is divided by fives, since each record
needs five locations (x,y,z,radius,color), all doubles.

The read iterator is for-looped by grouped fives also (above you see three),
so the read starts at zero and goes to *exactly* the end of the assigned
memory block and I don't get buffer overruns or out-of-range errors unless
I'm messing with it and do something stupid. (Which is too often for me to
have much fun with programming...(*grin*))

 

[John Brawley]

Don't worry about it. Stuff like that happens to me all the time.
Perhaps you moved something? Changed a file permission? Forgot to save
before a compile? Removed a file lock? Rebooted? Closed another copy
of your program that was running in the background? Some other
program accessing the file? The possibilities are truly endless. I
can assure you that it was not the *direct* result of removing the 8s
from the variable names. When something like that happens, I know
it's time to get some sleep.

It was. But I'm *so* sure that none of the things you mention above were
the case, and I was so intensely trying to correctly (meaning: *never* do
two things at once) diagnose the problem, that when it all worked even when
it was back in exactly the condition that had the problem before, but it
*worked*, I was (still am) completely bamfoozled.

Actually, if the OS was denying your program access to the file, then

That was the odd thing: it wasn't. Inside the braces of the second loop
within the function, nothing would go to file *or* to screen, but *one*line*
lower, just outside the closing brace for that loop, both file access/write
and screen output worked fine.

it might have been some program (a text editor?) that you were using
to verify the output. I know I've run into weird stuff like that on
Windows. Then, if you changed the file name (to remove the 8) it
would have written just fine. You would then have redirected your
text editor, model viewer or whatever to the new file, thus allowing
you to write to the old file. In other words, your program could have
been working the whole time.

Maybe something like that was going on, but still, the described oddity
above should not have "corrected itself" just with a name change. I've been
messing with computers (and build my own) since 1976 or so, and I'm aware
that occasionally some totally unfathomable interaction involving as little
as one byte (heck, even one *bit*) can make life hell until something is
done that changes the situation, but tracking down what happened is
impossible because it's hidden down in the machine somewhere, or the OpSys,
or some other weird place....

I use SciTE, and I had four files in it, two being used only as reference
(me-read-only), the other two being the nonworking program and the working
snippet, which was an exact *functional* copy of the function with the
disease.

I'll never know.
I do know it wasn't an inexperienced programmer's mistake or inattention to
detail. This was the single most frustrating weirdness I have ever run
into.

Thanks for the interaction.
Sincerely,
John Brawley