| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Sep 01 04:30PM -0700 > Not entirely correct. The allocated storage must be properly aligned > for an object of that size. > So if smaller than a long double, it can also be less aligned. That's not what the standard says: The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object with a fundamental alignment requirement and then used to access such an object or an array of such objects in the space allocated (until the space is explicitly deallocated). It can be difficult to tell whether double *p = malloc(1); gives you proper alignment, but the standard doesn't give permission for small allocations to have less strict alignment. (BTW, there's no guarantee that long double has the strictest alignment.) -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips void Void(void) { Void(); } /* The recursive call of the void */ |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 02 05:30AM +0200 Am 01.09.2021 um 21:55 schrieb Bo Persson: >> https://en.cppreference.com/w/c/types/max_align_t > Not entirely correct. The allocated storage must be properly aligned for > an object of that size. No, it's like what I said: > So if smaller than a long double, it can also be less aligned. No. |
| Juha Nieminen <nospam@thanks.invalid>: Sep 02 06:58AM > known to work on Windows in both 32-bit and 64-bit mode." > So you *can* run it on Windows. MSYS2, btw, is not some sort of Linux > emulation for Windows, as it might seem and opposed to Cygwin or WSL. You can run *what* on Windows? GMP is not a program. It's a library, which you can use in your programs. It's just a question of how many hurdles the developers have put to make it possible to compile it so that you can use it in your program. (One thing I really detest in the unix style source code design is the ubiquitous all-encompassing configure script, which is quite often used even in projects that wouldn't need one. Essentially, the library is, for all intents and purposes, being "held hostage" by its configure script. It won't compile as-is unless you run the configure script first, and the script will only run on a unix environment, and generally will only be able to configure the library to be compiled for the current host operating system. Depending on the complexity of the project, trying to compile it without running the script may be almost insurmountable, as it would require manually defining millions of things, manually creating very large files, and so on. This is not only detrimental to trying to compile the project for a non-unix platform (even if the source code of the project could well be 100% portable without any need for this), but it also makes it extraordinarily difficult to cross-compile it to another platform than the current one. Such as trying to use such a library in an iOS project. I know. I have pulled my hair many times because of this. It has taught me to *hate* unix-style configure scripts, and them keeping completely portable libraries as hostages.) |
| Paavo Helde <myfirstname@osa.pri.ee>: Sep 02 12:31PM +0300 01.09.2021 20:11 Bart kirjutas: > Try building GMP on pure Windows (no CYGWIN, MSYS2 or WSL to make it > emulate Linux). GMP is a numerical library; how does the OS come into it? With such libraries, I have had some success by adding their source files directly into my project and just ignoring their original build system. |
| David Brown <david.brown@hesbynett.no>: Sep 02 11:34AM +0200 On 02/09/2021 08:58, Juha Nieminen wrote: > It's just a question of how many hurdles the developers have put to > make it possible to compile it so that you can use it in your program. > (One thing I really detest in the unix style source code design is the <snip> > hostages.) I doubt if anyone will try to suggest that configure scripts are always written perfectly, or that even that it is a good way to handle cross-system compatibility in modern times. However, you are writing as though the GMP authors have a duty and a responsibility to make life easier for any programmers, on any system, with any preferences for how they want to get the library and make use of it. They have no such duty. These are people who have got together with a common need - for high-performance arbitrary precision arithmetic - and decided they would get better results working together on a common library than doing so separately. I'm sure they also enjoy helping others, and feel it is a good thing to make their code available. They don't /owe/ you anything. They don't owe Windows developers anything. They don't owe Linux developers, or Solaris developers, or anyone else. If other people want to make GMP easier to install on Windows, that's great. If other people want to make it easer to install on Linux, or anything else, that's great too. Only a small fraction of Linux users would install it by downloading and doing the ".configure && make && make install" dance. Most would do "apt-get install libgmp-dev", or similar.) And it turns out that people /have/ made things easier for getting GMP on Windows. If you use cygwin, the library is there. If you use msys2, the library is there. If you want to use it from MSVC, instructions and project settings are available. If you want to use it from Python, or PHP, or another language, packages are available. Perhaps things won't work immediately, or there are complications that you need to work through. But frankly, if you are not able to figure it out then you are probably not in a position to make much use of such a library anyway. One thing we can be sure about, however. If someone provides a library like this "in the unix way", it might be difficult to use on a Windows system, but it will be possible (baring unix-specific features). If they were to make a Windows library in "the Windows way", it can't be used on anything else. Hell, it probably won't even be usable if you don't have MSVC, which in turn tries to push you to the latest updates of the latest version of Windows. |
| Bart <bc@freeuk.com>: Sep 02 11:11AM +0100 On 02/09/2021 10:31, Paavo Helde wrote: > With such libraries, I have had some success by adding their source > files directly into my project and just ignoring their original build > system. That's what I do with open source C code in general; try and build it by just compiling the source files. But often the source files are disseminated across dozens of nested directories. You don't know which source files are relevant. The header files are equally scattered requiring special -I compiler options. You don't know what mix of executables/shared libraries will be generated using which source files. Often this info is buried in make files and you have to extract it painfilly, when a summary in English would help tremendously. (Sometimes just a list of files and options in an '@' file would do the job.) Another thing that is popular, is for the build system (make etc) to synthesise some essential header file necessary for compilation; one that doesn't otherwise exist. Sometimes that file only consists of one line. In the case of GMP, the 'configure' script is over 30,000 lines and only runs on Linux. The source codes also depends on inline ASM so will only work on certain compilers anyway. However, buried within the source code as I saw yesterday, was a tiny version of GMP, mini-GMP, in the two files mini-gmp.c and mini-gmp.h. This is rather limited, it only does integers, and it doesn't have the fastest algorithms, but it seems to work. /This/ is how libraries should be presented. I can trivially turn that into a shared library using: gcc -s -shared -O3 mini-gmp.c -omini-gmp.dll or: tcc -shared mini-gmp.c One C source file, one C header file, one C compiler. (And my distributions didn't even need a header file.) |
| RantingRover <noemail@4u.com>: Sep 02 01:14PM +0200 On 01.09.2021 19:11, Bart wrote: > Try building GMP on pure Windows (no CYGWIN, MSYS2 or WSL to make it > emulate Linux). GMP is a numerical library; how does the OS come into it? I think that's a problem with the build system, not with the library itself. For example, building a project using libgmp with Visual Studio on pure Windows is not a very complicated process, given the fact that sane build tools are present, e.g. conan package manager and cmake. >> conanfile.txt [requires] gmp/6.2.1 [generators] cmake >> CMakeLists.txt cmake_minimum_required(VERSION 3.5) project(gmp-test CXX) add_executable(gmp-test test.cpp) include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake) conan_basic_setup(TARGETS NO_OUTPUT_DIRS) target_link_libraries(gmp-test PUBLIC CONAN_PKG::gmp) >> test.cpp #include <gmp.h> int main() { gmp_printf("Hello world\n"); return 0; } >> command line: PS d:\vc\gmp-test> mkdir build ; cd build PS d:\vc\gmp-test\build> conan install .. PS d:\vc\gmp-test\build> cmake -G "Visual Studio 16 2019" .. PS D:\vc\gmp-test\build> msbuild.exe *.sln [...] 5 Warning(s) 0 Error(s) PS D:\vc\gmp-test\build> .\Debug\gmp-test.exe Hello world |
| Paavo Helde <myfirstname@osa.pri.ee>: Sep 02 04:04PM +0300 02.09.2021 13:11 Bart kirjutas: > tcc -shared mini-gmp.c > One C source file, one C header file, one C compiler. (And my > distributions didn't even need a header file.) In this sense SQLite is nice. A complete database engine in a single (amalgamated) source file, compiles without any hassles. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Sep 02 02:51PM -0700 David Brown <david.brown@hesbynett.no> writes: [...] > I doubt if anyone will try to suggest that configure scripts are always > written perfectly, or that even that it is a good way to handle > cross-system compatibility in modern times. It's also worth pointing out that configure scripts are not hand-written and are not expected to be maintained in that form. For example the configure script for the bash shell is about 22,000 lines, but it's generated from a much smaller configure.ac, and it's likely a lot of automation (or at least copy-and-paste) went into writing that. The generated configure script is included in the *.tar.gz file in which *nix source packages are usually distributed because it means the user who builds it doesn't need to have the tools that create the configure script. Think of the configure script as generated code that happens to run under a shell. The configure script is designed to be portable to Unix-like systems (a Bourne-like shell is required to run it). The complexity goes back to days when there was more variety in the Unix ecosystem than there is today. A configure script will likely check for features that could be assumed to be universally available today, and for platforms that hardly exist anymore. The inner workings of the autoconf system are almost certainly more complicated than they needs to be, but 99% of people who use it aren't affected by that complexity. Run "configure&&make&&make install" and you're done. That's unfortunate if you want to install an autoconf-based package on a system that doesn't have a Bourne-like shell, but nobody is obligated to make that easy. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips void Void(void) { Void(); } /* The recursive call of the void */ |
| Bart <bc@freeuk.com>: Sep 02 11:31PM +0100 On 02/09/2021 22:51, Keith Thompson wrote: > complicated than they needs to be, but 99% of people who use it aren't > affected by that complexity. Run "configure&&make&&make install" and > you're done. When I built A68G (an Algol68 interpreter) on Linux, the whole process took 5 minutes (300 seconds), most of that probably spent running 100s of pointless tests via that configuration file. This is for a program consisting of about 70K lines of C. If I just build those 70K lines directly (in about 12 modules, after prising that information out of the make file), then a fast C compiler can build it in about 1 second, on Windows. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 02 05:31AM +0200 Am 01.09.2021 um 21:10 schrieb Bonita Montero: > x /= 2; > else > if( 3 * x / x == x && 3 * x + 1 > 3 * x ) if( 3 * x / 3 == x && 3 * x + 1 > 3 * x ) |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 02 07:51AM +0200 Look at this fantastic optimization of clang 11: bool f( unsigned x ) { return 3 * x / 3 == x && 3 * x + 1 > 3 * x; } mov eax, ecx mov ecx, 3 mul ecx setno cl cmp eax, -1 setne al and al, cl ret |
| David Brown <david.brown@hesbynett.no>: Sep 02 11:53AM +0200 On 01/09/2021 21:02, Bonita Montero wrote: >> { >> x = (x%2 == 0 ? x/2 : 3*x+1); > Will x ever has a chance to become 1 ? Yes. The conjecture is that it will always become 1, regardless of the starting point. This has been confirmed up to x = 2 ^ 68, but of course that is not a proof. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment