Hi David,
I find that a rather self-fulfilling statement. It's insulting to characterize my expression of concern for this design principle as flame.
I've not tried to insult you. So if it was the case, please forgive me.
that does not benefit Boost or Shmem itself.
I think if you tried to learn something from my comments, Shmem's design would in fact benefit.
What I want to know is if you consider a library rejection reason if Shmem provides *both* RAII *and* open/close functions.
I consider a design that specifically accomodates a version of C++ with some of its features turned off at the expense of guarantees that one can otherwise achieve -- especially if that expense is completely avoidable -- cause for concern. And based on your response to my concerns so far I would be inclined to worry about the future of the library and your responsiveness to other legitimate concerns. All that would tend to bias me towards voting against this library. It's not a reason for a "no" vote in and of itself, but if I had any energy left to do an actual review, I would certainly be motivated to find other areas where the design looked problematic to me.
I see. Obviously, since I've been defending the other alternative, I don't see the double-alternative so dangerous. But I see that current open/close *only* view is dangerous. After thinking it a bit, if boosters think that double way is too dangerous (well, some other has expressed the opposite view and wants alternatives) I'm ready to remove open/close expressions and implement a RAII only final version. But surely someone won't agree with it and it might have good reasons. But I repeat: I propose a RAII only version. I don't think this aspect is the most important aspect of Shmem.
The optional may be or not constructed, and you have to check that before using optional. I'm trying to avoid dynamic allocation so scoped_ptr is not a good enough solution in my opinion.
The scoped pointer or optional would be employed by the *user* of shmem who wants to achieve that difference in lifetime.
Yes. But I wanted to avoid Shmem users to be forced to use dynamic allocation or optional if the want two-phase initialization. Re-reading the proposed C++ N1883 paper Kevlin Henney wrote about threader-joiner architecture similar to smart pointer/new combination: class threader { public: template<typename nullary_function> joiner operator()(nullary_function threadable); ... }; template<typename threadable> joiner<return_type<threadable>::type> thread(threadable function) { return threader()(function); } int main () { //Class approach threader run; joiner wait = run(first_task); //or function approach jointer wait2 = thread(second_task); } Couldn't be an alternative something similar with Shmem primitives: shared_memory_handle shm = shared_memory(/*open, open/create overloads*/); shm would be like the proposed joiner (CopyConstructible, Assignable, and DefaultConstructible and Shareable (via an internal shared_ptr, for example) so that I could have a shared_memory_handle member in a class that can be initialized when I want. Much like a shared_ptr member that can be default constructed but only initialized though an external "new T" operation. I see that since shared_memory_handle has default constructor it can be also a two-phase initialization class (much like shared_ptr) but do you think this architecture is acceptable or you think it has the same problems as the previous one? I'm trying to offer some alternatives I've seen in proposed WG21 papers (but I'm ready to offer a RAII only interface, as I've said).
And for example, to open raii I need 3 arguments, and to create raii resource I need 4.
class Holder { RAII raii; public: Holder(/*some conditions*/) : raii(/*Create or open depending arguments, and other temporary results*/) {} };
So make your constructors more flexible.
class Holder { RAII raii; public: Holder(/*some conditions*/) : raii( generate_initializer( arguments and other temporary results ) ) {} };
If you use the parameter library it's especially easy to accomodate this sort of interface.
I see. I can wrap all parameters in a single object to avoid this problem.
Then you clearly don't understand me at all. I'm arguing that interfaces that easily lead to zombie states make components harder to use and code harder to think about. Just providing a *way* to avoid the zombie state does not help me know that I can operate on such an object that I'm passed by reference without first making sure it's not a zombie.
Well, someone can pass you shared_ptr that is empty and we don't forbid an empty shared_ptr. I think that functions can establish preconditions to say what kind of parameters they expect.
I think that apart from this C++ aspect of your knowledge, there is plenty of your C++ knowledge that you can use in other aspects of the library. And I'm really interested in them. Specially, if they are related to correct uses or better idioms like the previous one. And I want to support those idioms. I just want to provide some alternatives apart from your advices.
I think I've used up most of my available energy on this one. :(
Ok. But don't say you were not invited to the party ;-) Now, seriously, I'm ready to offer a RAII only approach if the above described alternative is considered also a bad design. I would only need a class/library that you think it implements well this RAII approach (what kind of exceptions it throws, and so on) to have some good model. I do understand your concerns and I think that Shmem has much more to offer than this initialization problem. Regards, Ion