One last point concerning the non-comformance of compilers with the ARM's
overloading argument matching algorithm.  Linc Madison has suggested in
previous articles that the standard's algorithm is non-intuitive and
should be changed.  I disagree for reasons that have been outlined in
previous postings.

However, Madison cites g++ 2.5.8 as an example of a compiler that
implements the algorithm "correctly".  Although I am not clear on GNU's
selection process...on every 2.5.x compiler (I have not used 2.5.8 yet)
the function selected is very non-deterministic (in my view) with anything
other than an exact match.

ex:
 void identify(short);
 void identify(int);

 int main()
 {
  char c;

  identify(c); /* non-standard calls "short" */
 }

I assume that proponents of Linc Madison's view would have no problem with
this.  However if you switch the order of the declarations, g++ selects
identify(int)!  I would not want GNU's algorithm to be in the future standard.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                                  Mike Whiten

  Think of me a a cross between Slartibartfast & Julia Child.

Michael Whiten (ah657@FreeNet.Carleton.CA) wrote:


: One last point concerning the non-comformance of compilers with the ARM's
: overloading argument matching algorithm.  Linc Madison has suggested in
: previous articles that the standard's algorithm is non-intuitive and
: should be changed.  I disagree for reasons that have been outlined in
: previous postings.

: However, Madison cites g++ 2.5.8 as an example of a compiler that
: implements the algorithm "correctly".  Although I am not clear on GNU's
: selection process...on every 2.5.x compiler (I have not used 2.5.8 yet)
: the function selected is very non-deterministic (in my view) with anything
: other than an exact match.

FWIW, I didn't say that g++ was correct, only that in several specific
instances it is more right than the current standard.  Dependency on
order of declaration is clearly unacceptable.  However, so is equating
the conversion from float to char with the conversion from float to long
double, or the conversion from int to char with the conversion from int
to long int.

The rule set I have proposed is to prefer all promotions as shown in the
diagram on page 41 of the ARM, over all other conversions.  There are a
couple of ambiguities that should still be resolved with this notion.
First, should C-style integer promotions (promote anything smaller than
int to int if it fits or to unsigned int if it doesn't) still be
preferred over shorter promotion hops (e.g., prefer signed char to int
over signed char to short int)?  Second, should a special case be made
to allow promotion of char to signed short/int/long?  (The second
answer is no if there is any actual architecture on which a short is not
strictly larger than a char -- is there any such thing?)

The rules can be made both completely deterministic and much more
intuitive.  There is much to be gained and very, very, very little to be
lost, because, as I have noted, any function call that would be rendered
ambiguous by the change I'm proposing, is an example of extremely poor
programming practice in the first place, and *ought* to be flagged.

-- Linc Madison   *   Oakland, California   *   LincMad@Netcom.com