Subject: Re: [boost] [winapi] Default target Windows version
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-10-16 07:36:15
On Wednesday 16 October 2013 13:20:10 Olaf van der Spek wrote:
> On 16-10-2013 12:13, Andrey Semashev wrote:
> > On Wednesday 16 October 2013 12:05:51 Olaf van der Spek wrote:
> >> On 16-10-2013 0:20, Andrey Semashev wrote:
> >>> On Tuesday 15 October 2013 23:05:45 Olaf van der Spek wrote:
> >>>> What's the concrete advantage of defaulting to Vista? Performance?
> >>> Yes, mostly. Vista has builtin support for condition variables and
> >>> read/write mutexes, for example. Compiler-based TLS can be used safely
> >>> with dlls. GetTickCount64 can also be useful in some contexts and is
> >>> difficult to emulate. All these features will find their use at least in
> >>> Boost.Sync and Boost.Log (the latter currently uses its own protocol for
> >>> enabling use of these APIs, but it will be ported eventually).
> >> If a program targets >= Vista, aren't defines available you could check
> >> anyway?
> > Not necessarily. For example, the macros are typically not defined when
> > building Boost itself.
> Right. Would this create a new set of library variants and allow me to
> build both the XP and Vista variants? Some programs might need the XP
> variants while others might need the Vista ones.
I wasn't planning modifications to Boost.Build, if that's what you mean. But
in my libraries I use inline namespaces, which names depend on the selected
WinAPI version. This warrants against ABI incompatibilities.
Modifying Boost.Build to reflect the selected API in the built file names
might be reasonable, but it's too difficult for me right now.
> > Also, if a program relies on Boost to provide
> > abstraction over the OS API, it may well omit defining those macros too.
> True, but then these programs might as well just define the official
> defines instead of the Boost one.
The question is what to do when nothing is defined. You have to choose some
And regarding the official macros, there are at least two of them in wide use
(_WIN32_WINNT and WINVER) and quite a few more controlling versions of other
parts of Windows SDK. It is much easier to use just one. Also, it would be
theoretically possible to constrain Boost to use some specific API version,
while the rest of the application uses another (probably, newer) version.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk