[config] Macro proposal
Hi guys, could we please add something like this to the config system? #if defined(__GNUC_PATCHLEVEL__) # define <choose_a_name> ( __GNUC__ * 10000 \ + __GNUC_MINOR__ * 100 \ + __GNUC_PATCHLEVEL__ ) #else # define <choose_a_name> ( __GNUC__ * 10000 \ + __GNUC_MINOR__ * 100) #endif PS: of course it's possible to "share" the common part of the replacement-lists: ( __GNUC__ * 10000 + __GNUC_MINOR__ * 100) or (100 * ( __GNUC__ * 100 + __GNUC_MINOR__)) The decision is up to John :) --Gennaro.
Gennaro Prota wrote:
Hi guys,
could we please add something like this to the config system?
#if defined(__GNUC_PATCHLEVEL__) # define <choose_a_name> ( __GNUC__ * 10000 \ + __GNUC_MINOR__ * 100 \ + __GNUC_PATCHLEVEL__ ) #else # define <choose_a_name> ( __GNUC__ * 10000 \ + __GNUC_MINOR__ * 100) #endif
PS: of course it's possible to "share" the common part of the replacement-lists:
( __GNUC__ * 10000 + __GNUC_MINOR__ * 100)
or
(100 * ( __GNUC__ * 100 + __GNUC_MINOR__))
The decision is up to John :)
I've been working on making such changes for some time now <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostConfig>. But it's very slow going as I have almost no free time. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
On Wed, 14 Jun 2006 09:17:48 -0500, Rene Rivera <grafik.list@redshift-software.com> wrote:
I've been working on making such changes for some time now <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostConfig>. But it's very slow going as I have almost no free time.
Aha, thanks! Let me know if I can help (from a quick look at the wiki page I was under the impression that not all details are settled; if they are, instead, I can do the changes on the CVS repository) Rene, while you are here, thanks for the following workaround #if BOOST_WORKAROUND(__MWERKS__, <= 0x3003) // 8.x // CodeWarrior 8 generates incorrect code // when the &=~ is compiled, // use the |^ variation instead.. <grafik> m_bits[block_index(pos)] |= bit_mask(pos); m_bits[block_index(pos)] ^= bit_mask(pos); #else m_bits[block_index(pos)] &= ~bit_mask(pos); #endif in dynamic_bitset. IIUC, this went undetected by tests? If so, could you please provide a test snippet that I can add? --Gennaro.
Gennaro Prota wrote:
On Wed, 14 Jun 2006 09:17:48 -0500, Rene Rivera <grafik.list@redshift-software.com> wrote:
I've been working on making such changes for some time now <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostConfig>. But it's very slow going as I have almost no free time.
Aha, thanks! Let me know if I can help (from a quick look at the wiki page I was under the impression that not all details are settled; if they are, instead, I can do the changes on the CVS repository)
There's always some details to settle :-) In my local copy of that page I think I've "decided" on some of the missing details. I'll put up my newest set of comments today, and newest set of changes. I've been putting the code changes in a branch, BOOST_VERSION_NUMBER, of boost/config and boost/config.hpp, boost/config/*, and libs/config/*.
Rene, while you are here, thanks for the following workaround
Your welcome.
#if BOOST_WORKAROUND(__MWERKS__, <= 0x3003) // 8.x // CodeWarrior 8 generates incorrect code // when the &=~ is compiled, // use the |^ variation instead.. <grafik> m_bits[block_index(pos)] |= bit_mask(pos); m_bits[block_index(pos)] ^= bit_mask(pos); #else m_bits[block_index(pos)] &= ~bit_mask(pos); #endif
in dynamic_bitset. IIUC, this went undetected by tests? If so, could you please provide a test snippet that I can add?
Hm, if I remember correctly, there was a test where this showed up. But I don't remember which one. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Gennaro Prota wrote:
On Wed, 14 Jun 2006 09:17:48 -0500, Rene Rivera <grafik.list@redshift-software.com> wrote:
I've been working on making such changes for some time now <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostConfig>. But it's very slow going as I have almost no free time. Aha, thanks! Let me know if I can help (from a quick look at the wiki page I was under the impression that not all details are settled; if they are, instead, I can do the changes on the CVS repository)
There's always some details to settle :-) In my local copy of that page I think I've "decided" on some of the missing details. I'll put up my newest set of comments today, and newest set of changes. I've been putting the code changes in a branch, BOOST_VERSION_NUMBER, of boost/config and boost/config.hpp, boost/config/*, and libs/config/*.
OK, it turns out I had already checked in all the changes I had so far. And I updated the wiki page. And yes any help in implementation, documentation, and testing is appreciated. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
On Wed, 14 Jun 2006 13:14:40 -0500, Rene Rivera <grafik.list@redshift-software.com> wrote:
Rene Rivera wrote: OK, it turns out I had already checked in all the changes I had so far. And I updated the wiki page. And yes any help in implementation, documentation, and testing is appreciated.
Very good job. The only part I think I've not understood completely is the issues section: particularly the sentence "The only option I can think of is to go ahead and define the corresponding version macro and have the code deal with the multiple defs." Considering, for instance, Comeau with _MSC_VER defined, you mean user code would need to do: #if BOOST_WORKAROUND(BOOST_CXX_COMO, == ...) && \ (defined _MSC_VER && _MSC_VER == ...) ? That seems acceptable to me. --Gennaro.
Gennaro Prota wrote:
On Wed, 14 Jun 2006 13:14:40 -0500, Rene Rivera <grafik.list@redshift-software.com> wrote:
Rene Rivera wrote: OK, it turns out I had already checked in all the changes I had so far. And I updated the wiki page. And yes any help in implementation, documentation, and testing is appreciated.
Very good job. The only part I think I've not understood completely is the issues section: particularly the sentence
"The only option I can think of is to go ahead and define the corresponding version macro and have the code deal with the multiple defs."
Considering, for instance, Comeau with _MSC_VER defined, you mean user code would need to do:
#if BOOST_WORKAROUND(BOOST_CXX_COMO, == ...) && \ (defined _MSC_VER && _MSC_VER == ...)
? That seems acceptable to me.
Close... The second use would also use the standard macros. Hence: #if BOOST_WORKAROUND(BOOST_CXX_COMO, == BOOST_VERSION_NUMBER(?,?,?)) &&\ BOOST_WORKAROUND(BOOST_CXX_MSVC, == BOOST_VERSION_NUMBER(?,?,?)) In one of the previous discussions Dave mentioned that optimizing the BOOST_WORKAROUND macro to be more terse. For example: #if BOOST_WORKAROUND(BOOST_CXX_COMO,==,?,?,?) &&\ BOOST_WORKAROUND(BOOST_CXX_MSVC,==,?,?,?) Or something like that :-) But that would be work to do after the core config changes are done. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
On Wed, 14 Jun 2006 14:10:21 -0500, Rene Rivera <grafik.list@redshift-software.com> wrote:
Gennaro Prota wrote:
[...]
Considering, for instance, Comeau with _MSC_VER defined, you mean user code would need to do:
#if BOOST_WORKAROUND(BOOST_CXX_COMO, == ...) && \ (defined _MSC_VER && _MSC_VER == ...)
? That seems acceptable to me.
Close... The second use would also use the standard macros. Hence:
#if BOOST_WORKAROUND(BOOST_CXX_COMO, == BOOST_VERSION_NUMBER(?,?,?)) &&\ BOOST_WORKAROUND(BOOST_CXX_MSVC, == BOOST_VERSION_NUMBER(?,?,?))
That's why I asked :) It was my understanding that *either* BOOST_CXX_COMO is defined *or* BOOST_CXX_MSVC, so one couldn't do that (BOOST_CXX_MSVC being only defined for the "true" VC++).
In one of the previous discussions Dave mentioned that optimizing the BOOST_WORKAROUND macro to be more terse. For example:
#if BOOST_WORKAROUND(BOOST_CXX_COMO,==,?,?,?) &&\ BOOST_WORKAROUND(BOOST_CXX_MSVC,==,?,?,?)
Or something like that :-) But that would be work to do after the core config changes are done.
Nice :) I'm inclined to go directly for that (actually the commas could be eliminated as well, but that would require some preprocessing magic which we already preferred not to have when deciding the first implementation of BOOST_WORKAROUND(); see, for instance http://lists.boost.org/Archives/boost/2002/12/40843.php ) --Gennaro.
Gennaro Prota <gennaro_prota@yahoo.com> writes:
On Wed, 14 Jun 2006 14:10:21 -0500, Rene Rivera <grafik.list@redshift-software.com> wrote:
In one of the previous discussions Dave mentioned that optimizing the BOOST_WORKAROUND macro to be more terse. For example:
#if BOOST_WORKAROUND(BOOST_CXX_COMO,==,?,?,?) &&\ BOOST_WORKAROUND(BOOST_CXX_MSVC,==,?,?,?)
Or something like that :-) But that would be work to do after the core config changes are done.
Nice :) I'm inclined to go directly for that (actually the commas could be eliminated as well, but that would require some preprocessing magic which we already preferred not to have when deciding the first implementation of BOOST_WORKAROUND(); see, for instance
I don't see that conclusion there, but I have to say that I don't think whitespace is particularly better than commas here. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Wed, 14 Jun 2006 17:42:47 -0400, David Abrahams <dave@boost-consulting.com> wrote:
Gennaro Prota <gennaro_prota@yahoo.com> writes:
[eliminating commas...] would require some preprocessing magic which we already preferred not to have when deciding the first implementation of BOOST_WORKAROUND(); see, for instance
I don't see that conclusion there, but I have to say that I don't think whitespace is particularly better than commas here.
Yup, let me wear the boost historian hat :-O That post was the end - almost 4 years ago! - of the long "[boost] [Config] Testing instructions for compiler vendors" thread: http://lists.boost.org/Archives/boost/2002/12/index.php whose last part was mainly between you, Paul Mensonides and me. Among the several syntax choices we went so far to consider things like: BOOST_WORKAROUND(__SUNPRO_CC, (!) <= 0x530) I opposed that one (and other similar) because they required several pp-lib tricks and "primitives", for the only benefit of a nice syntax. Despite some divergence on details, we basically all agreed that something simpler was in order (see your last sentence here): http://lists.boost.org/Archives/boost/2002/12/41337.php John also expressed along the same lines: http://lists.boost.org/Archives/boost/2002/12/41355.php and thus we had the BOOST_WORKAROUND() implementation that we all know :) --Gennaro.
On Wed, 14 Jun 2006 13:14:40 -0500, Rene Rivera <grafik.list@redshift-software.com> wrote:
OK, it turns out I had already checked in all the changes I had so far. And I updated the wiki page. And yes any help in implementation, documentation, and testing is appreciated.
I cleaned it up a bit, removing duplications and clarifying why 999999999 is the limit we consider for numbering (though we could go a bit further, as pointed out in a note). For the rest I fixed the gcc version definition for the case where the patch-level macro is not defined and other minor things. I didn't touch is the issues section, as... the issue is open :) --Gennaro.
Rene Rivera <grafik.list@redshift-software.com> writes:
Gennaro Prota wrote:
Hi guys,
could we please add something like this to the config system?
#if defined(__GNUC_PATCHLEVEL__) # define <choose_a_name> ( __GNUC__ * 10000 \ + __GNUC_MINOR__ * 100 \ + __GNUC_PATCHLEVEL__ ) #else # define <choose_a_name> ( __GNUC__ * 10000 \ + __GNUC_MINOR__ * 100) #endif
PS: of course it's possible to "share" the common part of the replacement-lists:
( __GNUC__ * 10000 + __GNUC_MINOR__ * 100)
or
(100 * ( __GNUC__ * 100 + __GNUC_MINOR__))
The decision is up to John :)
I've been working on making such changes for some time now <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostConfig>. But it's very slow going as I have almost no free time.
This is great and very complete. It looks like you've worked things out so completely that actually doing the coding should be pretty easy. There is one nit:
Some compilers, like Comeau C++, try and simulate other compilers. For them it is possible that some workarounds are dependent on the particular version of the compiler they are emulating. Here's some of those issues, as they come up:
* boost/config/compiler/comeau.hpp - It emulates VC, and has the _MSC_VER define.
* boost/config/compiler/intel.hpp - It emulates VC, and has the _MSC_VER define.
The only option I can think of is to go ahead and define the corresponding version macro and have the code deal with the multiple defs.
If I understand what you're suggesting correctly, I don't think that part is a very good idea, because the status quo is that Boost libraries expect BOOST_MSVC only to be defined when it really _is_ MSVC, and we go to some lengths to ensure it. I don't mind the idea of BOOST_CXX_EMULATED_MSVC or BOOST_CXX_MSC_VER though. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Rene Rivera <grafik.list@redshift-software.com> writes:
I've been working on making such changes for some time now <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostConfig>. But it's very slow going as I have almost no free time.
This is great and very complete. It looks like you've worked things out so completely that actually doing the coding should be pretty easy.
Thanks :-) But it's not the coding of what's described in the wiki that is laborious. It's the translation of all the Boost.Config code to use the new macros.
There is one nit:
Some compilers, like Comeau C++, try and simulate other compilers. For them it is possible that some workarounds are dependent on the particular version of the compiler they are emulating. Here's some of those issues, as they come up:
* boost/config/compiler/comeau.hpp - It emulates VC, and has the _MSC_VER define.
* boost/config/compiler/intel.hpp - It emulates VC, and has the _MSC_VER define.
The only option I can think of is to go ahead and define the corresponding version macro and have the code deal with the multiple defs.
If I understand what you're suggesting correctly, I don't think that part is a very good idea, because the status quo is that Boost libraries expect BOOST_MSVC only to be defined when it really _is_ MSVC, and we go to some lengths to ensure it. I don't mind the idea of
BOOST_CXX_EMULATED_MSVC
or
BOOST_CXX_MSC_VER
though.
Well others will want to comment on their expectations. The tipping point for me in the direction I suggest is that I found many instances in current Boost code where there was only reference to _MSC_VER, with the expectation that it would apply in both real and simulated modes. SO it's not translating the use of BOOST_MSVC that worries me, it's the translation of all the _MSC_VER uses. Should they be converted to BOOST_CXX_EMUALTED_MSVC or to BOOST_CXX_MSVC? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Well others will want to comment on their expectations. The tipping point for me in the direction I suggest is that I found many instances in current Boost code where there was only reference to _MSC_VER, with the expectation that it would apply in both real and simulated modes. SO it's not translating the use of BOOST_MSVC that worries me, it's the translation of all the _MSC_VER uses. Should they be converted to BOOST_CXX_EMUALTED_MSVC or to BOOST_CXX_MSVC?
Aren't 99.9999% of those just checks around #pragma once ? What benefit does BOOST_CXX_EMUALTED_MSVC provide over _MSV_VER anyway given that the two will always be identical? John.
I changed the subject line as this is of more interest than the original title could suggest. For those who are just tuned in, there's ongoing work for having a more consistent and rational identification system for supported compilers, platforms and standard libraries. A wiki page is at http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostConfig and contributions are welcome, especially for macro definitions marked with '?'. Previous discussion has raised at least two important points: * the amount of work needed for conversion to the new system (either of the Boost.Config code itself and of client code) is non negligible and will take time * a choice is needed for compilers which offer emulation modes, e.g. Comeau C++, which defines _MSC_VER when emulating VC++. I want to add another couple of remarks * the BOOST_TESTED_AT macro; it seems we forgot about this, but we should be able to write: #if BOOST_WORKAROUND (BOOST_CXX_MSVC, BOOST_TESTED_AT(...)) or its moral equivalent. This means that either BOOST_TESTED_AT or BOOST_WORKAROUND can't have the current and the proposed syntax, respectively 2) rather than doing all the #ifdef/define/endif machine in suffix.hpp, wouldn't it be more elegant to have a prefix.hpp? // at the top of config.hpp #include <boost/config/prefix.hpp> // in prefix.hpp #define BOOST_ABSENT() 0 // Comeau C++ #define BOOST_CXX_COMO BOOST_ABSENT() // Digital Mars C++ #define BOOST_CXX_DMC BOOST_ABSENT() // Intel C++ #define BOOST_CXX_INTELC BOOST_ABSENT() // GNU C++ #define BOOST_CXX_GNUC BOOST_ABSENT() .... Cheers, --Gennaro.
Gennaro Prota <gennaro_prota@yahoo.com> writes:
* the BOOST_TESTED_AT macro; it seems we forgot about this, but we should be able to write:
#if BOOST_WORKAROUND (BOOST_CXX_MSVC, BOOST_TESTED_AT(...))
or its moral equivalent. This means that either BOOST_TESTED_AT or BOOST_WORKAROUND can't have the current and the proposed syntax, respectively
BOOST_WORKAROUND(CXX_MSVC, <=, 7,1,0) BOOST_WORKAROUND(CXX_MSVC, tested_at, 7,1,0) is an implementable syntax. It might be possible to drop the 2nd comma, but I'm not sure of that and it might be too cute :) -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Thu, 15 Jun 2006 13:19:36 -0400, David Abrahams <dave@boost-consulting.com> wrote:
BOOST_WORKAROUND(CXX_MSVC, <=, 7,1,0) BOOST_WORKAROUND(CXX_MSVC, tested_at, 7,1,0)
is an implementable syntax.
I'd have three questions, but maybe it's quicker to ask directly: "can you post the implementation you are thinking to?"
It might be possible to drop the 2nd comma, but I'm not sure of that and it might be too cute :)
I see the irony, but I don't mind. If we introduce room for bugs in here it will be troubles for everyone (and, given the way preprocessing works, I can think of tens of ways such bugs could go unnoticed, even with unit tests) --Gennaro.
Gennaro Prota <gennaro_prota@yahoo.com> writes:
On Thu, 15 Jun 2006 13:19:36 -0400, David Abrahams <dave@boost-consulting.com> wrote:
BOOST_WORKAROUND(CXX_MSVC, <=, 7,1,0) BOOST_WORKAROUND(CXX_MSVC, tested_at, 7,1,0)
is an implementable syntax.
I'd have three questions, but maybe it's quicker to ask directly: "can you post the implementation you are thinking to?"
Sorry, what I was thinking of won't work because you can't paste anything onto "<=". But BOOST_WORKAROUND(CXX_MSVC, <=, 7,1,0) BOOST_WORKAROUND(CXX_MSVC, BOOST_TESTED_AT, 7,1,0) ought to work. Something like: # ifndef BOOST_STRICT_CONFIG # define BOOST_WORKAROUND(symbol, test, major, minor, subminor) \ ((symbol != 0) \ && (1 % (( ( \ symbol test( BOOST_VERSION(major,minor,subminor))) ) + 1))) # ifdef BOOST_DETECT_OUTDATED_WORKAROUNDS # define BOOST_OPEN_PAREN ( # define BOOST_TESTED_AT(value) > value) ?(-1): BOOST_OPEN_PAREN 1 # else # define BOOST_TESTED_AT(value) != ((value)-(value)) # endif # else # define BOOST_WORKAROUND(symbol, test, major, minor, subminor) 0 # endif -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Sat, 17 Jun 2006 07:06:38 -0400, David Abrahams <dave@boost-consulting.com> wrote:
Gennaro Prota <gennaro_prota@yahoo.com> writes:
On Thu, 15 Jun 2006 13:19:36 -0400, David Abrahams <dave@boost-consulting.com> wrote:
BOOST_WORKAROUND(CXX_MSVC, <=, 7,1,0) BOOST_WORKAROUND(CXX_MSVC, tested_at, 7,1,0)
is an implementable syntax.
I'd have three questions, but maybe it's quicker to ask directly: "can you post the implementation you are thinking to?"
Sorry, what I was thinking of won't work because you can't paste anything onto "<=".
Yeah, that was one of the issues I was wondering about; you could have been thinking of a technique which didn't involve token pasting :) Anyway, one could of course use identifiers instead of <= and other operators. Attached is an implementation which maps "<" to "below", ">" to "above", etc. Two of the possible invocation forms would be: BOOST_WORKAROUND(CXX_MSVC, last_tested, (8, 0, 0)) BOOST_WORKAROUND(CXX_MSVC, up_to, (9, 0, 0)) Note that "CXX_MSVC" is used, though the macro actually defined is "BOOST_CXX_MSVC" and that the version numbers are grouped into a tuple (though this isn't necessary for the machinery to work). There's still the comma before the tuple, as I didn't want to carry the house of cards too far. A further easy step would be to enable a generic placeholder, say 'x', for minor and patch numbers, so that something like BOOST_WORKAROUND(CXX_CW, last_tested, (9, x, x)) // CodeW. 9.x would be valid. The big problem about all this is, as you know, that BOOST_PP_IS_UNARY isn't guaranteed to work everywhere, which is why Paul didn't make it part of the pp-lib interface. It *should* work on this scenario but I'm not sure. -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ] begin 644 Source1.cpp M+R\C9&5F:6YE($)/3U-47T1%5$5#5%]/551$051%1%]73U)+05)/54Y$4PT* M#0HC:6YC;'5D92`B8F]O<W0O<')E<')O8V5S<V]R+V-O;G1R;VPO:6EF+FAP M<"(-"B-I;F-L=61E(")B;V]S="]P<F5P<F]C97-S;W(O='5P;&4O96%T+FAP M<"(-"B-I;F-L=61E(")B;V]S="]P<F5P<F]C97-S;W(O;&]G:6-A;"]C;VUP M;"YH<'`B#0H-"B-I;F-L=61E(")B;V]S="]P<F5P<F]C97-S;W(O9&5T86EL M+VES7W5N87)Y+FAP<"(@+R\@3D(A(2$-"@T*#0HO+R`M+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2T-"@T*(V1E9FEN92!"3T]35%])4U],05-47U1%4U1%1"AE*2`@("`@("`@ M("`@("`@("`@("`@("`@("!<#0H@("`@0D]/4U1?4%!?24E&*"`@("`@("`@ M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@(%P-"B`@("`@("`@0D]/ M4U1?4%!?25-?54Y!4EDH($)/3U-47U9%4E-)3TY?(",C(&4@*"A^*2D@*2`@ M7`T*("`@("`@+"!"3T]35%])4U],05-47U1%4U1%1%])("`@("`@("`@("`@ M("`@("`@("`@("`@("!<#0H@("`@("`L(#`@0D]/4U1?4%!?5%503$5?14%4 M*#$I("`@("`@("`@("`@("`@("`@("`@("`@(%P-"B`@("`I*&4I("`@("`@ M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@+RHJ+PT* M#0HC9&5F:6YE($)/3U-47TE37TQ!4U1?5$535$5$7TDH92D@("`@("`@7`T* M("`@($)/3U-47U!07T-/35!,*"!"3T]35%]04%])4U]53D%262@@(%P-"B`@ M("`@("`@0D]/4U1?5D524TE/3E\@(R,@92@@("`@("`@("`@("!<#0H@("`@ M("`@("`@("!"3T]35%]615)324].7VQA<W1?=&5S=&5D("`@7`T*("`@("`@ M("`I*"A^*2D@("`@("`@("`@("`@("`@("`@("`@("`@(%P-"B`@("`I("D@ M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`O*BHO#0H-"B-D969I;F4@ M0D]/4U1?5D524TE/3E]L87-T7W1E<W1E9"AX*2!X#0H-"@T*+R\@+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM#0H-"B-D969I;F4@0D]/4U1?5D524TE/3E].54U"15(H;6%J M;W(L(&UI;F]R+"!P871C:"D@7`T*("`@("@@*&UA:F]R*2HQ,#`J,3`P,#`P M=2`K("AM:6YO<BD@*B`Q,#`P,#!U("L@*'!A=&-H*2`I("\J*B\-"@T*+R\@ M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM#0H-"B-D969I;F4@0D]/4U1?5T]22T%23U5.1"AS M>6UB;VPL('1E<W0L('9T=7!L92D@(%P-"B`@("`H("`@*"A"3T]35%\C(W-Y M;6)O;"D@(3T@,"D@)B8@("`@("`@("`@("`@(%P-"B`@("`@("`@0D]/4U1? M5T]22T%23U5.1%])35!,*$)/3U-47R,C<WEM8F]L("`@(%P-"B`@("`@("`@ M+"!T97-T("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@(%P-"B`@ M("`@("`@+"!"3T]35%]615)324].7TY534)%4B!V='5P;&4I("`@("`@("`@ M(%P-"B`@("`I("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@ M("`@("\J*B\-"@T*#0HC9&5F:6YE($)/3U-47U=/4DM!4D]53D1?24U03"AS M>6UB;VPL('1E<W0L('9E<BD@("`@("`@("`@7`T*("`@("@@("`@0D]/4U1? M4%!?24E&*"`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@(%P- M"B`@("`@("`@("`@($)/3U-47TE37TQ!4U1?5$535$5$*'1E<W0I("`@("`@ M("`@("`@("`@("`@("!<#0H@("`@("`@("`@("`L($)/3U-47U=/4DM!4D]5 M3D1?3$%35"AS>6UB;VPL('9E<BD@("`@("`@("`@7`T*("`@("`@("`@("`@ M+"!"3T]35%]73U)+05)/54Y$7TY/4DU!3"AS>6UB;VPL('1E<W0L('9E<BD@ M(%P-"B`@("`@("`@("D@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@ M("`@("`@("`@("`@("`@("!<#0H@("`@("`@("`@("`@("`@("`@("`@("`@ M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@7`T*("`@("D@("`@ M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@ M("\J*B\-"@T*(VEF9&5F($)/3U-47T1%5$5#5%]/551$051%1%]73U)+05)/ M54Y$4PT*(V1E9FEN92!"3T]35%]73U)+05)/54Y$7TQ!4U0H<WEM8F]L+"!V M97(I(%P-"B`@("`H("@H=F5R*2\H=F5R*2D@+R`H("AS>6UB;VPI(#X@*'9E M<BD@/R`P(#H@,2`I("D-"B-E;'-E#0HC9&5F:6YE($)/3U-47U=/4DM!4D]5 M3D1?3$%35"AS>6UB;VPL('9E<BD@*"AV97(I+RAV97(I*0T*(V5N9&EF#0H- M"B-D969I;F4@0D]/4U1?5T]22T%23U5.1%].3U)-04PH<WEM8F]L+"!T97-T M+"!V97(I(%P-"B`@("`H("AS>6UB;VPI($)/3U-47U9%4E-)3TY?(R-T97-T M("AV97(I("D-"@T*+R\@+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM#0HO+R!3>6YT87@@97AA M;7!L97,Z#0HO+PT*+R\@0D]/4U1?5T]22T%23U5.1"A#6%A?35-60RP@=7!? M=&\L("@Q+"`R+"`S*2D-"B\O($)/3U-47U=/4DM!4D]53D0H0UA87TU35D,L M('1E<W1E9%]A="P@*#$L(#(L(#,I*0T*+R\-"B\O($ET('=O=6QD(&)E('!O M<W-I8FQE('1O(&5N86)L92!T:&4@<'`M=&]K96X@?'A\(&%S('!L86-E:&]L M9&5R#0HO+R!F;W(@;6EN;W(@86YD('!A=&-H(&YU;6)E<G,-"B\O#0HO+R!" M3T]35%]73U)+05)/54Y$*$-86%]-4U9#+"!B96QO=R`H."P@,"P@>"DI#0HO M+PT*(V1E9FEN92!"3T]35%]615)324].7V)E;&]W("`@("`@("`@/`T*(V1E M9FEN92!"3T]35%]615)324].7W5P7W1O("`@("`@("`@/#T-"B-D969I;F4@ M0D]/4U1?5D524TE/3E]A8F]V92`@("`@("`@(#X-"B-D969I;F4@0D]/4U1? M5D524TE/3E]O;G=A<F0@("`@("`@(#X-"B-D969I;F4@0D]/4U1?5D524TE/ M3E]O=&AE<E]T:&5N("`@("$]#0HC9&5F:6YE($)/3U-47U9%4E-)3TY?97%U M86P@("`@("`@("`]/0T*#0H-"@T*#0HC9&5F:6YE($)/3U-47T-86%]-4U9# M($)/3U-47U9%4E-)3TY?3E5-0D52*#@L(#`L(#`I#0H-"B-D969I;F4@0UA8 M7TU35D,@)3TD*24])2$])2DF*"`O+R!C86XG="!I;G1E<F9E<F4@/"TM#0H- M"FEN="!M86EN*"D-"GL-"B`@("!"3T]35%]73U)+05)/54Y$*$-86%]-4U9# M+"!L87-T7W1E<W1E9"P@*#@L(#`L(#`I*3L-"B`@("!"3T]35%]73U)+05)/ E54Y$*$-86%]-4U9#+"!U<%]T;RP@*#DL(#`L(#`I*3L-"GT-"E]7 ` end
Rene Rivera <grafik.list@redshift-software.com> writes:
The tipping point for me in the direction I suggest is that I found many instances in current Boost code where there was only reference to _MSC_VER, with the expectation that it would apply in both real and simulated modes. SO it's not translating the use of BOOST_MSVC that worries me, it's the translation of all the _MSC_VER uses. Should they be converted to BOOST_CXX_EMUALTED_MSVC or to BOOST_CXX_MSVC?
Either they should be left alone (how many are checking the version number?) or they should be converted to the former. The latter should be reserved for the real thing. Otherwise, what would we turn BOOST_MSVC into? BOOST_CXX_REAL_MSVC? That seems a bit perverse. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (4)
-
David Abrahams -
Gennaro Prota -
John Maddock -
Rene Rivera