From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,9ce095aba33fe8d0 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newscon06.news.prodigy.com!prodigy.net!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Negative float problem Date: 19 Nov 2005 19:19:32 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <10mspnley7gzu$.1swtj67sv0ldr$.dlg@40tude.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1132445972 31070 192.74.137.71 (20 Nov 2005 00:19:32 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Sun, 20 Nov 2005 00:19:32 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:6492 Date: 2005-11-19T19:19:32-05:00 List-Id: Dave Thompson writes: > On 01 Nov 2005 19:28:34 -0500, Robert A Duff > wrote: > > > 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