It seems to me that what constitutes an initialised state of an object is largely library defined. One size does not fit all, some libraries will suit certain tasks better than others. As long as the state after construction is known and documented then it seems that even the EventLog with a default constructor would be a strictly correct (if not that useful) design. Some of the main reasons for two phase construction is to allow for relationships between long lived objects, and often to allow complex operational properties to be assigned or adjusted dynamically through the life of the objects - without constraint from external (outside program control) objects. Whether it is called "two phase construction" or whether it is just that we say the object is defined as having an active and inactive state does not matter much. AFAICT this is the principle that is being discussed. Mostly I am thinking of database and GUI applications, but we can demonstrate the principle using a file class (ignoring the availability of streams)... MyFileClass f; // an empty, unopen, unnamed file object f.set_file_name("afile"); // a named but still unopen file f.open(ForRead); // now an open for reading the file Is it bad to allow MyFileClass to be constructed in this way? It would seem to partially violate the resource acquisition is initialisation principle although exactly what happens internally I have not defined and it can still ensure appropriate release of resources when the object is destroyed. The advantage of such a system is the ability to hook up potentially complex objects and use events (or signals or whatever you want to call them) to keep them in touch using observer patterns. For example we may connect an object to f and observe signals that it sends out about what file it represents, whether it is open, and perhaps the contents of the file. ie. Your typical document/view sort of thing. Someone earlier mentioned vehicles (amongst other things) as an example of an object we expect to arrive in a fully constructed state. And this is a good example of what I am talking about here. I DO expect my car to be fully constructed when I get it - but I DONT expect it to be continually in motion, or have the engine running all the time. If I press the accelerator when it is not running then nothing happens. It is a fully constructed object, it is just not very useful until it has been turned on. (cf. MyFileClass when not open. A car does not have to be turned on to exist, a file does not have to be open to exist - it is just that some things are not possible until the object is active.) I may want to engage four wheel drive. I dont mind turning it off while I do it (if I have too), but I dont expect to take the entire car to pieces and reassemble it in four wheel drive mode. (cv. MyFileClass when open for read and want to write.) I have many applications where the same principles apply. The objects have complex relationships and may have many defining or dynamically adjustable attributes. It is not always convenient to destroy and recreate entire sets of objects every time I want to change some aspect of their operation. That is my current take on it. Single phase construction is obviously best where feasible - it keeps everything simpler and clearer. But at this time I can see no alternative but two phase construction (objects with active/inactive state) for some situations. Are there practical alternatives? If so I'd love to hear about them. -- Geoff Worboys Telesis Computing