Forum Replies Created
-
AuthorPosts
-
::
As you mentioned the pointer p is const per se and it is pointing to a const integer. Therefore you can are neither change the value (through *p) nor the address it is point to (through p).
In both cases you get almost the same error: “error: assignment of read-only location ‘*(const int*)p'” and “error: assignment of read-only variable ‘p'”, check it here: https://godbolt.org/z/eE6dMeshsP.S. I wanted to reply directly to the message from Antonella but the Forum tool placed my text as the last one in the order.
::It is correct. The provided char value is promoted/converted to its integral value due to the operator+ which requires two integral operands to sum them up. You can place your code in CPP-Insides and see this static_cast.
You get the warning because a char (single qoutation marks) can have only one letter, because it occupies only one Byte in memory.
You get the error when you use the string because is not convertible to a number.
::I think the constness is removed from the return type because auto decays, i.e., the constness any reference or pointer is removed from variable defined as auto.
Just specifying the return value as const does not bring any benefit with it. Only if you return a const& then it is important/interesting, but be aware of the lifetime of the object/variable you are returning the const& from.
::I am currently working in the IT/financial branch. We do integrate different payment terminals in our product and provide an standard API to the ECR softwares.
I worked as well in another company where we developed algorithms and services in GNSS (GPS, Galileo and Glonas) and telecommunication.
At both companies I worked (still working) as C++ developer being responsible for product/service design, implementation, testing, etc.::I think it can happen. You can simulate this behaviour if you put a sleep( 2s ) between the two threads in main function (so let just one thread run for a time).
Here you have the code example: https://godbolt.org/z/9b9rx67hs where first thread locks “only” twice the mutex. I mean, it cannot happen three times.
A screenshot of the output which shows the same thread locking twice and the other one locking afterwards.But since the critical region is protected (additionally) by the predicate (dataReady == false), then the thread setTrue cannot enter this area and modify the counter again.
When the predicate returns false, then the condition variable (condVar1) releases the locked mutex and takes a nap. Therefore, the other thread can lock the mutex and enter its crititcal region, where it can change the value of dataReady::Hi again,
the video is wrong in this lesson: https://www.modernescpp.org/topics/example-stringcversusc-cpp/
and here it is missing: https://www.modernescpp.org/topics/example-stringnumericconversions-cpp/
Thanx for fixing them!
::To avoid reallocating the elements, I calles rehash at the beginning. Therefore there are as much buckets as elements to be added and loadFactor = 1.
Theoritically each thread should generate in-place an element and place it to the corresponding bucket. This is what makes me thinking that, even the map is shared among all threads, every thread “knows” how to behave and should not effect the others.
-
AuthorPosts