What is the behavior of various systems when you have more than one copy of a particular program or library running, do string literals get stored once in RAM or once for every copy of the process/library? What if they are stored in an array like:

static const char *const foo[] = { "bar", "baz", "buz" };

Does the static change the behavior of the memory storage at all?

Edit: Since it is likely platform specific, what is the behavior on Micro开发者_如何学运维soft compiler on Windows or GCC on linux (x86)?

Assuming you are asking about dynamically linked library data, typically each process would get its own copy of the data, at least virtually. The operating system could actually use the same RAM to hold this data, though. If the data were then written to by one of the processes the OS would then make a new copy of the data that that process could change and let the other processes keep looking at the old copy. This is known as Copy On Write (COW).

For statically linked libraries, the programs have their own copy of the data usually, except that if the same program is run more than once each instance of that program would likely share the view of the same data in much the same way as the dynamically linked library data.

Some OSes probably don't implement the COW stuff.

edit

After reading a comment to another post I decided to delve in a little bit more.

Since you have a lot of string literals, which are constant, they should get put in a read only section of your executable. Since they are read only your program would be in error to attempt to write to them anyway so the OS would probably not have to make copies of them.

If you declared a lot of string variables and did not declare them as constant variables (oxymoron) then you might end up with more copies of them since they would be put in a writable section of the executable and even if you didn't write to them other data close to them could be written to, which might result in them getting copied along with that data.

I assume this is platform specific as there are no such specs in the language.

Does the static change the behavior of the memory storage at all?

Yes but not in regards to string literal storage between multiple copies of a process or library.

As the processes' memory is isolated (well, mostly), each process has a copy of all strings in it's virtual memory. However this depends on the compiler (I didn't investigate how compilers handle various string constant declarations). In general if the block of data (or code) is mapped into address space, it's not "loaded" into physical memory more than needed. One copy is kept in physical memory block (page), and this page is mapped into different virtual addresses of several processes. If you modify the data in virtual space of one process, a copy of this page is created and mapped to the old virtual address.

In your task it makes sense to keep all resources as PE resources and load them in code into memory-mapped file. Each application instance would do this if it has not been done by previous instance of the application. This way you always have just one copy of the constants in memory.

The static shouldn't affect this, since it makes no specification about the string literals themselves. They still might be returned to callers from other compilation units, and thus to an application that links to a library, e.g.

Windows and I believe Unix/Linux, allows this, and in the early days, when RAM was limited, encouraged it use. However, this was a trade-off between conserving memory, and preserving memory protection. As memory addressing ranges grew, and RAM became cheap, it was largely decided that it wasn't worth the trouble. (In Win16, I believe doing this was the default; under Win32, it requires some manual steps to use it)

In some specialized environments (embedded systems for example), it may still be worthwhile (but embedded system rarely need to run two copies of the same app)

UPDATE: In Windows, you can have a resource-only DLL, which can be marked "shared". That's probably the best way to handle what you want.