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