On Wed, Apr 8, 2015 at 9:11 AM, Gavin Lambert
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.