|
Boost : |
From: Edward Diener (eddielee_at_[hidden])
Date: 2002-10-22 09:12:58
"John Maddock" <jm_at_[hidden]> wrote in message
news:010901c279b9$c86b96c0$51be193e_at_1016031671...
>
> > Is the official Boost position on this, if there is one, to build such
> > libraries without the /Zc:wchar_t switch and tell the end user that he
> must
> > do the same if he wants to use the Boost library ?
>
> There is no official position, but it seems to reasonable to me, that
boost
> libraries should be built using the toolsets default options, and if the
> user want something different then they should have to rebuild their
> libraries. Basically there is a limit to how many library variants we
want
> built by default (and how many user will tolerate) - there are already 6
for
> VC6/7, IMO that's enough.
Sounds reasonable to me also. I am wondering if a note regarding the
/Zc:wchar_t linker incompatibility is warranted when distributing VC7
versions of libraries. The reason I mention this is something that has
occurred before. The command line compiler for VC7 does not default to
/Zc:wchar_t but I think I have seen situations using the IDE wizards for
setting up project types where /Zc:wchar_t is automatically turned on as the
default. I think BCB does similar things in a few cases with some of their
defaults. So while the Boost libraries are always built from the command
line compilers, and use those defaults, end users who use the IDEs may be
wondering why they can't link when they use the IDE defaults.
MS should have provided a #pragma for this so that one could have set the
wchar_t type in the header file and the compiler would have honored it no
matter what the default was. Then end users would have gotten a compiler
error if they try to pass the wrong wchar_t type to a function.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk