On 3/28/2018 9:51 PM, Vinnie Falco via Boost wrote:
On Wed, Mar 28, 2018 at 5:49 PM, Andrey Semashev via Boost
wrote: If someone wants to target an outdated architecture (and 32-bit x86 really is a separate architecture, including hardware features and software ABI) then let them do that with a little more effort. The rest of the world have moved to 64 bits long ago, and that is what we should target by default, IMO.
No they have not all "moved on to 64 bits." Most programs work perfectly fine as 32-bit applications and have no need for the ability to access a full 64-bit address space. In fact many programs perform objectively worse as 64-bit application since pointers and data structures become larger without a corresponding benefit. This is especially true for mobile applications.
Note that the Visual Studio 2017 default for all new projects/solutions is 32-bit, x86 (aka Win32). In older Visual Studio releases, extra mouse clicks are required to configure a project to compile as x64. If there are a family of projects within an existing solution, then all projects individual project files will likely have to be manually edited to support x64. Ask me how I know. Also note that until proven otherwise, the Boost Unit Test Adapter fork by Microsoft only integrates with Visual Studio 2017 correctly when set to x86 | Release. No other configuration setting will run within the IDE, let alone integrate correctly with the Visual Studio 2017 environment. When this is finally fixed, I have no idea. You will have to ask the Microsoft team managing the Boost Unit Test Adapter fork.
Rumors of 32-bit apps' demise are greatly exaggerated.
Seconded --Robert
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost