vector not pushing value within detached thread

Question

I am trying to push value from a global vector to a local vector which is declared within a detached thread context. When i am trying to push the value like this:-

¹ sensor_topolgy_contnr ² tmp_sensor_topolgy_contnr

   std::vector<sensor_modl_cred> tmp_sensor_topolgy_contnr;
   std::vector<std::pair<std::string,sensor_modl_cred>> sensor_topolgy_contnr;               

   std::thread sensor_th(
                              [=]() { 
    tmp_sensor_topolgy_contnr.push_back(sensor_topolgy_contnr[sensor_itr].second);

this the thread within which i am pushing the local vector and this thread is enclosed by another detached thread (both of the threads are detached) ¹ sensor_topolgy_contnr is globally declared vector ² tmp_sensor_topolgy_contnr is locally declared vector within detached thread i get compilation error :-

error: passing ‘const std::vector’ as ‘this’ argument discards qualifiers [-fpermissive] tmp_sensor_topolgy_contnr.push_back(sensor_topolgy_contnr[sensor_itr].second);

I can't figure out why i am getting this error i am doing this operation within a detached thread and i have not declared the local thread as constant but still i am getting this error.What should i do in this scenario.

Please post the declarations of all your variables. I.e., a minimal, complete, verifiable, example (https://stackoverflow.com/help/mcve). The error indicates that `tmp_sensor_topolgy_contnr` is declared `const`, but I can't be sure without seeing more of your code. That would be a problem, because the `push_back()` method modifies the container. — bnaecker, Jan 20 '17 at 05:40
@bnaecker that could also be the result of the vector being a member variable of a class and then trying to modify it from a `const` member function. — Mark Ransom, Jan 20 '17 at 05:44
actually this vector is not a member variable of a class but pushes struct element within it from the detached thread context — sense_kus bhatt, Jan 20 '17 at 05:45
@sense_kusbhatt We still need more code. How are you creating and starting the thread? — bnaecker, Jan 20 '17 at 05:49
i am delaring that variable within a detached thread and then i am pushing the value in the local vector through a for loop — sense_kus bhatt, Jan 20 '17 at 05:54
sorry if i am missing something please do correct me if i am failing to provide any other adequate data — sense_kus bhatt, Jan 20 '17 at 05:56
@sense_kusbhatt It would really help if you posted a complete example, which is something that I could literally copy and paste, compile, and then run on my own machine. — bnaecker, Jan 20 '17 at 06:05
but the code snippet is too long and tedious to post in this forum it is depend on several files — sense_kus bhatt, Jan 20 '17 at 06:13
@sense_kusbhatt You should reduce the code to the *minimal* amount required to reproduce your compilation error. That's what should be posted. Look at the link in my first comment for tips on how to do this. Without such code, it doesn't seem likely to me that your question will be answered. — bnaecker, Jan 20 '17 at 06:18
the problem has been solved as of now :) i dont know why the local vector is automatically being implicitly converted to const but in the local context i used the deep copy initializer concept to directl copy the value of sensor_topolgy_contnr to tmp_sensor_topolgy_contnr — sense_kus bhatt, Jan 20 '17 at 06:37
@sense_kusbhatt Glad it's been solved. It looks like this is the same problem discussed here: https://stackoverflow.com/questions/5501959/why-does-c0xs-lambda-require-mutable-keyword-for-capture-by-value-by-defau. — bnaecker, Jan 20 '17 at 16:41
u may say these two posts are somewhat interrelated sorry i didnt find this post:) — sense_kus bhatt, Jan 20 '17 at 18:17

score 1 · Accepted Answer · answered Jan 20 '17 at 19:53

The compiler is saving you from doing something useless.

Your [=] designator on the lambda causes the lambda to use a copy of all captured variables. If you copy the vector and add to the copy (which is possible if you use mutable on the lambda), the changes to made to the copy get lost when the lambda object dies -- they never get seen by the original vector.

The only time you could safely use this modified local copy is inside the lambda function itself, and if you want that, simply declare your temporary/working object inside the lambda body instead of defining it outside and then capturing.

Another way the changes could be seen is on a subsequent call of the same lambda object. But lambda objects can be copied, and many of the standard algorithms do, so having code that behaves differently when a lambda instance is reused is a really good way of becoming dependent on internal implementation details (and that results in non-portable code, a bad thing).

thanx for tis valuable answer but is the const declared implicitly due to [=] behavioue within the local copy :) i guess thts what i infer from it — sense_kus bhatt, Jan 21 '17 at 05:12
`operator()()` inside the lambda is `const` unless you use the `mutable` keyword. This prevents making changes to the vector stored inside the lambda (which is a copy of the `tmp_sensor_topolgy_contnr` that you captured). Yes, I know `tmp_sensor_topolgy_contnr` is a copy of the global variable, but it gets copied *again* for the lambda. — Ben Voigt, Jan 21 '17 at 05:16

vector not pushing value within detached thread

1 Answers1