Aleksey Gurtovoy [EMAIL PROTECTED] writes:
David Abrahams wrote:
I agree completely, and I'll even promise not to change my
mind for at least a week :-)
Good! You, Aleksey and I all agree. So shall we go with this
definition of BOOST_WORKAROUND from Gennaro Prota?
#define
OK, now I've rewritten and re-thought this email about 5 times ;-)
Only 5 ? ;-
I'm going to ask a controversial question: what is the point of
checking the version at all in the case above, really? If you buy my
argument that the user surely knows what he's doing when he specifies
John Maddock [EMAIL PROTECTED] writes:
I agree completely, and I'll even promise not to change my mind for at least
a week :-)
Good! You, Aleksey and I all agree. So shall we go with this definition
of BOOST_WORKAROUND from Gennaro Prota?
#define BOOST_WORKAROUND(symbol, test) ((symbol !=
On Tue, 10 Dec 2002, David Abrahams wrote:
And, I suggest
BOOST_WORKAROUND(__BORLANDC__, |0x569)
Since I began wondering whether it was a typo that you used | instead of
, since the | obviously always evaluates true, leading me to browse this
thread, I think something more descriptive
Yitzhak Sapir [EMAIL PROTECTED] writes:
On Tue, 10 Dec 2002, David Abrahams wrote:
And, I suggest
BOOST_WORKAROUND(__BORLANDC__, |0x569)
Since I began wondering whether it was a typo that you used | instead of
, since the | obviously always evaluates true, leading me to browse this
On Tue, 10 Dec 2002, David Abrahams wrote:
That's awfully verbose, though. And it would need a BOOST_ prefix,
making it more verbose still.
Given that the meaning of BOOST_WORKAROUND is already non-transparent,
you need to read the documentation to understand it. I think it'd be
best to
David Abrahams wrote:
I agree completely, and I'll even promise not to change my
mind for at least a week :-)
Good! You, Aleksey and I all agree. So shall we go with this
definition of BOOST_WORKAROUND from Gennaro Prota?
#define BOOST_WORKAROUND(symbol, test) ((symbol != 0)
This is bad [but read to the end because I might change my
mind]. Suppose someone is working with a pre-release of MSVC 8.0. She
knows it has several problems, so adds appropriate workarounds to the
code. How can someone over at Microsoft is test their compiler against
the Boost CVS without
John Maddock [EMAIL PROTECTED] writes:
This is bad [but read to the end because I might change my
mind]. Suppose someone is working with a pre-release of MSVC 8.0. She
knows it has several problems, so adds appropriate workarounds to the
code. How can someone over at Microsoft is test their
David Abrahams [EMAIL PROTECTED] writes:
or
#if BOOST_WORKAROUND(__BORLANDC__, +0x569)
// not sure about overflow issues, so maybe not
or
#if BOOST_WORKAROUND(__BORLANDC__, |0x569)
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
I don't (yet). Why do we need yet another macro which means turn off
the workarounds? Would BOOST_STRICT_CONFIG then be obsolete?
I think that the idea is that BOOST_STRICT_CONFIG applies only to
unknown
compiler versions, and BOOST_DISABLE_WORKAROUNDS (do we need separate
On Saturday 07 December 2002 06:47 am, John Maddock wrote:
Maybe we need something new for those folks: something like
BOOST_NO_WORKAROUNDS or whatever, that disables all compiler workarounds?
To keep things centralised BOOST_NO_WORKAROUNDS should be defined by the
compiler config when the
From: Douglas Gregor [EMAIL PROTECTED]
On Saturday 07 December 2002 06:47 am, John Maddock wrote:
Maybe we need something new for those folks: something like
BOOST_NO_WORKAROUNDS or whatever, that disables all compiler
workarounds?
[...]
I like it.
Looks reasonable, although I'd prefer
Douglas Gregor [EMAIL PROTECTED] writes:
On Saturday 07 December 2002 06:47 am, John Maddock wrote:
Maybe we need something new for those folks: something like
BOOST_NO_WORKAROUNDS or whatever, that disables all compiler workarounds?
To keep things centralised BOOST_NO_WORKAROUNDS should be
Peter Dimov [EMAIL PROTECTED] writes:
From: David Abrahams [EMAIL PROTECTED]
I like it.
I don't (yet). Why do we need yet another macro which means turn off
the workarounds? Would BOOST_STRICT_CONFIG then be obsolete?
I think that the idea is that BOOST_STRICT_CONFIG applies only to
David Abrahams wrote:
I'm trying to come up with instructions for compiler vendors who want
to use Boost to test their compilers. What preprocessor symbols do
they need to define? So far, it looks like:
- BOOST_NO_COMPILER_CONFIG
- BOOST_NO_STDLIB_CONFIG - if they want to check
Aleksey Gurtovoy [EMAIL PROTECTED] writes:
David Abrahams wrote:
I'm trying to come up with instructions for compiler vendors who want
to use Boost to test their compilers. What preprocessor symbols do
they need to define? So far, it looks like:
- BOOST_NO_COMPILER_CONFIG
-
--- David Abrahams [EMAIL PROTECTED] wrote:
[...]
I propose:
#ifndef BOOST_STRICT_CONFIG
# define BOOST_WORKAROUND(symbol, test) (defined(symbol) symbol test)
#else
# define BOOST_WORKAROUND(symbol, test) 0
#endif
Comments?
Sorry for jumping in without really
- Original Message -
From: David Abrahams [EMAIL PROTECTED]
To: boost [EMAIL PROTECTED]
Sent: Wednesday, December 04, 2002 9:27 PM
Subject: [boost] [Config] Testing instructions for compiler vendors
Hi,
I'm trying to come up with instructions for compiler vendors who want
to use
- Original Message -
From: David Abrahams [EMAIL PROTECTED]
To: Boost mailing list [EMAIL PROTECTED]
Sent: Thursday, December 05, 2002 9:38 PM
Subject: Re: [boost] [Config] Testing instructions for compiler vendors
[EMAIL PROTECTED] (Joerg Walter) writes:
1. Should we do
On Thursday 05 December 2002 02:41 pm, David Abrahams wrote:
I propose:
#ifndef BOOST_STRICT_CONFIG
# define BOOST_WORKAROUND(symbol, test) (defined(symbol) symbol
test) #else
# define BOOST_WORKAROUND(symbol, test) 0
#endif
Comments?
I'm still not sure that
21 matches
Mail list logo
