Re: [boost] [Config] Testing instructions for compiler vendors
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 BOOST_WORKAROUND(symbol, test) ((symbol != 0) (symbol test)) Looks good to me. How about keeping it in a separate header, though? Personally, I am getting annoyed by having to write, for example: #include boost/config.hpp // for BOOST_STATIC_CONSTANT instead of #include boost/config/static_constant.hpp and by tracking down whether a header still needs boost/config.hpp include after you've removed, let's say, all BOOST_STRICT_CONFIG references. Fine with me. I never intended to move it until John suggested it. The two of you can duke it out over this one, as far as I'm concerned ;- -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
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 BOOST_STRICT_CONFIG, there's no reason not to let BOOST_STRICT_CONFIG turn off workarounds always. In that case, the test above might as well just be: # if defined(__BORLANDC__) !defined(BOOST_STRICT_CONFIG) And, it seems to me, if the presumption that the bug being worked around is likely present in future versions is correct, this is better because there's no associated maintenance cost (i.e. nobody has to bump the version number). I think the current accepted form quoted by you and Aleksey is theoretically interesting, but the version number doesn't have much value other than as a comment. Wouldn't #if BOOST_WORKAROUND(__BORLANDC__, != 0) // last checked at 0x569 or #if BOOST_WORKAROUND(__BORLANDC__, +0x569) // not sure about overflow issues, so maybe not be just as good, or maybe even better? I agree completely, and I'll even promise not to change my mind for at least a week :-) John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
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 != 0) (symbol test)) And, I suggest BOOST_WORKAROUND(__BORLANDC__, |0x569) As the standard comment about the last known version where the workaround is needed. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
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 (not necessarily as long as the following) might be helpful: #define WORKAROUND_LAST_CHECKED_AT_VERSION(version) |1 // documentation macro only ... BOOST_WORKAROUND(__BORLANDC__, WORKAROUND_LAST_CHECKED_AT_VERSION(0x569)) ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
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 thread, I think something more descriptive (not necessarily as long as the following) might be helpful: #define WORKAROUND_LAST_CHECKED_AT_VERSION(version) |1 // documentation macro only ... BOOST_WORKAROUND(__BORLANDC__, WORKAROUND_LAST_CHECKED_AT_VERSION(0x569)) 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 simply document the | convention there. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
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 simply document the | convention there. I agree, I considered this later that night, after I wrote the message. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [Config] Testing instructions for compiler vendors
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) (symbol test)) Looks good to me. How about keeping it in a separate header, though? Personally, I am getting annoyed by having to write, for example: #include boost/config.hpp // for BOOST_STATIC_CONSTANT instead of #include boost/config/static_constant.hpp and by tracking down whether a header still needs boost/config.hpp include after you've removed, let's say, all BOOST_STRICT_CONFIG references. And, I suggest BOOST_WORKAROUND(__BORLANDC__, |0x569) As the standard comment about the last known version where the workaround is needed. Agreed. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
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 workaround, other than by faking the compiler version number? OK you've convinced me: apart from anything else it's an easier rule to adhere to - lets just trust the user and have BOOST_STRICT_CONFIG disable compiler specific workarounds. Incidentally, I think we had some kind of agreement a while back (sparked by Thomas Witt, IIRC) that when a workaround is implemented for the most recent compiler version, no assumption should be made that the corresponding bug will be fixed in future versions. I don't think my macro accounts for that, and I really don't know a good way to cope with it. I don't think we ought to add any workarounds without at least some way to record the most-recent version where it's known to be needed. In theory the way to do that is (for example): #if defined(__BORLANDC__) ((__BORLANDC__ 0x570) || !defined(BOOST_STRICT_CONFIG)) which enables the workaround for all Borland versions, unless BOOST_STRICT_CONFIG is defined. This is consistent with the way that the existing config system works BTW, although it does present a maintenance problem (lots of compiler version checks scattered all over the place, all of which need updating when a new compiler is released). This also conflicts with your desired use case (disabling workarounds in cases where we know that it really is needed)! Round and round and round :-( John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
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 compiler against the Boost CVS without workaround, other than by faking the compiler version number? OK you've convinced me: apart from anything else it's an easier rule to adhere to - lets just trust the user and have BOOST_STRICT_CONFIG disable compiler specific workarounds. Incidentally, I think we had some kind of agreement a while back (sparked by Thomas Witt, IIRC) that when a workaround is implemented for the most recent compiler version, no assumption should be made that the corresponding bug will be fixed in future versions. I don't think my macro accounts for that, and I really don't know a good way to cope with it. I don't think we ought to add any workarounds without at least some way to record the most-recent version where it's known to be needed. In theory the way to do that is (for example): #if defined(__BORLANDC__) ((__BORLANDC__ 0x570) || !defined(BOOST_STRICT_CONFIG)) which enables the workaround for all Borland versions, unless BOOST_STRICT_CONFIG is defined. This is consistent with the way that the existing config system works BTW, although it does present a maintenance problem (lots of compiler version checks scattered all over the place, all of which need updating when a new compiler is released). This also conflicts with your desired use case (disabling workarounds in cases where we know that it really is needed)! Round and round and round :-( OK, now I've rewritten and re-thought this email about 5 times ;-) 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 BOOST_STRICT_CONFIG, there's no reason not to let BOOST_STRICT_CONFIG turn off workarounds always. In that case, the test above might as well just be: # if defined(__BORLANDC__) !defined(BOOST_STRICT_CONFIG) And, it seems to me, if the presumption that the bug being worked around is likely present in future versions is correct, this is better because there's no associated maintenance cost (i.e. nobody has to bump the version number). I think the current accepted form quoted by you and Aleksey is theoretically interesting, but the version number doesn't have much value other than as a comment. Wouldn't #if BOOST_WORKAROUND(__BORLANDC__, != 0) // last checked at 0x569 or #if BOOST_WORKAROUND(__BORLANDC__, +0x569) // not sure about overflow issues, so maybe not be just as good, or maybe even better? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
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 Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
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 compiler/library macros?) would be applied unconditionally, regardless of whether the compiler has known defects. What's the use of distinguishing those? Surely the person who's doing the testing doesn't care about whether we think we know that particular compiler version? Would you believe that I've rewritten this mail three times with the previous two having flaws (discovered just as I'm adding my sig!). Hopefully this time this is logically correct, how about this: If the config system detects a compiler version it knows about, and which it knows will likely need compiler specific workarounds, then it undef's BOOST_STRICT_CONFIG if it's set (in the compiler config files). Then we just use BOOST_STRICT_CONFIG as to determine whether to enable workarounds or not. There are now three use cases if BOOST_STRICT_CONFIG is defined: 1) We recognise the compiler, and know that it needs workarounds: disable BOOST_STRICT_CONFIG. 2) We don't recognise the compiler: assume that it is standard conforming and disable all workarounds. 3) BOOST_NO_COMPILER_CONFIG is set: so irrespective of the compiler version all workarounds will be turned off. BTW I think your BOOST_WORKAROUND macro belongs in boost/config/suffix.hpp if you want to move it there (so we all get it), and of course it needs docs adding - probably to the helper macros table in the config docs. John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
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 compilers version is greater than the last known version and BOOST_STRICT_CONFIG is set, then boost workaround-code need only check for the presence of BOOST_NO_WORKAROUNDS or whatever in addition to the compiler version. How does this sound? John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm I like it. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
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 BOOST_DISABLE_WORKAROUNDS, as by convention BOOST_NO_XXX macros indicate defects. :-) ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
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 defined by the compiler config when the compilers version is greater than the last known version and BOOST_STRICT_CONFIG is set, then boost workaround-code need only check for the presence of BOOST_NO_WORKAROUNDS or whatever in addition to the compiler version. How does this sound? John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm 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? Maybe I just don't understand the proposal, and code would help. Can you show us a rewrite of boost/detail/workaround.hpp that would correspond to what you're proposing? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
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 unknown compiler versions, and BOOST_DISABLE_WORKAROUNDS (do we need separate compiler/library macros?) would be applied unconditionally, regardless of whether the compiler has known defects. What's the use of distinguishing those? Surely the person who's doing the testing doesn't care about whether we think we know that particular compiler version? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [Config] Testing instructions for compiler vendors
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 the library - BOOST_STRICT_CONFIG - to disable some checks in source code - macros for any known-not-implemented features, e.g. BOOST_NO_TEMPLATE_TEMPLATES. Right? As far as I understand, defining BOOST_STRICT_CONFIG only should be sufficient (for compiler tests) - given that the compiler being tested has a bumped up version number. 2. What about all the places we make compiler-specific checks in Boost code? Could we define some macros which make it easier and less error-prone to write these, and which can be globally turned off when needed? # if BOOST_COMPILER_WORKAROUND(__SUNPRO_CC, = 0x540) ... #else ... #endif The checks for the past versions of the compiler, e.g. #if defined(BOOST_MSVC) BOOST_MSVC = 1300 # define BOOST_MPL_MSVC_ETI_BUG #endif are harmless for the beta-testing of the new one. As for checks for current bugs, I think it's our current convention that they should be guarded by BOOST_STRICT_CONFIG, like this: #if defined(__BORLANDC__) \ (__BORLANDC__ = 0x570 || !defined(BOOST_STRICT_CONFIG)) # define BOOST_MPL_BROKEN_OVERLOAD_RESOLUTION #endif so defining BOOST_STRICT_CONFIG would disable them. I am afraid it's not thoroughly enforced, though. If we come up with a way to simplify the above, personally I would be more than happy. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
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 - BOOST_NO_STDLIB_CONFIG - if they want to check the library - BOOST_STRICT_CONFIG - to disable some checks in source code - macros for any known-not-implemented features, e.g. BOOST_NO_TEMPLATE_TEMPLATES. Right? As far as I understand, defining BOOST_STRICT_CONFIG only should be sufficient (for compiler tests) - given that the compiler being tested has a bumped up version number. That's a big assumption. Some vendors will want to check their current release, and sometimes we begin to set up configuration for pre-released compilers. 2. What about all the places we make compiler-specific checks in Boost code? Could we define some macros which make it easier and less error-prone to write these, and which can be globally turned off when needed? # if BOOST_COMPILER_WORKAROUND(__SUNPRO_CC, = 0x540) ... #else ... #endif The checks for the past versions of the compiler, e.g. #if defined(BOOST_MSVC) BOOST_MSVC = 1300 # define BOOST_MPL_MSVC_ETI_BUG #endif are harmless for the beta-testing of the new one. I suppose. I can see it being useful to be able to demonstrate bugs in any version of a compiler, though. As for checks for current bugs, I think it's our current convention that they should be guarded by BOOST_STRICT_CONFIG, like this: #if defined(__BORLANDC__) \ (__BORLANDC__ = 0x570 || !defined(BOOST_STRICT_CONFIG)) # define BOOST_MPL_BROKEN_OVERLOAD_RESOLUTION #endif so defining BOOST_STRICT_CONFIG would disable them. I'm not sure there's universal agreement about that, but now that Doug has fixed the function headers, the code says otherwise. I am afraid it's not thoroughly enforced, though. If we come up with a way to simplify the above, personally I would be more than happy. I propose: #ifndef BOOST_STRICT_CONFIG # define BOOST_WORKAROUND(symbol, test) (defined(symbol) symbol test) #else # define BOOST_WORKAROUND(symbol, test) 0 #endif Comments? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
--- 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 following this thread. I'm busy and just trying to read the posts quickly. This example struck me though. Please take a look at this: http://groups.google.com/groups?threadm=m4TT8.211653%24nZ3.100438%40rwcrnsc53 Genny. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
- 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 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 the library - BOOST_STRICT_CONFIG - to disable some checks in source code - macros for any known-not-implemented features, e.g. BOOST_NO_TEMPLATE_TEMPLATES. Right? Questions: 1. Should we do something to make this easier for them? No. We should focus on serving our users. 2. What about all the places we make compiler-specific checks in Boost code? Could we define some macros which make it easier and less error-prone to write these, and which can be globally turned off when needed? # if BOOST_COMPILER_WORKAROUND(__SUNPRO_CC, = 0x540) ... #else ... #endif I'm sometimes not even able to decide who is wrong ;-( Best regards Joerg ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
- 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 something to make this easier for them? No. We should focus on serving our users. Our users will be happy and our lives will be easier if their compilers finally start working. Didn't they have enough time and resources to work this out 'til now? Best regards Joerg ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
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 BOOST_STRICT_CONFIG is the right macro to determine if workarounds are enabled or not, but if John agrees then I'm happy with it. Regardless of what macro determines which BOOST_WORKAROUND is used, I like the above definition (+ dumb compiler workarounds). Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [Config] Testing instructions for compiler vendors
Hi, 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 the library - BOOST_STRICT_CONFIG - to disable some checks in source code - macros for any known-not-implemented features, e.g. BOOST_NO_TEMPLATE_TEMPLATES. Right? Questions: 1. Should we do something to make this easier for them? 2. What about all the places we make compiler-specific checks in Boost code? Could we define some macros which make it easier and less error-prone to write these, and which can be globally turned off when needed? # if BOOST_COMPILER_WORKAROUND(__SUNPRO_CC, = 0x540) ... #else ... #endif Thoughts? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
