Subject: Re: [boost] [boost, config, context, log, 1.58] address-model and architecture detection
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2015-04-07 04:45:58
On April 7, 2015 2:38:59 AM EDT, Andrey Semashev <andrey.semashev_at_[hidden]> wrote:
> On Tue, Apr 7, 2015 at 8:58 AM, Gavin Lambert <gavinl_at_[hidden]>
> > 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
> > 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
> BTW, I think 32-bit Windows spread is overestimated. Here are some
> stats from Steam, for example (click "OS Version" in the table):
> 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.
(Sent from my portable computation engine)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk