Re: Problem with linker

Tech-Archive recommends: Speed Up your PC by fixing your registry

In fact, I agree that the it is the result of "carelessness", but the correct way to
handle it in C# would be
Something();
Something(string);
Something(int);
so I believe the correct solution was not to add a default parameter to the constructor,
but to have actually written a default constructor.

Note that if it was
Something();
Something(LPCTSTR);
Something(int);
then we still have an abiguity problem if someone calls
Something(NULL);

My own preference to avoid this is to declare them as
Something();
Something(const CString & s);
Something(int);

so it is impossible to write Something(NULL); the programmer is forced to write
Something() to get a default parameter.

This often arises when the correct breakdown should have been
Something() { Init(NULL); }
Something(LPCTSTR p) { Init(p); }
Something(int n)
where I could consider implementations such as
{ CString s; s.Format(_T("%d"), n); Init(s); }
or
{ Init(n); }
given that I define functions
protected:
void Init(LPCTSTR);
void Init(int);

Either of the above would be better alternatives to using default parameters. The issue
here is a reluctance to refactor code; default parameters make it easy to reuse the
existing code instead of adding another function to handle the indrection, and since
adding code is Always A Bad Thing (an attitude that sets my teeth on edge, and I think is
the result of poor education), the quick & dirty hack is to add a default parameter.
joe

On Thu, 07 Jun 2007 13:02:34 -0500, "Doug Harrison [MVP]" <dsh@xxxxxxxx> wrote:

On Thu, 07 Jun 2007 15:08:09 GMT, MrAsm <mrasm@xxxxxxx> wrote:

On Thu, 07 Jun 2007 10:48:42 -0400, Joseph M. Newcomer
<newcomer@xxxxxxxxxxxx> wrote:

Default parameters introduce all kinds of problems, especially when overloading comes into
play. Suppose I have

class Someting {
public:
Something(LPCTSTR = NULL);
Something(int);
}

you would think there is no problem, but Something() is ambiguous.

It's not default arguments per se that cause problems. A function
declaration that uses default arguments can always be decomposed into a set
of function declarations that do not. Ambiguities arise with carelessly
designed overloading, such as overloading on int and pointer types. That's
the real mistake in the example. (More below.)

I don't agree. I think you are wrong here, IMHO.
Something() is *not* ambigous, because you have not defined a default
constructor.

Because it can be invoked with no arguments, this is a default ctor:

Something(LPCTSTR = NULL);

Note that the following are fine:

Something x;
Something y(0); // Chooses Something(int) though!

The problem is with:

Something z(0L);

Actually, VC8 passes that, which is a bug in VC8. I just entered a bug
report on this:

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=281889

If I write:

Something z((unsigned) 0);

Then I get the expected C2668. (NB: It is the function call that is
"ambiguous" due to the failure of overload resolution to find a single best
match; the set of function declarations simply is what it is. It may
contain duplicates and thus cause function calls to be ambiguous, but I
wouldn't say the set of function declarations itself is ambiguous.)
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.