From: Ioannis V. <no...@ho...> - 2002-09-11 20:47:26
|
> -----Original Message----- > From: Paul Schmidt [mailto:pa...@tr...] > Sent: Wednesday, September 11, 2002 7:29 PM > To: Ioannis Vranos; MinGW Users Mailing List > Subject: Re: [Mingw-users] Leaving from the mailing list - Synopsis > > > > Sent to Ioannis, copy to the list FYI > > On 11 Sep 2002 at 8:12, Ioannis Vranos wrote: > > > 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. > > > > So, what stopped you? YOU could have easily taken the > windows header files, > added the __STRICT_ANSI__ flag to it, and then submitted a > patch, I am sure the > maintainers would have been happy to accept your patch, and > even give you credit > for it. I do not think so. Rather i got the impression that they do not understand (they confuse the notion of ANSI C++ code which is the core language and 100% portable, Win32 extensions, and ANSI C++ compliance). If they had said, "ok do it and send us the result" i would have done it. But unfortunately they simply do not get it. > Like most people you find it easier to whine and > complain that someone else, > fix it for you, the gcc maintainers and the mingw maintainers > are volunteers, > typically people who take time from their busy schedules to > work on this, it's tough > to work all day, and then spend your off hours working on > this stuff. Now you are kidding right? They never said "ok do it". > > 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: > > > > Again, what stopped you from fixing it and submitting a > patch? I know, it's easier to > whine and complain, that someone else isn't working hard > enough, then it is to pick > up part of the load and help. I wouldn't write code that would end in the trash bin. They never agreed with it. Have you seen any agreement on these topics from the development team? So why do you ask me such things? > > <snip> > > > 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. > > There could be a number of reasons, > > Probably the most important ones > > 1) The software and format have not yet stabilized, so future > betas could render the > current 7-zip files unusable. I have already answered to this problems. The self-extracting archive does not have this problem (also the current distribution is an .exe too). > 2) It's only available for Windows, so far, and some mingw > components are used > with non-windows environments (In cross compiling mode). So > they must be > available from those environments. But MINGW 2.0.0 comes in a win32 exe. > 3) Some people don't use beta software in production environments. > 4) It doesn't have a CLI version, so it's can't be used from > a script file. I do not know about script files but i do not think the current exe is also scriptable. Ioannis * Ioannis Vranos * Programming pages: http://www.noicys.cjb.net * Alternative URL: http://run.to/noicys |