Ion Gaztañaga wrote:
Hi fred,
First, there tends to be a create and object member function of a lot of objects in the library. This forced Ion to create partially constructed objects with the constructor, but it allows the use of return values instead of exceptions for error handling. I personally do not like partially constructed objects, and I do not mind exceptions that are thrown if there's a serious problem detected. I'm curious what the rationale was for that decision. Do the create/open functions fail frequently in typical use cases?
Can you elaborate a bit on this? I can't understand well what you are trying to point out.
I think he's pointing out the lack of RAII. From your first example: named_shared_object segment; if(!segment.create("/MySharedMemory", //segment name 65536)){ //segment size in bytes return -1; } void * shptr = segment.allocate(1024/*bytes to allocate*/); segment.deallocate(shptr); I'd rather see: try { named_shared_object segment("/MySharedMemory",65536); shmem::shared_ptr lPtr = segment.allocate(1024); } catch( const shmem::exception& aExc ) { ... } Where the shared_ptr has a deleter calling named_shared_object::deallocate. I'd also think that the 'shared_memory' should not be destructed until the last shmem::shared_ptr is released. Which brings up the issue that I could not easily find any discussion of lifetime requirements in the documentation. Thanks, Jeff