When I tried to upgrade shmem 0.9 in vault I am failing to compile on Cygwin using gcc 3.4.4 with the following error message.

e:/boost/boost_1_33_1/boost/shmem/shared_memory.hpp:585: error: there are no arguments to `shm_open' that depend on a template parameter, so a declaration of `shm_open' must be available e:/boost/boost_1_33_1/boost/shmem/shared_memory.hpp:585: error: (if you use `-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)

I went a head and added the following two lines to shared_memory.hpp after which I was able to compile.

I didn't know that someone was trying to use this in cygwin! Last time I checked, cygwin had not PTHREAD_PROCESS_SHARED support so I thought Shmem couldn't work with cygwin. I'm wrong or has this changed? You've said "I tried to upgrade shmem 0.9" so I suppose you have tested previous Shmem versions. What was the latest version of Shmem that you could compile? I don't know much about cygwin but shared_memory.hpp header says: #if (defined BOOST_WINDOWS) && !(defined BOOST_DISABLE_WIN32) # include <boost/shmem/sync/win32/win32_sync_primitives.hpp> #else # ifdef BOOST_HAS_UNISTD_H # include <fcntl.h> //O_CREAT, O_*... # include <sys/mman.h> //mmap # include <unistd.h> //ftruncate, close # include <semaphore.h> //sem_t* family, SEM_VALUE_MAX # include <string> //std::string # include <sys/stat.h> //mode_t, S_IRWXG, S_IRWXO, S_IRWXU, # else # error Unknown platform # endif So if you have calls to shm_open in the code the #if (defined BOOST_WINDOWS) && !(defined BOOST_DISABLE_WIN32) condition should be true and since you don't get # error Unknown platform I suppose BOOST_HAS_UNISTD_H is true. And posix says # include <sys/mman.h> //mmap is enough to get shm_open and shm_unlink declarations. Can you investigate this a bit further? Thanks, Ion

It may be just a 'feature' of windows, but the shmemdoc-0.9.zip appears corrupt here in winrar, winzip and in explorer. lib file is fine. - unexpected end of file.

Re-uploaded, downloaded and unzipped. Now, it seems to work. Thanks, Ion

Hi Pedro,

I suggest supplying a default constructor to the shared memory Allocator (and generally making it compatible with the Allocator concept) in order to allow the easiest uses, like:

std::queue<boost::shmem::allocator> global_queue;

But since a shared memory segment is dynamic (and because of that, the address is not known at compile time) how can the allocator know the address of the segment from where it has to allocate memory? Also, if the user opens more than one segment, you must say from which segment you want to allocate memory. If you have only one segment you could use a static object to tell so. This is a bit different from "operator new", because there is just one standard heap source and you don't need any handle to call global new. When allocating from shared memory, and since you can have multiple segment, you need dynamic data. But if you have any idea to initialize the allocator you think it's better than the current approach, I'm open to include it in Shmem. Regards, Ion