It looks to me that you are talking about different things. I think Ion agrees about invariants but advocating an interface that can be used without exceptions, to make the library accessible to the platforms with no exception available. And without exceptions, you can't ensure that no object with invalid state is constructed. So there is two choices - or to provide an exception-only interface and strong invariants, or to allow the library to be used in a restricting embedded environment.
Someone please correct me if I'm wrong, but doesn't the GCC C++ std library (and maybe others) support a "no exception" compile time flag, by replacing thrown exceptions with an assert? Within the library, every place an exception would be thrown goes through a function that has a compile time conditional on either throwing the appropriate std lib exception or calling assert. I think the goal of providing alternate interfaces for embedded environments where exceptions are not supported is misguided. Note that support for replacing the thrown exception with assert is NOT supporting alternate interfaces to the library - it is supporting alternate error recovery mechanisms, which is a different thing. I wonder how environments without exception support handle the C++ std library, since exceptions are part of the standard (and I haven't looked at the EC++ effort, which I think was promoted by Dinkumware and maybe others). I'm a very big believer in preconditions, invariants, etc. I can provide real-world experience (multiple large-scale projects) about the problems caused by two-phase construction (or more specifically, the easy misuse and hidden costly bugs introduced as part of a two-phase construction design). If we were still in the early 90's, where C++ exceptions were not the norm (or not well implemented), it would be a different story (e.g. the ACE library is full of two-phase construction designs due to it's vintage, but if the ACE people were starting from scratch today, it would be a far different story). I guess I just don't see where Shmem is fundamentally different from other Boost libraries, where it must support alternate interfaces for exception-less environments. I haven't recently looked at Shmem, so I'm not criticizing it's (most likely excellent) quality. I'm just chiming in with Dave A and others about class design principles, of which I hold strong opinions. Cliff