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

On April 7, 2015 2:38:59 AM EDT, Andrey Semashev wrote:

On Tue, Apr 7, 2015 at 8:58 AM, Gavin Lambert wrote:

...

Building 64-bit on Windows is not the preferred option for the vast

...

of applications, for compatibility reasons.

Typically only those that actually need gobs of memory (read: >1.5GB

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

Right

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

BTW, I think 32-bit Windows spread is overestimated. Here are some stats from Steam, for example (click "OS Version" in the table):

http://store.steampowered.com/hwsurvey/

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.

So my vote is for building 64-bit binaries on a 64-bit system by default. This is also consistent with other systems.

We always build Boost 64b. ___ Rob (Sent from my portable computation engine)