Re: [boost] [Config] Testing instructions for compiler vendors
At 03:38 PM 12/5/2002, David Abrahams wrote: >[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. I agree with Dave 100%. Boost developers and users both waste far too much time dealing with broken compilers. If we can, without a huge amount of effort, make it easier for compiler suppliers to test against the Boost libraries, that really will end up being a benefit for users, IMO. --Beman ___ 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 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
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
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
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: > 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
"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
> 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
David Abrahams wrote: > "John Maddock" <[EMAIL PROTECTED]> writes: > > 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). Actually, they don't - as far as BOOST_STRICT_CONFIG is not defined (I wonder if anybody uses it at all), the checks will continue to work. Updating them is a strictly volunteer activity :) > > 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) > Well, expect that the above doesn't let you distinguish whether the bug is (was) really present in the latest known version of the compiler, or the person who wrote the above was just sloppy/careless ;). > 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. Hmm, looks like a 100% correct observation to me. > 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 am sold on this one :). Aleksey ___ 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
"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
> 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
David Abrahams wrote: > > 2) We don't recognise the compiler: assume that it is standard > > conforming and disable all workarounds. > > Is this a different case from "we recognize the compiler, but not the > compiler version"? > > 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. That was probably me (http://lists.boost.org/MailArchives/boost/msg16944.php). Actually, it's not "incidentally" at all - that very thread was what triggered the introduction of BOOST_STRICT_CONFIG with the semantics John is trying to defend ;). > 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. Well, #if defined(COMPILER_VER) && (COMPILER_VER <= xxx || !defined(BOOST_STRICT_CONFIG)) is the current way to do exactly that (a verbose one, admittedly). Aleksey ___ 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 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!). I'm afraid so ;-) > 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). This is confusing and a bit alarming. If the user intentionally sets BOOST_STRICT_CONFIG I don't think our configuration system should ever undef it. Why would anyone want that behavior? Or are you suggesting that users should never set BOOST_STRICT_CONFIG in the first place, instead leaving that job to our compiler config files? > Then we just use BOOST_STRICT_CONFIG as to determine whether to enable > workarounds or not. Why can't we do that anyway, without the #undef behavior you suggest above? > 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. 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? Further, suppose someone at Microsoft wants to investigate a problem in the already-released vc7.1, which seems to have bugs related to the same problem? Fake-bumping the version number forward for vc7.1 might be a bad idea because it would pick up workarounds for the 8.0 prerelease. > 2) We don't recognise the compiler: assume that it is standard > conforming and disable all workarounds. Is this a different case from "we recognize the compiler, but not the compiler version"? 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. > 3) BOOST_NO_COMPILER_CONFIG is set: so irrespective of the compiler version > all workarounds will be turned off. O...K, but why should we not respect BOOST_STRICT_CONFIG in exactly the same way? It sounds like you want BOOST_STRICT_CONFIG to have meaning only for compilers that we don't know need any workarounds. But what difference will it make for those compilers? > 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), Until the dust settles, I'd rather leave it in boost/detail/workaround.hpp. When we get all these other issues figured out, we can move it. > and of course it needs docs adding - probably to the helper > macros table in the config docs. Remind me when this is all over ;-) -- 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
"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
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. ___ 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
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
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
> 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). OK let me try and explain what I had in mind when those macros were introduced: BOOST_NO_XXX_CONFIG: disables automatic configuration of compiler/stdlib/platform, generally used in conjunction with a customised boost/config/user.hpp to prevent dependencies on the config system. Should *not* disable compiler workarounds. BOOST_STRICT_CONFIG: defined when the user is testing a new compiler version (one newer than boosts automatic config is aware of, and which may or may not require configuration), should disable compiler specific fixes only if the compiler version is greater than the last version we've tested. Remember these were designed for users, not compiler vendors. 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 ___ 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
Re: [boost] [Config] Testing instructions for compiler vendors
Gennaro Prota <[EMAIL PROTECTED]> writes: > --- 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 Hmm. Well, if it's non-conforming we probably shouldn't use it. If it's just a vc bug, we could do something like #ifndef BOOST_STRICT_CONFIG # ifdef BOOST_MSVC # define BOOST_WORKAROUND(symbol, test) BOOST_DEFINED_##symbol && symbol test # define BOOST_DEFINED_BOOST_MSVC BOOST_MSVC # define BOOST_DEFINED_BOOST_DINKUMWARE_STDLIB BOOST_DINKUMWARE_STDLIB ... # else # define BOOST_WORKAROUND(symbol, test) (defined(symbol) && symbol test) #else # define BOOST_WORKAROUND(symbol, test) 0 #endif -- 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
- 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
[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. -- 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
- 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
--- 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
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 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
Douglas Gregor <[EMAIL PROTECTED]> writes: > I like BOOST_COMPILER_WORKAROUND. We should use it and ban explicit references > to compiler/platform/library version macros outside of the config library > that don't use it. I'm convinced ;-) I think we should probably just call it BOOST_WORKAROUND, though: we might need to check library versions, too. -- 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 Wednesday 04 December 2002 03:27 pm, David Abrahams wrote: > 1. Should we do something to make this easier for them? Yeah, let's add a macro BOOST_HOLY_GRAIL to skip all workarounds :) > 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? I like BOOST_COMPILER_WORKAROUND. We should use it and ban explicit references to compiler/platform/library version macros outside of the config library that don't use it. Doug ___ 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'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? > > Not quite: > > BOOST_NO_CONFIG : turns off all checking for defects, Well, sure. But if they're just trying to check the core compiler and NOT the library, I don't think they want BOOST_NO_CONFIG, do they? And since that also turns of platform workarounds, it could get them into trouble with platform bugs over which they have no control, couldn't it? > IMO compiler specific fixes should be turned off by this as well (in > many cases this is all you need - certainly this is what I used for > testing a certain recent alpha compiler release...) Well, in my code I've been using BOOST_STRICT_CONFIG to turn off version-specific fixes. So we have a problem. > Then define: any macros that define features: BOOST_HAS_LONG_LONG > etc. Right, I guess that will tend to test more of the compiler. > Then define any defect macros you want to temporarily enable until the > compiler is fixed :-) OK. >> 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? > > That's not a bad idea IMO. #1 or #2? > Compiler vendors aren't necessarily typical boost users though :-) No, it's true. In some ways they're dumber. It seems as though the ability of compiler vendors to get the tests running properly if you don't hold their hand every step of the way is pretty low. That aside, I think if we don't use something like BOOST_COMPILER_WORKAROUND, we're bound to continue to have problems like deciding whether to check BOOST_STRICT_CONFIG or BOOST_NO_CONFIG. Not to mention the fact that simply writing these sorts of checks is error-prone and makes the code hard-to-read: #if defined(__SUNPRO_CC) && __SUNPRO_CC <= 0x540 && !defined(BOOST_NO_CONFIG) // workaround here #else ... #endif -- 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'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? Not quite: BOOST_NO_CONFIG : turns off all checking for defects, IMO compiler specific fixes should be turned off by this as well (in many cases this is all you need - certainly this is what I used for testing a certain recent alpha compiler release...) Then define: any macros that define features: BOOST_HAS_LONG_LONG etc. Then define any defect macros you want to temporarily enable until the compiler is fixed :-) > 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? That's not a bad idea IMO. Compiler vendors aren't necessarily typical boost users though :-) John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ 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
