Boost logo

Boost :

Subject: Re: [boost] [boost, config, context, log, 1.58] address-model and architecture detection
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-04-08 04:34:12

On 8/04/2015 19:37, Andrey Semashev wrote:
> Well, IMO the code that didn't manage to get ported to 64 bits for
> the last 10 years is dead and I would eagerly avoid using it in new
> projects and even make effort to get rid of it in the currently
> maintained ones.

In the Windows environment, this is not a valid assumption. It is still
probably the case that more than 80% of non-driver-based applications
are 32-bit only. (Though like any made-up statistic, take that with a
grain of salt.)

For another perspective, look at the major applications: Firefox is
32-bit only (barring unofficial builds). Office has 32-bit and 64-bit
versions, but the 32-bit version is the recommended one for general
users (who don't need to edit large documents). Visual Studio itself is
32-bit only. Go to any typical Windows box (that has had some real
usage, not just a freshly installed one) and count the number of
applications in Program Files vs. those in Program Files (x86).

Also, since I forgot to respond to this point earlier:
> BTW, I think 32-bit Windows spread is overestimated. Here are some
> stats from Steam, for example (click "OS Version" in the table):

While Steam is somewhat ubiquitous, it's still a gaming platform. And
gamers will almost always have 64-bit systems because they want the RAM
-- it's rare to find a modern game that isn't RAM-hungry, and even games
of a decade ago often wanted 2GB, which meant your system would run
better if you could have the magic 4GB of RAM or more.

And again, 64-bit Windows platform does not imply that applications
themselves are 64-bit. The majority case is still the opposite.

>> 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.
> That's something MS will have to fix then. I don't think that
> cross-compiling is the right default choice. Even then, if your
> project is more than a simple "hello world", I would expect you to
> set up its parameters carefully.

I'm not sure this counts as cross-compiling, since the CPU can execute
both 32-bit and 64-bit code natively (in fact 32-bit code can be faster
than 64-bit code, although the extra registers in x64 definitely help a
lot in this regard). There is some redirection and emulation at the API
layers but not for the code itself.

Boost list run by bdawes at, gregod at, cpdaniel at, john at