Edward Diener
Johan Nilsson wrote:
and seem to contradict the advice of the designers of the .NET API.
Different platform and philosophy, unless you're talking about C++/CLI.
C++/CLI is not an exception. C++/CLI follows the .Net philosophy and rules regarding the construction of objects, not the C++ philosophy and rules, as I pointed out in another post on this thread. Because of that it is not necessarily apropos to use .Net as a basis for discussion of constructor philosophy in C++, although .Net's reliance on properties and events does have an anology to work that has been done with C++ lately, and does affect how one thinks about constructing and using objects.
C++/CLI's default null-initialization of references doesn't in any way justify designs that pass out half-baked objects to users, any more than we would approve of passing out half-baked objects containing only shared_ptr<>s in C++. It's bad design. It makes the client of a class responsible for things that the class designer should have taken care of. That's a universal no-no, regardless of what language the code is written in. Default null-initialization of references does make it easier to not think about certain exception-safety and object state issues and "get away with it" some of the time, but that doesn't make code written that way correct. Usually, it just means that bugs may be masked or harder to detect. -- Dave Abrahams Boost Consulting www.boost-consulting.com