On 29 March 2018 at 19:00, Antony Polukhin via Boost <boost@lists.boost.org> wrote:
IMO a good solution for this issue would be to test for an ability of the compiler to do 64bit builds. If it does not support 64 bit builds - just disable them and build i 32 bit mode.
About 32 or 64 bits by default... I'd prefer 64 bits as a more modern solution. Users always can switch back to 32 if they have a need.
My small data point, as a boost user and cross platform dev. In all of my applications I need: - both 32bit and 64bit versions of boost on windows and linux (embedded 32bit) - to generate both 32bit and 64bit versions of my apps because - experience shows (because of different possible reasons, including cache miss profile changes) that guessing which one will be the most efficient is not possible, so depending on the app, I/we decide to use one or the other. - for some programs I need to use some closed libraries (unfortunately I can't easily change that now) which only provide 32bit binaries, but I still need a different 64bit version available too (without these libs but without the related features too); - "memory is cheap" is actually wrong when your main performance bottleneck is cache-misses that trigger more in 64bit because your structs containing pointers just double sizes; - also note that the size of binaries (that 64bit often impacts) is a major issue with some online systems when updating as it can lead to significant downloads, even with a binary patching system; My point: it's not obvious at all which of 32bit or 64bit is superior in practice (at least on windows but not clear if it's an OS thing or not) depending on the application and how it's coded, although it would make my life easier if 64bit was not surprisingly expensive sometime, so that I don't have to bother about that (and sometime I just ignore the hit and use it anyway, depends). All that is not very important actually if I was just building boost with the right flags to compile all I need - which is basically what I do anyway. The core issue that lead to that change, if my memory is correct, is that the boost binaries distribution, which is equivalent to the default build configuration, have to be set so that tools (in particular CMake) have a change to guess which version is built (which is now in the file name) and select the version depending on what the user want (instead of having to point to different boost install directories manually). Next CMake version will handle boost binaries detection automatically (the patch have been merged several weeks ago, I dont know why it was not in the last release but they plan it for the next). Though it forces me to adapt my boost build scripts to build all variants, I'm not against the default build config to only building one of the platforms (but please keep the tests running for both! both are used!). It also seem ok if it's only 64bit by default. However, please keep the new naming layout as it is to make sure tools identify the architecture of the binaries easily and the binary distribution matches at least partially a default build of boost. As long as you keep that, it should be fine IMO (although keep in mind that 32bit dev will not go away on Windows soon, it really is unfortunately necessary to be able to use it depending on the program). A. Joël Lamotte