My review is based on a very light skim through everything. Sorry its not more comprehensive, but if/when I get time I defintely want to play with this library! ***Design*** Shmem is limited in scope. Its a low level building block for implementing local inter process Object transfer. AFAICS shmem doesnt concern itself much with the protocols of IPC. It wont scale to distributed communications. Is there scope for proprietary IPC mechanisms , (such as COM, DDE, and CORBA), to be built on top of it ? The restrictions placed on the types of objects that can be placed in shared memory are understandable, but heavy and presumably cant be checked?. Now there Must be a special definition of an shareable-object outside C++ class eg like a COM interface. In fact some evidence that this is occurring with classes such as basic_named_shared_object. However should these objects not be designed for distributed environment as well as local one? If shmem doesnt provide protocols for building objects that can be passed over a network and in a scaleable way then objects using its mechanisms direct will be of limited use, so larger picture should be taken into account Now. *** Offset Pointers *** Couldnt pointer_offsets be a class?. This would mean overloadable functions, type safety, rather than ptrdiff_t which I'm guessing is an int or something? -------------- ***Did you try to use, with what compiler?*** Tested out ProcessA/ProcessB example in VC7.1. Could do with some documentation as to how it should work. C++ IPC is unfamiliar territory! Eventually figured out that running ProcessA and then ProcessB in separate Command Prompt windows should have the desired effect.. which it did. Its Fun.! ---------- *Documentation* It seems a lot of effort has been put into documentation. Its noted that Ion is not a native English speaker, but it reads OK in spite of that. It probably needs to be better organised though. Concepts and Definitions section should be split into Concepts section and Definitions section. Traditionally definitions are put near to start of docs so user knows where they are before defined words are used. Definitions should be expanded A Lot ... to include many more entities such as mutex, semaphore, shared-memory, named-shared-memory,offset-pointer, process etc etc etc. Even if you think you know what they mean, some words need to be defined so reader can see what author means in this particular context. Quick guide for the impatient could then benefit from having unfamiliar terms hyperlinked to their definitions. ---------- **Construction *** On construction issue , only because its been brought to light recently. named_shared_object segment; //Create shared memory if(!segment.open_or_create(shMemName, memsize)){ std::cout << "error creating shared memory\n"; return -1; could (presumably?) be replaced with try{ //Create shared memory named_shared_object segment(shMemName, memsize); } catch( shmem_exception & e){ std::cout << "error creating shared memory\n"; return -1; } which I would prefer. --------------------- ***Should it be a boost library** You betcha. Yes indeed It should definitely be a boost library. C++ needs this type of library badly. It is all very low level however and I would like to see a higher level abstraction for designing objects that can be passed about over a network too though and shmem objects should then try to conform to that, but that shmems role would be maybe as a building block for that. Needs to be discussed. If it is in Docs.. Sorry I missed it! regards Andy Little