Re: [Boost-users] Library Interface Design

David Abrahams wrote:

Edward Diener writes:

...

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.

That's really .Net's default null-initialization of references, since C++/CLI plays by the .Net rules. Most .Net objects aren't half-baked objects to use, but they are objects which are created with a default constructor, which gives people the idea that they are not ready to use. They rely quite a bit on properties being set in order to use, and those properties are set via the design-time interface in Visual Studio, which then injects code in the default constructor to set the properties. So while it looks like these objects are not ready to use, they really are. This is an instance where programmers who are not cognizant of a particular technology jump to conclusions which are not true based on a similar technology which behaves differently. Standard C++ does not have a design-time interface which sets private data members from within a constructor, the equivalent of .Net's properties, so it appears to standard C++ programmers that the .Net default constructor, which is the common case, creates objects which are not ready to use whereas this is not the situation at all. In my initial response in this thread I may not have been clear about how .Net works, but I did say that the .Net default constructor methodology is not indicative of the issue discussed, where the OP thought it might be a good idea not to have his objects ready to use immediately upon construction and thought that the .Net default constructors were an indication of that case.

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.

See above vis-a-vis properties being set in the constructor buy the .Net visual designer interface.