"Ion Gaztañaga" wrote:

first rough version of shared memory library http://groups.yahoo.com/group/boost/files/boost.shmem.zip

________________________________________________ 1. The HTML documentation does't allow to change font in browser. ________________________________________________ 2. End of document can be marked so it doesn't look like cut in half during transmission. ________________________________________________ 3. docs 3.2: "Boost Shmem provides some STL containers" probably means "Boost Shmem provides some STL compliant containers" ________________________________________________ 4. Example in 3.2: the "alignement" parameter in segment.create() isn't found in code. ________________________________________________ 5. Example in 4.2: segment.named_new<MyType> ("MyType instance", /*name of the object*/ 10 /*number of elements*/, false /*if previously present, return error*/, 0 /*ctor first argument*/, 0 /*ctor second argument*/); a. What does t mean "return error" here? Exception? b. Wouldn't it be better to split the function into two, one which allow to overwrite, second which doesn't. This would get rid of boolean parameter which is always hard to understand w/o context. c. Could the syntax be like: segment.named_new<MyType>("name")(ctor_param1, ....); so it looks more like operator new? Current signature feels very prone to bugs. In: std::pair< MyType *, std::size_t> res = segment.find_named_new< MyType > ("MyType instance"); Why do I need the "size"? Doesn't a type have always the same size regardless? Isn't sizeof(MyType) == res.second always? ________________________________________________ 6. Could you use namespace shmem_detail or so instead of "detal" to avoid possible clashes? ________________________________________________ 7. exceptions.hpp: a) file name should be shmem_exceptions.hpp or so b) does it make sense to have common base for both exceptions there? ________________________________________________ 8. offset_ptr.hpp: full_offset_ptr class a) using char as de-facto bool class has usually no practical advantage and may be actually slowe. b) The flag could be eliminated completely. If m_offset == 0 it is NULL pointer and no data allocated in shmem will starts on the beginning. This would also eliminate need for min_offset_ptr. c) swap() could be added and other operators. ________________________________________________ 9. Maybe the protection of mutext from shared ptr lib could be worked around so the code duplication would be eliminated. Even if it is dirty it would be worth. ________________________________________________ 10. The example in 4.3 uses very dirty C-like approach with casts. Cannot it be rewritten in C++ way with overloaded new? ________________________________________________ 11. Some source files use Unix line ends, some DOS line ends. Just bit strange. ________________________________________________ 12. The simple algorithm to find fitting memory block may not be adequate for high-performance apps (who are most likely to use shared memory). ________________________________________________ 13. Can be be possible to identify named objects with something else than C string? Say wchar_t* or numeral or other templated type? ________________________________________________ 14. What I would like to see: a) avoiding shmem specific containers/mutexes/etc as much as possible. b) ability to "equalize" shared memory features between operating systems. E.g. Windows deletes shared memory when no one is using it, Unix keeps it until destroyed explicitly. I would like to have both approaches on both platforms (handled possibly by exec()ing helper process. In addition, Shmem should provide platform specific access to its internals, e.g. to Win32 handles to allow security settings. c) support for inheritance in shmem using object factories, e.g. like one in Classloader http://s11n.net/papers/classloading_cpp.html d) support for "transactions": I would like to be able to add/modify/remove objects in shared memory and made all changes visible to other process in one moment. This would save me one more IPC channel to signal readiness of data. If possible the library should provide several levels of isolation. Long lasting transactions could be also considered. /Pavel