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):
>
> http://store.steampowered.com/hwsurvey/
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.