0

I declare a vector in the .h file:

typedef std::vector<bool> bit_vector;
bit_vector decoded_lcw_vec;

In the .cc file I fill the vector like this:

 bit_vector decoded_lcw_vec(corrected_array, corrected_array + sizeof corrected_array / sizeof corrected_array[0]) ; 

and the the correct values are in it:

printf( "\n\n Decode LDU1 LCW Vector Complete:");
for(int i = 0 ; i < 72; i++ )  cout << decoded_lcw_vec[i];    

gives:

Decode LDU1 LCW Vector Complete:000000000000000000000000000000000000111111111111000000000000000000000101

so the problem is that if I try to access the vector outside of the function where it is filled, then I get a seg fault. No matter how I try to access the vector, the program dies. I want to do:

uint16_t 
ldu1::lcf() const
    {
    const size_t LCF_BITS[] = {
    0, 1, 2, 3, 4, 5, 6 , 7
    };
const size_t LCF_BITS_SZ = sizeof(LCF_BITS) / sizeof(LCF_BITS[0]);
const uint16_t lcf = extract(decoded_lcw_vec, LCF_BITS, LCF_BITS_SZ);
return lcf;

}

it seg faults. I've tried many other ways to access the vector. If I try any kind of print statement, or whatever, program seg faults. So, no matter how I try to do it, the program seg faults when trying to access the vector outside of the function where it is filled. The problem has to be i am trying to make illegal access right? How can this be since I declared the vector private in the .h file and the class has not been destructed?? That vector should, at least I was under the impression that it would, persist until the the class was destroyed.

Is it possible that this vector is on the stack and hence out-of-scope by the time control returns from the call?

crash
  • 1
  • 1
  • Show the smallest complete program that you can come up with that compiles and runs and shows the problem. – Pete Becker Dec 11 '13 at 19:33
  • 3
    Please post all your code. This is not enough information. It sounds like decoded_lcw_vec is on the stack and is being deleted when the function exits. – Blazes Dec 11 '13 at 19:33
  • whats the function footprint for decoded_lcw_vec and/or extract? – IdeaHat Dec 11 '13 at 19:34
  • the whole file is like 540 lines. and this is least amount of code i could put and still describe the problem. like if i don't show the typedef, some will say, "how are you declaring this". – crash Dec 11 '13 at 20:04
  • ldu1.cc:343:106: error: no match for call to '(bit_vector {aka std::vector}) (int [72], int*)' is the compile time error if i don't type the vector in the .cc file. – crash Dec 11 '13 at 20:16

1 Answers1

3

The problem appears to be that you are declaring a new variable with the same name in your function. This variables scope is the function and is destroyed at the end of the function. If you want it to be the class member change this line:

bit_vector decoded_lcw_vec(corrected_array, corrected_array + sizeof corrected_array / sizeof corrected_array[0]) ;

to:

decoded_lcw_vec = bit_vector(corrected_array, corrected_array + sizeof corrected_array / sizeof corrected_array[0]);
pippin1289
  • 4,861
  • 2
  • 22
  • 37
  • but now the error on compile is: ldu1.cc: In member function 'void ldu1::correct_lcw(int*)': ldu1.cc:340:106: error: no match for call to '(bit_vector {aka std::vector}) (int [72], int*)' – crash Dec 11 '13 at 20:01
  • How about &corrected_array[0] for the first argument? I think the compiler can't deduce the template argument of the vector constructor correctly. – pippin1289 Dec 11 '13 at 21:46
  • its typed int. btw, if i declare that array in the header then i can use it as expected. i dont understand why this is not so for the vector. – crash Dec 11 '13 at 22:18
  • is it an int[] or int* or what? I cannot replicate the error you are getting in a simple program where I declare an int arr[] and fill the vector like I said above. You can try filling the array differently as a test, but I cannot replicate the error you said you are getting during compilation. – pippin1289 Dec 11 '13 at 22:21
  • @crash I can replicate it. You copied my code wrong. make sure it is `decoded_lcw_vec = ....`. NOT: `decoded_lcw_vec(...)` – pippin1289 Dec 11 '13 at 22:27