Re: [Mingw-users] Leaving from the mailing list - Synopsis

[Wu Y. <ad...@ne...>]

1) It is you yourself that got confused. People in this mailing list (like
Jerry, Earnie, and others) have told you enough on this subject.

2) It depends on what one thinks more important, better precision or
internal consistency. The MinGW maintainers choose the former when there is
not a perfect answer. Apparently you think differently. It is just one case
that people could think differently from you.

3) You mentioned that the 7-zip issue was the least important. It was. Using
a new format takes time and brings the maintainer more labour. This is a
free world and the maintainer can choose what to do first, of course. And
you have the right to volunteer to do what you like.

I have no regret to see you go. You have made too much noise in this list
for trivial things. You really should learn to know how OTHER people think.

Wu Yongwei

--- Original Message from Ioannis Vranos ---

1) An ANSI C++ compliant compiler is a compiler that compiles ANSI C++
code and whatever other system extensions.

ANSI C++ code is code that compiles to every 100% ANSI C++ compliant
compiler. That is ANSI C++ code is 100% portable code (but which may
have different effects in different machines).

Some compilers provide a "strict ANSI C++ code mode" which is supposed
to allow only ANSI C++ code to get compiled.

GCC provides for this purpose the combination -ansi -pedantic-errors and
the macro __STRICT_ANSI__ to mark non-ANSI C++ code (that is system
extensions, like Win32 API specific header files etc).


An example is conio.h. Consider the code:


#include <conio.h>

int main()
{
 char c=getch();
}


Using default mode:

C:\c>g++ temp.cpp -o temp

C:\c>



Using strict ANSI C++ mode:


C:\c>g++ -ansi -pedantic-errors temp.cpp -o temp
temp.cpp: In function `int main()':
temp.cpp:5: `getch' undeclared (first use this function)
temp.cpp:5: (Each undeclared identifier is reported only once for each
function
it appears in.)


But not all system extensions header files contain the macro
__STRICT_ANSI__ , making this useful mode useless. I asked many times
from the MINGW fellows to add this macro to all the windows-specific
header files but they don't get it. They confuse the ideas of ANSI C++,
Win32 API, ANSI C++ compliance.



2) Some time ago i had discovered that the long double implementation
was completely broken. They were suggesting me for days "simply do not
use long double".

But this is not reasonable. long double is used when we want the maximum
precision in floating point, or to have the type which can store the
largest numbers in portable code.

That is, if i write code for a system, whether it is GNU/Linux, Solaris,
Windows, BeOS, Windows CE and i want to store very large numbers i 'll
use long double (without caring if long double==double in the specific
system).

Finally they fixed it by casting it to double when it is about to be
printed  (i do not know if it is fixed for everything cout, cerr,
fprintf(), etc).


However they did not fix it completely.

I said to them, that the casting only is not enough. The
numeric_limits<>() of <numeric> and long double limits in <float.h>,
<cfloat> must also change to become equal to double (except the
precision stuff). They did not understand. Result:


C++ code:

#include <limits>
#include <iostream>

int main()
{
 using namespace std;

 cout<<"numeric_limits<long double>::max(): ";
 cout<<numeric_limits<long double>::max()<<endl;

}


> Executing: C:\Program Files\ConTEXT\ConExec.exe "g++" -ansi
-pedantic-errors -Wall -fexpensive-optimizations -O3 -ffloat-store
-mcpu=pentiumpro "temp.cpp" -o temp

> Execution finished.


C:\c>temp
numeric_limits<long double>::max(): 1.#INF

[Broken]



VC++ .NET:

> Executing: C:\Program Files\ConTEXT\ConExec.exe "cl" /EHa /Ox /G6 /Za
/nologo /Wp64 "temp.cpp"

temp.cpp

C:\c>temp
numeric_limits<long double>::max(): 1.79769e+308



C code:

#include <float.h>
#include <stdio.h>

int main()
{
 printf("%Lf\n", LDBL_MAX);

 return 0;
}

> Executing: C:\Program Files\ConTEXT\ConExec.exe "gcc" -ansi
-pedantic-errors -Wall -fexpensive-optimizations -O3 -ffloat-store
-mcpu=pentiumpro "temp.c" -o temp

> Execution finished.

C:\c>temp
-1.#QNAN0

[Broken]


This makes MINGW unsuitable for code using long double. If the limits
were equal to those of double (except precision stuff), everything would
work almost as expected with undefined behaviour to overflow, and
truncation to decimal part depth on printing which would be better than
what we have now.



3) And last an issue which is not much important. There is an open
source compression utility named 7-zip, which provides much compression.
It makes the current MINGW distribution smaller than the half current
size (about 5.5 MB). For unknown reasons it is not being used. But this
issue is the less important of all.



So since i report bugs and nothing seems to be fixed, i think there is
no reason to remain in the list. I suggest people consisting the MINGW
development team to read some good up to date C++ book (i am doing it
myself too) and fix the bugs i mentioned.



Keep coding,
Ioannis

* Ioannis Vranos
* Programming pages: http://www.noicys.cjb.net
* Alternative URL: http://run.to/noicys