Subject: Re: [boost] [boost, config, context, log, 1.58] address-model and architecture detection
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-04-08 02:11:52
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk