Re: Ada or C++ acting 'correctly' here?

Re: Ada or C++ acting 'correctly' here?

[Matthew Heaney]

bill@mooner writes:

> compare these 2 little programs, do same thing, one in C++
> and one in Ada. The C++ program compiles Ok, but result is
> negative, the Ada program refused to compile:

...

> test_multi.adb:6:18: value not in range of type "Standard.Integer"
> test_multi.adb:6:18: static expression raises "Constraint_Error"

...

> Now. Which would you consider the correct language behaviour?
> (same machine, Pentium pro, Linux.


You may be comparing apples and oranges.

I you want to duplicate the C++, then use a modular type.  Instantiate
Text_IO.Modular_IO on Interfaces.Unsigned_32, and then compare results.
(Print out the values in hex.)

The other thing you could try is to create a non-static value in the Ada
program, and then be sure to compare with overflow checks off (the
default in gnat).  This would be closer to the C++ program.

The fact that the Ada code refuses to compile, you should regard as a
Good Thing, since it doesn't make any sense to try to print out an
unrepresentable value.

Re: Ada or C++ acting 'correctly' here?

[Steve Doiel]

>Now. Which would you consider the correct language behaviour?
>(same machine, Pentium pro, Linux.
>

Both are giving the correct language behavior.  For their language.

The nature of C/C++ is to not notify you of overflows or suprises in
calculations.

The nature of Ada is to let you know when suprises occur.

Your example is a good example of why I prefer Ada.

Here's another.  Consider the following C++ program

#include <iostream.h>

void main()
{
  int value = -4;
  unsigned divisor = 2;

  cout << value / divisor << endl;
}

Output:
  214748364

And here's it's Ada Counterpart:

WITH Ada.Integer_Text_Io;
WITH Ada.Text_Io;
WITH Interfaces; USE Interfaces;
PROCEDURE Demo IS
  value   : Integer_32 := -4;
  divisor : Unsigned_32 := 2;
BEGIN
  Ada.Integer_Text_Io.Put( value / divisor );
  Ada.Text_Io.New_Line;
END Demo;

Which gives a compile error:
  demo.adb:8:34: invalid operand types for operator "/"
  demo.adb:8:34: left operand has type "Interfaces.Integer_32"
  demo.adb:8:34: right operand has type "Interfaces.Unsigned_32"
  gnatmake: "demo.adb" compilation error

The C++ program is more than happy to give you the wrong answer (as it must
in accordance with the language standard).  But the Ada compiler tells you
you're doing something silly.

BTW: I ran into this bug in a C program that was calculating an average
where the sum was an integer and the count was unsigned.

SteveD

Re: Ada or C++ acting 'correctly' here?

[Gautier.DeMontmollin]

> compare these 2 little programs, do same thing, one in C++
> and one in Ada. The C++ program compiles Ok, but result is
> negative, the Ada program refused to compile:

(...)
> {
>   cout<<(500000000*7);
>   return 0;
> }

(...)
>   begin
>    Put( 500000000*7 );
>   end Test_Multi;

(...)
> Now. Which would you consider the correct language behaviour?
> (same machine, Pentium pro, Linux.

This could be a bright example of how a strong-typed language
helps you finding errors already at compile time (here: a 32-bit
overflow). If accepted by the compiler, such a bug, lost in a large
program, could take days to locate! 

-- 
Gautier

Re: Ada or C++ acting 'correctly' here?

[Claudius Proculus]

In article <7b8c7u$sj1@drn.newsguy.com>, bill@mooner wrote:
>Hello,
>
>compare these 2 little programs, do same thing, one in C++
>and one in Ada. The C++ program compiles Ok, but result is
>negative, the Ada program refused to compile:
>
>
>----------------------------
>#include <iostream>
>int main()
>{
>  cout<<(500000000*7);
>  return 0;
>}
>-----------------------------
>%g++ -Wall test_mult.cc
>%./a.out
>-794967296
>
>(this is g++ 2.8.1)
>
>----------------------------
>with Ada.Integer_Text_Io; use Ada.Integer_Text_Io;
>procedure Test_Multi is
>  begin
>   Put( 500000000*7 );
>  end Test_Multi;
>-----------------------------
>$gnatmake test_multi.adb
>gcc -c test_multi.adb
>test_multi.adb:6:18: value not in range of type "Standard.Integer"
>test_multi.adb:6:18: static expression raises "Constraint_Error"
>gnatmake: "test_multi.adb" compilation error
>
>
>Now. Which would you consider the correct language behaviour?
>(same machine, Pentium pro, Linux.

They are both the correct behavior.

However, this does illustrate one of the benefits of using Ada.

John - N8086N 
Wise man says "Never use a bank with the initials F. U."
----------------------------------------- Matloff --
Are you interested in a professional society or
guild for programmers?

See www.programmersguild.org/american.htm
Newsgroup: us.issues.occupations.computer-programmers

EMail Address:
_m-i-a-n-o_@_c_o_l_o_s_s_e_u_m_b_u_i_l_d_e_r_s._c_o_m_

Re: Ada or C++ acting 'correctly' here?

[Biju Thomas]

Claudius Proculus wrote:
> 
> In article <7b8c7u$sj1@drn.newsguy.com>, bill@mooner wrote:
> >compare these 2 little programs, do same thing, one in C++
> >and one in Ada. The C++ program compiles Ok, but result is
> >negative, the Ada program refused to compile:
> >
> >
> >----------------------------
> >#include <iostream>
> >int main()
> >{
> >  cout<<(500000000*7);
> >  return 0;
> >}
> >-----------------------------
> >%g++ -Wall test_mult.cc
> >%./a.out
> >-794967296
> >
> >(this is g++ 2.8.1)
> >
> 
> They are both the correct behavior.
> 

No. The C++ compiler is non-conforming. The C++ standard says that if a
constant expression cannot be represented in the target type, the
program is ill-formed. (Chapter 5, paragraph 5.) A C++ compiler is
required to issue a diagnostic message while compiling an ill-formed
program. (It is *not* an undefined behaviour.)

> However, this does illustrate one of the benefits of using Ada.
 
Ada certainly will have benefits, but not on this one.

-- 
Best regards,
Biju Thomas

Ada or C++ acting 'correctly' here?

[bill]

Hello,

compare these 2 little programs, do same thing, one in C++
and one in Ada. The C++ program compiles Ok, but result is
negative, the Ada program refused to compile:


----------------------------
#include <iostream>
int main()
{
  cout<<(500000000*7);
  return 0;
}
-----------------------------
%g++ -Wall test_mult.cc
%./a.out
-794967296

(this is g++ 2.8.1)

----------------------------
with Ada.Integer_Text_Io; use Ada.Integer_Text_Io;
procedure Test_Multi is
  begin
   Put( 500000000*7 );
  end Test_Multi;
-----------------------------
$gnatmake test_multi.adb
gcc -c test_multi.adb
test_multi.adb:6:18: value not in range of type "Standard.Integer"
test_multi.adb:6:18: static expression raises "Constraint_Error"
gnatmake: "test_multi.adb" compilation error


Now. Which would you consider the correct language behaviour?
(same machine, Pentium pro, Linux.

Bill.

Re: Ada or C++ acting 'correctly' here?

[Florian Weimer]

bill@mooner writes:

> ----------------------------
> #include <iostream>
> int main()
> {
>   cout<<(500000000*7);
>   return 0;
> }
> -----------------------------

Quotation from ISO/IEC 14882:1998(E), Chapter 5 (Expressions):

|  5 If during the evaluation of an expression, the result is not
|    mathematically defined or not in the range of representable values
|    for its type, the behavior is undefined, unless such an expression is
|    a constant expression (5.19), in which case the program is ill-formed.

The standard doesn't mention that no diagnonstic is required, so
conforming implementations have to refuse to compile this program.

> ----------------------------
> with Ada.Integer_Text_Io; use Ada.Integer_Text_Io;
> procedure Test_Multi is
>   begin
>    Put( 500000000*7 );
>   end Test_Multi;
> -----------------------------

Quotation from ISO/IEC 8652:1995(E), Section 4.9 (Static Expressions
and Static Subtypes):

| 33 A static expression is evaluated at compile time except when it is
|    part of the right operand of a static short-circuit control form whose
|    value is determined by its left operand.  This evaluation is performed
|    exactly, without performing Overflow_Checks.  For a static expression
|    that is evaluated:
|     
|        34  The expression is illegal if its evaluation fails a
|            language-defined check other than Overflow_Check.

Again, conforming compilers must refuse to compile this program.

(BTW: It's pretty pointless to compare languages this way, isn't it?)

Re: Ada or C++ acting 'correctly' here?

[robert_dewar]

In article <7b8c7u$sj1@drn.newsguy.com>,
  bill@mooner wrote:
> Hello,
>
> compare these 2 little programs, do same thing, one in
> C++ and one in Ada. The C++ program compiles Ok, but
> result is negative,

Reasonable, since the C++ program is legal, but has
undefined semantics.


> the Ada program refused to compile:

Reasonable, since this is clearly an illegal program, and
the error messages you got from GNAT were pretty clear as
far as I can see!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada or C++ acting 'correctly' here?

[robert_dewar]

In article <36D85A54.2A0E6283@ibm.net>,
  bijuthom@ibm.net wrote:
> No. The C++ compiler is non-conforming. The C++ standard
> says that if a constant expression cannot be represented
> in the target type, the program is ill-formed. (Chapter
> 5, paragraph 5.) A C++ compiler is required to issue a
> diagnostic message while compiling an ill-formed
> program. (It is *not* an undefined behaviour.)

Interesting, this is new to me, is this something that
has been in informal C++ definitions from the start, or
was it something added for the ISO standard?

By the way, I still think this shows an advantage of
Ada, one cannot imagine bumping into a non-conforming
Ada 95 compiler that would not reject the Ada example
here. I suspect the C++ situation is precisely an
indication of the fact that C++ compilers are not
yet generally fully conforming with the ISO standard.


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada or C++ acting 'correctly' here?

[William McKenzie]

With -W3, always a good idea, microsoft will give you an 'integral constant
overflow' message on the expression.  With -WX -W3 you could even say it
behaves as well as the ADA compiler.

Cheers, Bill
--
William McKenzie
CarteWright, Inc.
w_s_m@g5.com
bill@mooner wrote in message <7b8c7u$sj1@drn.newsguy.com>...
>Hello,
>
>compare these 2 little programs, do same thing, one in C++
>and one in Ada. The C++ program compiles Ok, but result is
>negative, the Ada program refused to compile:

Re: Ada or C++ acting 'correctly' here?

[Florian Weimer]

robert_dewar@my-dejanews.com writes:

> In article <36D85A54.2A0E6283@ibm.net>,
>   bijuthom@ibm.net wrote:
> > No. The C++ compiler is non-conforming. The C++ standard
> > says that if a constant expression cannot be represented
> > in the target type, the program is ill-formed. (Chapter
> > 5, paragraph 5.) A C++ compiler is required to issue a
> > diagnostic message while compiling an ill-formed
> > program. (It is *not* an undefined behaviour.)
> 
> Interesting, this is new to me, is this something that
> has been in informal C++ definitions from the start, or
> was it something added for the ISO standard?

In Stroustroup's `The C++ programming language', second edition (1991),
there is no distinction between compile-time and run-time evaluation.
Integer overflow (on both occasions) results in undefined behaviour.

> By the way, I still think this shows an advantage of
> Ada, one cannot imagine bumping into a non-conforming
> Ada 95 compiler that would not reject the Ada example
> here. I suspect the C++ situation is precisely an
> indication of the fact that C++ compilers are not
> yet generally fully conforming with the ISO standard.

This is really a problem.  Some vendors seem to be completely
uninterested in making their compiler conforming with the standard.
For example, one vendor's compiler has an option to enable the new
scoping rules on loop counter variables (which completely make sense
and are already widely used), but the header files provided by the same
vendor can't be used if that switch is turned on. :-/

Re: Ada or C++ acting 'correctly' here?

[Hubert B. Keller]

William McKenzie wrote:

> With -W3, always a good idea, microsoft will give you an 'integral constant
> overflow' message on the expression.  With -WX -W3 you could even say it
> behaves as well as the ADA compiler.
>

Is it a question of defined semantics of programming language constructs or
more
a question of compiler statements and how can i decide how a program was
compiled and behaves using it later as an existing module (and searching for
errors)?
I believe it should be a question of clearly defined semantics - so i'm using
Ada.
H. Keller

Re: Ada or C++ acting 'correctly' here?

[fraser]

I nearly cried when w_s_m@g5.com said:

>With -W3, always a good idea, microsoft will give you an 'integral constant
>overflow' message on the expression.  With -WX -W3 you could even say it
>behaves as well as the ADA compiler.

Until you replace the constants with a couple of variables, which will
send you off into hyperspace without a speck of complaint.

Mind you, this is only one amongst many reasons to choose Ada (ADA being
the American Dental Association or something, which you can choose as
well, but I'm not qualified to comment on that).

Fraser.

Re: Ada or C++ acting 'correctly' here?

[dewar]

In article
<m3678mdit2.fsf@deneb.cygnus.stuttgart.netsurf.de>,
  Florian Weimer <fw@cygnus.stuttgart.netsurf.de> wrote:
> robert_dewar@my-dejanews.com writes:
> This is really a problem.  Some vendors seem to be
> completely uninterested in making their compiler
> conforming with the standard.

Vendors respond to market demand, so what you are really
saying here is that the C++ applications world does not
strongly demand ISO compliance at this stage. After all,
there is no external requirement for an Ada compiler to
conform to the Ada standard. It is merely that the Ada
applications market insists on such conformance, and
vendors respond to this insistance!

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada or C++ acting 'correctly' here?

[kvisko]

In article <qH8mEcCfxEsj@nedcu4>, Gautier.DeMontmollin@maths.unine.ch says...
>
>"Willliam V" <nospam@nospam.com> writes:
>
>> 500000000*7 is a negative quantity.
>
>Wow! A new axiom in mathematics!!
>

i did not laugh so much for a long time :)

i think William V be must the new Gauss, comming up with new Mathematics
where 500000000*7 is negative.  Think of all the possibilites this can
bring! 

kvisko

Re: Ada or C++ acting 'correctly' here?

[robert_dewar]

In article <7bg0pc$5a4$1@ffx2nh3.news.uu.net>,
  "Willliam V" <nospam@nospam.com> wrote:
> So the Ada compiler you are using is
> relying very heavily on the underlying C machinery. Don't
> be too fast to blame C or C++
> Wil

This is most certainly completely wrong, but it is hard
to understand the misconception that leads to this
incorrect statement, so it is hard to comment in any
detail!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada or C++ acting 'correctly' here?

[Pascal Obry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 936 bytes --]


Willliam V a �crit dans le message <7bg0pc$5a4$1@ffx2nh3.news.uu.net>...
>500000000*7 is a negative quantity.  C++ prints out
>what you ask it to do.
>try unsigned long l = 500000000*7;
>cout << l;
>or even
>cout << ((unsigned long )500000000)*7);
>If Linux 'd make the unsigned long to be 64 bit, you Ada would
>have compiled fine. So the Ada compiler you are using is
>relying very heavily on the underlying C machinery. Don't be
>too fast to blame C or C++


Certainly not. What does it means anyway that "your Ada compiler is
relying on the underlying C machinery" ????

It is just that the Ada compiler rely on the underlying architecture, how
could it be otherwise anyway !

The 32 bits or 64 bits attributes are coming from the architecture not
from the C compiler. So the only thing we know now is that a machine
word (in this example) is 32 bits.

And now again, Ada pay attention to that but C/C++ does not.

Pascal.

Re: Ada or C++ acting 'correctly' here?

[SpamSpamSpam]

The logic of a C/C++ programmer a little too close to his bits and
bobs......

Willliam V wrote:

> 500000000*7 is a negative quantity.

Re: Ada or C++ acting 'correctly' here?

[Gautier.DeMontmollin]

"Willliam V" <nospam@nospam.com> writes:

> 500000000*7 is a negative quantity.

Wow! A new axiom in mathematics!!

> C++ prints out
> what you ask it to do.

Absolutely - it does the modulo 2^32 and returns a signed value.

> try unsigned long l = 500000000*7;
> cout << l;
> or even
> cout << ((unsigned long )500000000)*7);

BTW: shouldn't the output be *unsigned* (modulo 2^32) ?!

> If Linux 'd make the unsigned long to be 64 bit, you Ada would
> have compiled fine.

The standard integer would be 64 bit - but the "problem" would
come again with 2^62 * 7...

> So the Ada compiler you are using is
> relying very heavily on the underlying C machinery.

Not that much, since the Ada compiler *did* detect the overflow
- as it should !

> Don't be
> too fast to blame C or C++

It was a question about languages behaviours...
Did someone blame C/C++ ?

-- 
Gautier

--------
Homepage: http://www.unine.ch/math/Personnel/Assistants/Gautier/Montmollin.html
Software: http://www.unine.ch/math/Personnel/Assistants/Gautier/Gaut_FTP.htm

Re: Ada or C++ acting 'correctly' here?

[Willliam V]

500000000*7 is a negative quantity.  C++ prints out
what you ask it to do.
try unsigned long l = 500000000*7;
cout << l;
or even
cout << ((unsigned long )500000000)*7);
If Linux 'd make the unsigned long to be 64 bit, you Ada would
have compiled fine. So the Ada compiler you are using is
relying very heavily on the underlying C machinery. Don't be
too fast to blame C or C++
Wil

bill@mooner wrote in message <7b8c7u$sj1@drn.newsguy.com>...
>Hello,
>
>compare these 2 little programs, do same thing, one in C++
>and one in Ada. The C++ program compiles Ok, but result is
>negative, the Ada program refused to compile:
>
>
>----------------------------
>#include <iostream>
>int main()
>{
>  cout<<(500000000*7);
>  return 0;
>}
>-----------------------------
>%g++ -Wall test_mult.cc
>%./a.out
>-794967296
>
>(this is g++ 2.8.1)
>
>----------------------------
>with Ada.Integer_Text_Io; use Ada.Integer_Text_Io;
>procedure Test_Multi is
>  begin
>   Put( 500000000*7 );
>  end Test_Multi;
>-----------------------------
>$gnatmake test_multi.adb
>gcc -c test_multi.adb
>test_multi.adb:6:18: value not in range of type "Standard.Integer"
>test_multi.adb:6:18: static expression raises "Constraint_Error"
>gnatmake: "test_multi.adb" compilation error
>
>
>Now. Which would you consider the correct language behaviour?
>(same machine, Pentium pro, Linux.
>
>Bill.

Re: Ada or C++ acting 'correctly' here?

[bglbv]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]

> > >   cout<<(500000000*7);

> > Quotation from ISO/IEC 14882:1998(E), Chapter 5 (Expressions):

> > |  5 If during the evaluation of an expression, the result is not
> > |    mathematically defined or not in the range of representable values
> > |    for its type, the behavior is undefined, unless such an expression is
> > |    a constant expression (5.19), in which case the program is ill-formed.

> > The standard doesn't mention that no diagnonstic is required, so
> > conforming implementations have to refuse to compile this program.

> The standard does not have to mention that no diagnostic is required
> if undefined behavior is involved.  A diagnostic is never required for
> undefined behavior.  Among other things, requiring a diagnostic would
> be defining a behavior.

The point here is that (500000000*7) is a constant expression (would
someone who has read �5.19 please confirm this?) and the program is
therefore ill-formed. The wording of the passage quoted above
contrasts this situation with the more general case where the behavior
is undefined; one is therefore tempted to read it as meaning that a
diagnostic *is* required in this particular case.