On 7/04/2015 18:38, Andrey Semashev wrote:
Building 64-bit on Windows is not the preferred option for the vast majority of applications, for compatibility reasons.
Typically only those that actually need gobs of memory (read: >1.5GB per app) get compiled for 64-bit. While these certainly exist, they're relatively rare (except in certain domains, perhaps).
Larger address space is not the only benefit of 64-bit x86. More registers (GPRs are also widened to 64 bits), mandatory SSE2, new addressing mode - all these features are very much useful even if you don't need large amounts of memory. In fact, there is no point in building 32-bit binaries nowdays, unless you desperately need compatibility with 32-bit only systems (read - more than a decade old).
That's not the only reason. There are plenty of 32-bit only components in the wild, which force your own code to 32-bit if you use them. And large legacy codebases still exist and must be maintained, and may have been written in such a way that porting them to 64-bit is tricky. (Not impossible, of course, but tricky and error-prone, and hard to justify to people when the 32-bit version still works.)
Regarding MSVC defaults - I think there is a little misunderstanding here. There is no "default" from the compiler standpoint, it's just a matter of environment setup, which defines the compiler executable (cl.exe) that gets picked. The "default" (i.e. clean) environment is not suitable for running any cl.exe, b2 has to pick one anyway and run the corresponding environment setup scripts. It is totally our decision which one we pick.
At the compiler level, sure -- but that wasn't what I was trying to say. Even in VS2013, if you create a new C++ project, you're not even asked if you want it to be 32-bit or 64-bit -- VS will create that project for 32-bit compilation only. Granted, it's not hard to change this setting, but I would be surprised if most end-users bother to do so. These are the *users* of Boost -- who will be very surprised if the default build of Boost does not link with their applications, merely because they happen to be compiling on a 64-bit Windows system. Again, I'm all for being able to build Boost both ways (which makes it essential to either put the architecture in the filenames or to adopt a directory convention (eg. 32-bits in "x86" and 64-bits in "x64" subdirs). I just don't agree that *on Windows* the system architecture has any bearing on the default build architecture.