Re: Negative float problem

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Dave Thompson <david.thompson1@worldnet.att.net> writes:

> On 01 Nov 2005 19:28:34 -0500, Robert A Duff
> <bobduff@shell01.TheWorld.com> wrote:
> <snip>
> > Right.  That was my point: functions do not overload on their return
> > type in C++.
> > 
> That's true.
> 
> > It's the same reason why you have to put an annoying "L" at the end of a
> > "long int" literal in C++.  That's a kludge, and it wouldn't work at all
> > in Ada, which has many integer types.  Have I got that right?
> > 
> No and no.

Not sure what's "No".  Certainly it's a kludge, and certainly it
wouldn't work in Ada, since there are an unbounded number of
integer types.

> First, you don't always need a suffix L (or LL for long long in C99).

OK.  So you need it exactly when you can't tell the appropriate type of
the literal by looking at the literal itself.  E.g., in your 1000*1000
example, below -- you have to add an "L" to get the right answer.

> Literals have specific types in C and C++ (i.e. no Universal_Integer)
> and a decimal literal unsuffixed has the smallest signed integer type
> capable of representing it. On a system with 16-bit int, 1000000 is
> long int. Where you do need it (or alternatively a cast) is:
> 
> - when passed as argument (actual) to a function declared without a
> prototype (obsolete and bad style since 89 but still allowed), or as a
> variable argument e.g.: printf ("%ld", 3L /* not just 3 */);
> 
> - when used in certain (arithmetic) expressions:
>   1000 /* always int */ * 1000 /* ditto */
> on system with 16-bit int is computed in 16 bits (not promoted) and
> overflows, can't produce correct result and may go undiagnosed
>   1000L * 1000 /* promoted to long, computed in long, safe */
> 
> You do more often need a suffix U (or cast) for unsigned -- but not
> always; octal and hexadecimal (but not decimal) unsuffixed literals of
> certain sizes are automatically unsigned. And signed ones are silently
> and losslessly converted if they meet unsigned in an expression. 
> 
> You might write suffixes even where not required, for documentation.
> Just as I might 'use Foo.Bar' and still write Foo.Bar.X or Bar.X
> instead of just X.

Yes.  Perhaps a better analogy would be saying "My_Integer'(X)" instead
of just "X".

> Second, this still has nothing to do with overloading on return type.

It has a lot to do with overloading on return type.  The point is
whether overload resolution uses context to determine the type of an
expression result -- that could be the result of a function call, the
result of a literal, or various other things, depending on the
language.

> A numeric literal is not a function, not even in Ada. 

It doesn't matter that literals are not functions.  As far as the design
of overload resolution goes, they are analogous.

>...It can be an
> argument, and matching and conversion of actual arguments to formal
> parameters of possible overloads in C++ is basically similar to Ada.

No, C++ and Ada are completely different in this regard: In C++, the
literal itself determines its type (the value, plus the presence of
"L"), as you explained above.  In Ada, the _context_ determines the type
of the literal.  This is analogous to the function-call case:
In C++, the innards of the function call determine which function is
called, and therefore, its type.  In Ada, the context is used
(in addition to the innards).

Example:

    function F return Integer;
    function F return Boolean;
    procedure P(X: Integer);

    P(F*F); -- (1)

    type Int is range -2**15 .. 2**15-1;
    type Long is range -2**31 .. 2**31-1;
    procedure Q(X: Long);

    Q(1000*1000); -- (2)

In Ada, the F's at (1) are the Integer one, and the 1000's at (2) are of
type Long.  If we translate to C++, I believe (1) is a compile-time
error, and (2) gets the wrong answer.

- Bob