Re: default values - the good, the bad and the ugly

From: lilburne (lilburne_at_godzilla.net)
Date: 11/04/03 

Date: Tue, 04 Nov 2003 20:42:14 +0000

Dan Cernat wrote:
> lilburne <lilburne@godzilla.com> wrote in message news:<bo8bvq$1a5bg1$1@ID-179504.news.uni-berlin.de>...
>
>>
>>Now I'm not bitter but if the diseased brain that originated this hadn't
>>been able to apply the default argument trick, this god awful fucked up
>>nondesign could have been halted at its *** conception.
>
>
> The thing is that in your tale, they didn't change only a constructor
> (to have some default parameter values), they changed the class
> entirely, I mean, they gave a new meanning for the entire class. That
> is bad design. They should have had two classes derived from a common
> one (that doesn't care about open or closed regions) - I'm sure you
> know what I am talking about.

That is exactly the point. The class was turned into two
classes, and the thing that made it possible was the
seductive application of a default parameter. This is an
extreme case of bolting on a flag to something that already
exists. In most cases you end up with a method that behaves
differently depending on whether an argument is supplied or not.

> Having a new constructor with the additional parameter would have
> helped? No. Someone could have passed the same object (open
> region)(correctly constructed this time) to the function that expected
> a closed region.

Well by the time that the horror blew up lots of code had
been written that was compromised. The act of forcing
everyone to construct the class with a flag like:

    Region open(wartOPEN);
    Region closed(wartCLOSED);

would have alerted people glancing at the code to the fact
that something smelly was going on. As it was those that
worked primarily with closed 'regions' had little awareness
that the class had been compromised.

The headers of methods that assumed 'closed' regions hadn't
been updated to say "don't call this with open segements".
What the default parameter did was sweep the issue under the
carpet for a number of months, because the originated hadn't
had to raise an API change, it had managed to sneaked past
critical scutiny.

>>
>>Compiler fuckups:
>>
>>I have a piece of code that looks like this
>>
>> int i = get_int();
>>
>> myArchiveWriter >> i;
>>
>>and an old SPARC compiler that upon seeing
>>
>>class someClass {
>>public:
>> someClass(double d, int size = 0);
>>};
>>
>>thinks that:
>>
>>myArchiveWriter& operator>>(myArchiveWriter&, someClass& c);
>>
>>is the best match.
>
>
> My Turbo C 2.0 doesn't know about templates ergo, templates are bad.
> C'mon, let's move forward, change the compiler or don't use the
> language's feature if you don't like it. BTW I never used goto in any
> of my programs. Should it be removed from language?
>

The point of this is not that the SPARC compiler gets it
wrong (spectacular as it is) but that you have a class that
can be constructed with a single parameter of inbuilt type.
You ought to also be suspicious of the default argument,
which was bolted on at a later date, again to avoid an API
change. In the specific case the someClass is a container of
geometric curves, 'd' is the c0 continuous tolerance between
adjacent curves, and 'size' the initial capacity of the
container. The container allocates more space as its size
increases.

Now what happens if you don't supply a size? Well as curves
are added the internal buffer resizes, which has a
performance hit, and can result in memory fragmentation. To
avoid having to resize all the time extra slots are
reserved. If this was implemented in terms of std::vector
the capacity reserved would be double the last size. Whilst
you hardly ever want an initial capacity of zero the default
argument encourages its use.

Like a goto, sometimes a well designed default argument will
makes sense (though I've yet to encounter an example). Using
them to avoid an API change, or to make one function look
like 2 or more simply to save clients from typing a few
extra characters, will bite you over time.