Re: [Dev-C++] Dev-C++ Users Beware!

[Brian P. <br...@su...>]

Actually, I am told that the full switch is: -ansi -pedantic-errors (but
the person who told me this may simply be a pedant himself:)

I didn't know this even existed.  C99 allowed it in block scope (as
opposed to mint flavored) but that supposedly made the code non-portable
to c++ which brings up two things:
a.  I would hate to be the winner that got to port a huge c project to
c++,
b.  If I had to move a large, real life C++ project from any other
compiler to VC++ I think that the variable array would be the least of
my worries.

In fact, the only reason I can see (at this point) of porting from gnu
to MS...er...O.k., I can't see one.  Oh! Yea, it would be if I had to
use the .NET stuff in VC++ 7.  And anyone who has worked with VC++ .NET
will wonder (as I did) if that can constitute C++ programming at all
since microsoft isn't the king of "embrace and enhance" for nothing.

b--


On Sat, 2002-04-20 at 03:20, Abhijit Shylanath wrote:
> Quote Microsoft: "This isn't a bug, it's a feature." Seriously, though, t=
his is one feature of the GCC compiler (I remember reading about it in the =
DJGPP docs). If you're still looking for the compiler to stop when it encou=
nters non-ANSI code, there must be a command-line options somewhere.  Yup, =
here it is... from the Dev-C++ help file.
>=20
> -------------------------------------------------------------------------=
-------
>=20
> - Support all ANSI C standard programs (compiler parameter : -ansi):
>=20
> This turns off certain features of GNU C that are incompatible with ANSI =
C, such as the asm, inline and typeof keywords, and predefined macros such =
as unix and vax that identify the type of system you are using.  It also en=
ables the undesirable and rarely used ANSI trigraph feature, and it disable=
s recognition of C++ style // comments.
>=20
> -------------------------------------------------------------------------=
-------
>=20
> But what the hell, GCC is kind of a standard in itself.
> mdeth O
> m.o.t.o[P.S.Y.C.H.O]=20
>=20
> http://mudeth.tripod.com | ibr...@bi... | mu...@gm...
> ----- Original Message -----=20
>   From: Bob Wilson=20
>   To: Dev-C++ User Mailing List=20
>   Sent: Saturday, April 20, 2002 3:29 AM
>   Subject: [Dev-C++] Dev-C++ Users Beware!
>=20
>=20
>   David,
>     An array is not dynamic, the value you pass it at initalization must =
be a constat of some sort.if 'i' were to change during the program some wei=
rd voodoo (the program will crash,the world will end,etc.) all this will ha=
pen because it cannot change the size of an array at runtime(reason no. 1 l=
inked lists were created)
>   I am in the process of learning C++, as Ioannis well knows, and a week =
or so ago I was working on the array chapter. In the past I have done most =
of my programming in pascal, and every pascal compiler I have used will not=
 compile an array if the size of the array is a variable, i.e., no dynamic =
arrays. Just fooling around I modified the simple little C++ array program =
to define an array with a variable. I had not done any research but was con=
fident that the compiler would flag an error and bail out.=20
>=20
>   Not So! the program compiled and ran allowing me to change the size of =
the array. I tested the bounds of the program and could build quite large a=
rrays. the size_of function always returnd the correct size of the array. I=
 was really surprised because that it worked. I have not employed the techn=
ique in any real world program, because I felt that it would be much safer =
with pointers and linked lists.=20
>=20
>   Your message above confirmed what I suspected but had not taken the tim=
e to investigate. Stroustrup says:
>     The number of elements of the array, the array bound, must be a const=
ant expresseion (=A7C.5)
>   Paragraph C.5 says in part:
>     A constant expression evaluates to an integral of enumeration constan=
t. Such an expression is composed of literals, enumerators, and const initi=
alized by constant expressions. < . . . > Intuitively, constant expressions=
 are simple expressions that can be evaluated by the compiler before the pr=
ogram is linked and starts to run.
>   That tells me that the compiler should have caught this and bailed out =
rather than compiling, linking, and running this program:=20
>=20
>     #include <iostream.h>
>     #include <stdlib.h>
>=20
>     int main
>     {
>         int arraySize =3D 1;
>         std::cout << "Enter the size of the array: ";
>         std::cin >> arraySize;
>         if (!(arraySize > 0))
>         {
>             system("pause");
>             return 0;
>         }
>         int myArray[arraySize];
>         int arrayLength =3D sizeof(myArray)/sizeof(myArray[0]);
>         for (int i=3D0; i < arrayLength; i++)     // 0 to arrayLength-1
>         {
>             myArray[i] =3D (i + 1) * 2 + 1;
>         }
>         for (int i=3D0; i< arrayLength; i++)     // 0 to arrayLength-1
>         {
>             std::cout << i << ": " << myArray[i] << "\n";
>         }
>        =20
>         system("pause");
>         return 0;
>     }
>   The faulty compiler is the one used by Bloodshed. Visual C++ 6.0 caught=
 the error. That is the second and most serious problem I have found with t=
he compiler used by the dev-c++ environment. It appears it will properly co=
mpile ANSI standard code, but it will also compile code that is clearly out=
side of the standard.=20
>=20
>   I believe that the dev-c++ compiler is the mingw compiler.=20
>=20
>   Regards,
>=20
>   Bob Wilson
>=20