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: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-04-08 03:37:42

On Wed, Apr 8, 2015 at 9:11 AM, Gavin Lambert <gavinl_at_[hidden]> wrote:
> On 7/04/2015 18:38, Andrey Semashev wrote:
>>
>> 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
>> old).
>
> That's not the only reason.  There are plenty of 32-bit only components in
> the wild, which force your own code to 32-bit if you use them.
>
> And large legacy codebases still exist and must be maintained, and may have
> been written in such a way that porting them to 64-bit is tricky. (Not
> impossible, of course, but tricky and error-prone, and hard to justify to
> people when the 32-bit version still works.)

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. Of course, there are cases where you simply don't
have a choice (mostly when the code is third party and closed source).
For those cases explicitly specifying target architecture for Boost is
the suitable solution. Adding explicit target architecture for Boost
compilation would be part of the upgrade process.

>> 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.
>
> At the compiler level, sure -- but that wasn't what I was trying to say.
>
> 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.

> Again, I'm all for being able to build Boost both ways (which makes it
> essential to either put the architecture in the filenames or to adopt a
> directory convention (eg. 32-bits in "x86" and 64-bits in "x64" subdirs).

I agree that directory name convention for the target architecture
would be useful. It probably should not be limited just to x86 bitness
- it essentially means support for cross-compiled binaries.