2010/1/11 Warren Young:
> On 1/11/2010 5:51 AM, Jonathan Wakely wrote:
>> There's no need to make the default constructor private. Declaring any
>> other user-defined constructor disables the implicit generation of a
>> default constructor.
> True, but declaring it gives us a place to hang a comment saying why we did
> it that way. It also tells anyone tempted to add one in the future why they
> shouldn't do that.
If a comment is needed it could still be there, just not attached to
the private declaration. The class definition is short enough that it
almost fits on one screen so anyone trying to add a default ctor would
have no excuse for missing the comment!
>> Making it private means attempting to use it
>> will give a "constructor is private" error rather than a "no such
>> constructor" error. Personally I think the latter is preferable so I
>> would remove the declaration of the private default constructor.
> This is reasonable, too.
> So, how to resolve the tension? Can we expect people to understand why
> something is non-existent and be content with that? It seems to be human
> nature to invent all kinds of crazy things to fill in the places where
> non-existent things ought to be. >:)
Heh - true :-)
However, anyone who tried to write a default ctor would have to figure
out what to initialise the ConnectionPool& member to (references
cannot be uninit'd or default-init'd) and that might make them pause
for thought, and stop them from doing it.
But I'm certainly not going to lose sleep over it if the private decl
goes back in.