Re: [boost] [boost, config, context, log, 1.58] address-model and architecture detection

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
> 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.