I hope I summarized your pros and cons correctly here: 1) 'complete' constructors show the user what to do to use the class. 2) 'incomplete' constructors are easier to use, because they incur less (so-called) overhead.
I've slept soundly with this philosophy for many years, but lately I've noticed that this idea runs headlong into one of the ideas of testability: that classes should be easy to test in isolation. The above constructor requires that an ostream be set up before an EventLog can be tested, and this might (1) be a pain and (2) be irrelevant for whatever test I want to perform. In such cases, offering a default constructor in addition to the above would make the class potentially easier to test. (In the general case, there might be many parameters, and they might themselves be hard to instantiate for a test due to required parameters that their constructors require....)
3) Because of 2 and because (many) of the arguments are 'irrelevant', 'incomplete' constructors are easier in testing, because you get your test-object faster. 4) 'incomplete' constructors are easier when exploring classes. 5) .NET Framework designers know what they're doing. My oppinion is that 'complete' constructors are better then 'incomplete'. I read that most of you feel the same. I also am a big fan of having sufficient overloads to instantiate a class from different perspectives (ie with different arguments). Usually a constructor with many default arguments works very convenient for me. A constructor should only set what is required to get the desired behaviour. Therefore, there *is* no overhead: all arguments are NECESSARY if not, additional constructor overloads can be created. This makes items 2 and 3 IMHO less important. The use of interfaces may greately ease the construction of test-stubs. In C++, I of course mean multiple inheritance with abstract 'interface' base-classes. As for Item 1, I believe that it's very important to tell the user of a class what is expected of the user and what the class provides. One can do this in comments (XML comments in .NET are great for that, I think), but if given the choice I prefer 'self-documenting' compilable code, like argument names and types. I'm not going to comment on item 5 :-) In short, I think the advantages of 'complete' constructors outweigh the disadvantages and the disadvantages can be reduced by proper design and interfaces. my 2 cents, agb