Thursday, March 9, 2017

Digest for comp.lang.c++@googlegroups.com - 12 updates in 6 topics

Mike Copeland <mrc2323@cox.net>: Mar 09 04:06PM -0700

Some basic problems have been solved, but the "root issue" remains.
That is, I need to populate a structure (i.e. std::map) that contains a
pointer to an integer value that can be changed. For example,
#include <map>
#include <string>
int main()
{
int BNoffset = 42;
map<std::string, int> csvMap2;
map<std::string, int>::iterator csvIt;
csvMap2["BIB"] = BNoffset;
csvMap2["NO."] = BNoffset;
csvIt = csvMap2.find("BIB");
if(csvIt != csvMap2.end())
{
csvIt->second = 17;
}
return;
}
The program starts with "BNoffset" establishing a (default) value.
After I populate the std::map, I will need to change that variable's
value - to something I calculate. My dilemma is that I can't declare
the map object's type (I want pass-by-reference?) during
execution...because I can't find a way to declare and use the object's
"second" component. The code compiles, but it doesn't alter the
_contents_ of "BNoffset", which is my goal.
In essence, I don't know how to declare and use pointer addressing in
the way I want. Is it possible? If so, please explain how. TIA
 
 
 
 
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Manfred <invalid@invalid.add>: Mar 10 12:23AM +0100

On 03/10/2017 12:06 AM, Mike Copeland wrote:
> _contents_ of "BNoffset", which is my goal.
> In essence, I don't know how to declare and use pointer addressing in
> the way I want. Is it possible? If so, please explain how. TIA
 
#include <map>
#include <string>
int main()
{
int BNoffset = 42;
map<std::string, int*> csvMap2;
map<std::string, int*>::iterator csvIt;
csvMap2["BIB"] = &BNoffset;
csvMap2["NO."] = &BNoffset;
csvIt = csvMap2.find("BIB");
if(csvIt != csvMap2.end())
{
*(csvIt->second) = 17;
}
return 0;
}
 
This would do what seems to be what you are asking here, although it is
not clear if this is what you were looking for in the original post.
Marcel Mueller <news.5.maazl@spamgourmet.org>: Mar 09 08:53PM +0100

On 09.03.17 20.01, Christopher Pisz wrote:
 
> lock.lock();
> }
 
> lock.unlock();
 
The lock still makes no sense here.
 
 
Marcel
Christopher Pisz <christopherpisz@gmail.com>: Mar 09 12:19PM -0800

On Thursday, March 9, 2017 at 1:53:53 PM UTC-6, Marcel Mueller wrote:
 
> > lock.unlock();
 
> The lock still makes no sense here.
 
> Marcel
 
 
Can you elaborate on why this makes no sense?
The intention is to run the loop until state is not "started" or "starting"
 
If one thread reads and another write to a variable, we lock it.
Why does the lock make no sense?
 
Are you claiming that an integer type is atomic by default?
Christopher Pisz <christopherpisz@gmail.com>: Mar 09 12:33PM -0800

On Thursday, March 9, 2017 at 12:25:23 PM UTC-6, Marcel Mueller wrote:
SNIP
 
 
> The comparison is not your problem. The code at DoStuff probably need to
> be synchronized with state changes.
 
> Marcel
 
 
I really don't care if the state changes while I am "doing stuff."
I only care that the state was exactly what we checked for in the condition when we checked it.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Mar 09 11:10PM

On Thu, 9 Mar 2017 12:19:12 -0800 (PST)
 
> If one thread reads and another write to a variable, we lock it.
> Why does the lock make no sense?
 
> Are you claiming that an integer type is atomic by default?
 
In practice on any architecture you could be interested in, ints (but
not necessarily all integer types) are atomic (in the
std::memory_order_relaxed sense).
 
However your latest question above is irrelevant to your original
question, wherein you correctly pointed out that your mutex locking
makes the ORed comparison atomic, whereas just substituting atomic
variables, of whatever memory order, without some other synchronization
mechanism between them such as "test and loop" will not.
 
This raises a number of points which would need to be answered to solve
your first question. In particular, why does it make a difference in
your use case that the ORed enumeration comparison should be atomic
when it does not matter that the dependent operations (those covered by
your "Do Stuff") are not also atomic with respect to the enumeration
comparisons? Possibly your code was implementing some kind of test and
rollback before committing changes but that is not immediately obvious,
and in that case does the first comparison need to be atomic at all?
 
I think that was Marcel's point.
woodbrian77@gmail.com: Mar 09 02:59PM -0800

On Wednesday, March 8, 2017 at 2:53:52 PM UTC-6, Alf P. Steinbach wrote:
> std::cout << v << "\n";
> }
> }
 
OK, I understand some of that, but if the claim that plf::stack
generally out-performs std::stack:
 
"Simply put, plf::stack out-performs both std::stack (std::deque)
and std::vector once you take into account both push and pop time,
and we can see that the larger the stored type is, the greater
the performance advantage is."
 
is true, it's the container I'd rather focus on. It's not clear
to me if adding interfaces to support serialization would somehow
compromise his implementation/test results.
 
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
"Chris M. Thomasson" <invalid@invalid.invalid>: Mar 09 01:02PM -0800

For now, lets start off with taking a simple case of a try_lock
operation failing on a mutex. What if we tried to do something else
while we had to wait anyway?
 
Think of all those mutex lock operations? Can they be converted into
little message pumps in and of themselves? Fwiw, here is some very
contrived pseudo code, that just scratches the surface of this possible
line of thinking:
____________________________________
for (;;)
{
if (try_lock()) return;
 
if (! try_something_else())
{
// possible nesting opportunity...
lock();
return;
}
}
____________________________________
 
 
We try to lock the mutex to perform work under its protection. If that
action succeeds we exit the for loop. If not, we try to do something
else, this can be recursive up to a limit. If we actually did some work
wrt trying something else, we repeat the process wrt the for(;;) loop,
trying the original mutex lock again. However, if no other work could be
found, we just block for the locking action of the mutex, and wait for
it be committed, and exit from the loop. AFAICT, this is a sort of "odd
message pump" in a sense, with an adaptive mutex flare.
 
The key aspect is that the mutex is locked when this for(;;) loop exits.
Ready for the caller to use.
 
Humm..
 
Any thoughts?
 
Is this crap? It cannot be anything new. But, it would be nice to talk
about threading here for C++ can handle it now.
 
Nice! :^)
David Brown <david.brown@hesbynett.no>: Mar 09 10:00PM +0100

On 09/03/17 19:25, Mark Storkamp wrote:
 
>> Comport.print(...);
 
> Thanks, that's exactly what I need. Don't know if it's C++11 or not, but
> one way or the other should do it.
 
If you get /really/ stuck for this sort of thing, there is always #define:
 
#ifdef ARDUINO_AVR_PROMICRO
#define ComPort Serial1
#else
#define ComPort Serial
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)