Re: Noob on memory and data streams...
On May 8, 4:41 am, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
noemailplease wrote:
I would like to write a (small) app in C++ that streams a
"signal value" (-1, 0 , +1) to a specific memory address
where this value can be read by a second application (over
which I have very little control, other than (possibly)
specifying the memory address of the signal values).
This all seems a bit long-winded in my mind, and raises
several questions:
Is it possible to specify (hard-code?) an address in which
store a value?
That's platform-specific. There is no portable way.
Partially. The standard does say that you can reinterpret_cast
an integer to a pointer, so regardless of the platform, his code
will likely use a reinterpret_cast. (For the rest, of course,
what any integer means when reinterpret_cast to a pointer is
implementation defined.)
How does one check that address is free beforehand?
Unknown. In most cases there is no way an application (a
process) can check anything that might belong to another
application (process). It's called "memory protection".
In most cases, it doesn't matter, since the process can't access
anything in another process, either. Most systems do have some
means of sharing memory, however. Some of which don't even
depend on the memory being at the same address in the two
different processes. (Under Unix, for example, one simple
solution to his problem would be to put the signal value and a
mutex in a mmapped file. And let the system choose where to map
it.)
And of course, on most, if not all, systems, there are ways for
priviledged processes to access the memory of other processes.
And usually also for unpriviledged processes, if the other
process collaborates a little. (Otherwise, how could you
implement a debugger.)
But as you say, it's all platform specific.
Is there some sort of semaphore to stop read/write
collisions between different applications?
There are ways to synchronize access to a resource. They are
platform-specific in most cases.
Is there a better way to do this?
Files.
Not always better or simpler. It depends on what he's really
doing.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34