Re: [Boost-users] Library Interface Design

From: Edward Diener (eldiener_at_[hidden])
Date: 2006-09-13 13:14:43

David Abrahams wrote:
> Edward Diener <eldiener_at_[hidden]> 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.