You are here:

C++/C++ inter-program communication


Hello. For reason's not important to this question, i need to have one c++ program, access a variable that is declared in another program.
I tried taking ProgramA, declaring an integer. Then saving the address of that integer in a text file. Then while programA was still running, i ran ProgramB which read the text file, took the value and stored it into a pointer, and then read the value at that address.

The values didn't match. How to i make two program's share memory addresses?

As far as C++ is concerned the short answer is that you do not.

The longer answer is that it depends on the available facilities of the operating system you are running the programs on (assuming you are using a system that has an operating system at all). I will overview some methods; however I will leave it up to you to look up the details of the method(s) that interest you as you have not given any indication of the kind of system you are using. You can obtain further information from several places:

- In built system help, UNIX/Linux systems have the man command and manual pages for commands and functions (note: they are usually found in sections 2 or 3 of the manual). MS systems do not have developer help built in, however if you subscribe to the MS Developer Network (MSDN) or use their more recent developer tools then you may well have copies of the MSDN library installed on your system.

- From the Internet. There is a lot of software development information on the Internet. If you use Microsoft systems and do not have the MSDN library available locally then it can be found on the MSDN site ( at Most UNIX/Linux man pages seem to be available in various places. Use a search engine such as Google ( to enter a query for what you wish to know about and see what turns up!

- From books. There are many, many book on developing software so the system(s) you are using and the facilities you want information about will almost certainly be covered by some book(s) somewhere. The ACCU site ( has many book reviews (, which may help you determine those more likely to be of use.

If you are using a desktop or server operating systems such as MS Windows XP, UNIX or Linux then such systems run each process in its own protected virtual memory space. For the purposes of this question each of the programs you run will run in its own process space. Hence the addresses used by one program running in one process have meaning only in that process. This is made possible by the virtual memory management facilities of the processors. In fact if you run two instances of the same program (each in its own process) then you can expect the addresses of objects to have the same memory address in each process. That is each process has a virtual memory address range the same as any other process. Behind the scenes the virtual memory system will map these virtual addresses to the required physical memory addresses.

Run time libraries can be shared by several (or all) processes. Such libraries are called shared object libraries on UNIX/Linux like systems and Dynamic Link Libraries (DLLs) on MS Windows (and some other) systems. In such cases the required code (and data) is mapped into each process' address space.

OK so that is the background on why your plan did not work as expected. What can you do to fix it? The general term for handling this sort of problem is called Inter Process Communication or IPC for short.

The most obvious method would be to ask for a shared region of memory between program processes. This is called shared memory or a memory mapping. UNIX/Linux systems have two API sets for handling such a facility: The older System V shared memory API, with functions like shmget, shmat, shmdt, and the POSIX API functions mmap, munmap msync. MS Win32 systems have the functions CreateFileMapping, OpenFileMapping, MapViewOfFile, MapViewOfFileEx, FlushViewOfFile.

Note that sharing data between processes can cause synchronisation problems if more than one process wishes to update/access the data at a time.

There are other methods. For example you could use a pipe to transfer the data from one process to another. Pipes connect the output of one process to the input of another. See the UNIX/Linux (POSIX) pipe and mkfifo API functions and the Win32 CreatePipe, CreateNamedPipe, ConnectNamedPipe etc. API functions. In your case named pipes (POSIX calls named pipes FIFOs) would be most useful as you can share the name (typically similar to or the same as a file name) between programs. Similarly you could use sockets (as in TCP/IP socket) to transfer the information, see API functions socket, bind, accept, listen etc. (note Win32 has the winsock2 API functions that are similar to the UNIX/Linux/POSIX/Berkley style socket API in this case).

You could also use middleware systems such as COM/DCOM and CORBA. These, like named pipes and sockets, have the capability to allow your programs to be running on different machines altogether.

Note that there are libraries that can wrap some/all of these raw operating system facilities. One such is the ACE library (

I hope I have given you enough information that you can look up further information on the specific parts that interest you.  


All Answers

Answers by Expert:

Ask Experts


Ralph McArdell


I am a software developer with more than 15 years C++ experience and over 25 years experience developing a wide variety of applications for Windows NT/2000/XP, UNIX, Linux and other platforms. I can help with basic to advanced C++, C (although I do not write just-C much if at all these days so maybe ask in the C section about purely C matters), software development and many platform specific and system development problems.


My career started in the mid 1980s working as a batch process operator for the now defunct Inner London Education Authority, working on Prime mini computers. I then moved into the role of Programmer / Analyst, also on the Primes, then into technical support and finally into the micro computing section, using a variety of 16 and 8 bit machines. Following the demise of the ILEA I worked for a small company, now gone, called Hodos. I worked on a part task train simulator using C and the Intel DVI (Digital Video Interactive) - the hardware based predecessor to Indeo. Other projects included a CGI based train simulator (different goals to the first), and various other projects in C and Visual Basic (er, version 1 that is). When Hodos went into receivership I went freelance and finally managed to start working in C++. I initially had contracts working on train simulators (surprise) and multimedia - I worked on many of the Dorling Kindersley CD-ROM titles and wrote the screensaver games for the Wallace and Gromit Cracking Animator CD. My more recent contracts have been more traditionally IT based, working predominately in C++ on MS Windows NT, 2000. XP, Linux and UN*X. These projects have had wide ranging additional skill sets including system analysis and design, databases and SQL in various guises, C#, client server and remoting, cross porting applications between platforms and various client development processes. I have an interest in the development of the C++ core language and libraries and try to keep up with at least some of the papers on the ISO C++ Standard Committee site at


©2017 All rights reserved.