[config] Last call for choosing macro names
Hi guys, I've just committed a prefix file with the new macro names that will be used for compiler identification: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostConfig> This is basically your last chance to point out better names for them; I've marked with a comment the ones which diverge significantly from the built-in identification macro names (e.g.: BOOST_CXX_CW, whereas the built-macro is named __MWERKS__). The file is in /boost/config: <http://boost.cvs.sourceforge.net/boost/boost/boost/config/prefix.hpp?revision=1.1&view=markup> One other issue: suppose a compiler defines M=0xMMmmpp to indicate version MM.mm.pp (a common case). Let's take 0x030411 as an example. Now, since we want the user to be able to write: #if BOOST_CXX_FOO == BOOST_VERSION_NUMBER(3, 4, 11) // (a) we have to define BOOST_CXX_FOO in a way that "transforms the single parts" of M as if they were expressed in decimal. If we simply take M & 0xFF as sub-minor version number then it actually results in 17 (11 base sixteen) and (a) will never be true. So, is it my understanding correct that what we want to do is some machinery like this? #define SUBMINOR \ ( (M & 0xF) + 10* ((M & 0xF0)>>4) ) #define MINOR \ ( ((M & 0x0F00) >> 8) + (10* ((M & 0xF000)>> 12)) ) #define MAJOR \ ( ((M & 0x0F0000) >> 16) + (10 * (( M &0xF00000) >> 20) )) #define BOOST_CXX_FOO \ BOOST_VERSION_NUMBER(MAJOR, MINOR, SUBMINOR) (note the various multiplications by 10, to "interpret" everything as decimal) -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]
Gennaro Prota wrote:
This is basically your last chance to point out better names for them;
I think we might as well change the CW one to MWERKS. For Intel we could use BOOST_CXX_INTEL, as there's already the BOOST_INTEL macro which presumably is getting used everywhere in Boost code. BOOST_CXX_ACC could be changed to BOOST_CXX_HPACC as that would match the _HPACC_ of the compiler, as opposed to the __HP_aCC version macro. -- -- 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:
I think we might as well change the CW one to MWERKS.
The current name used by marketing is "Code Warrior". http://www.freescale.com/webapp/sps/site/homepage.jsp?nodeId=012726 /Pavel
on 7/8/06 4:01 PM, Pavel Vozenilek at pavel_vozenilek@hotmail.com wrote:
"Rene Rivera" wrote:
I think we might as well change the CW one to MWERKS.
The current name used by marketing is "Code Warrior". http://www.freescale.com/webapp/sps/site/homepage.jsp?nodeId=012726
The compiler/product has always been CodeWarrior (one word) while Metrowerks was the company. The compiler will likely always use MWERKS internally for legacy reasons but Metrowerks has long been absorbed into Freescale. Chris
"Gennaro Prota" wrote:
I've just committed a prefix file with the new macro names that will be used for compiler identification:
<http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostConfig>
Windows and Linux Intel compilers are quite different beasts (one pretending to be VC, the other GCC). The planned obsolence of separate macros doesn't feel good to me. Rogue Wave STL now lives under name stdcxx (http://incubator.apache.org/projects/stdcxx.html) Copenhagen STL (http://www.cphstl.dk/) still shows some sign of life. I am not sure whether BOOST_CXX_DEC will be recognised after so many name changes. Possibly something for Win64 platform could be defined. /Pavel
On Sat, 8 Jul 2006 21:59:15 +0200, "Pavel Vozenilek" <pavel_vozenilek@hotmail.com> wrote:
Windows and Linux Intel compilers are quite different beasts (one pretending to be VC, the other GCC).
I know. Both pretending to be worse a compiler than itself :-/ But this is already managed by the config system, isn't it? Compiler and platform are dealt with orthogonally.
The planned obsolence of separate macros doesn't feel good to me.
Rogue Wave STL now lives under name stdcxx (http://incubator.apache.org/projects/stdcxx.html)
Copenhagen STL (http://www.cphstl.dk/) still shows some sign of life.
Yep. How much energy waste. And we don't have a conforming standard library yet.
I am not sure whether BOOST_CXX_DEC will be recognised after so many name changes.
Suggestion? :)
Possibly something for Win64 platform could be defined.
I didn't get this. Just to be sure we are on the same wavelength, so far I've only introduced macros for compilers. Also, I'm just considering compilers/libraries/platforms which are *already* supported by the config system. PS: no hope about having info for Green Hills: I wrote to their support and they forwarded the mail to an Italian company which manages user requests; they in turn replied with a copy of a page of the manual, but when I asked what the *format* for the version number was they didn't reply anymore. I got the definite impression they didn't know what they were talking about. -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]
"Gennaro Prota" wrote:
Windows and Linux Intel compilers are quite different beasts (one pretending to be VC, the other GCC).
I know. Both pretending to be worse a compiler than itself :-/ But this is already managed by the config system, isn't it? Compiler and platform are dealt with orthogonally.
The danger I see is that people will use the generic macro for both variants when they tested only one. I did.
I am not sure whether BOOST_CXX_DEC will be recognised after so many name changes.
Suggestion? :)
Tru64 I guess there won't be any more reincarnations before it goes away.
PS: no hope about having info for Green Hills: I wrote to their support and they forwarded the mail to an Italian company which manages user requests; they in turn replied with a copy of a page of the manual, but when I asked what the *format* for the version number was they didn't reply anymore. I got the definite impression they didn't know what they were talking about.
"Green Hills Software doesn't just drive a truck up to your loading dock, shove the software off the back, and drive away. Green Hills Software provides comprehensive and continuous service and support to ensure that you get all of the benefits that the most advanced software development technology has to offer".
/Pavel
On Sun, 9 Jul 2006 19:57:48 +0200, "Pavel Vozenilek" <pavel_vozenilek@hotmail.com> wrote:
"Green Hills Software doesn't just drive a truck up to your loading dock, shove the software off the back, and drive away. Green Hills Software provides comprehensive and continuous service and support to ensure that you get all of the benefits that the most advanced software development technology has to offer".
I don't know what kind of company GHS is, but I can tell for sure that *all* companies which have Italian branch offices or subsidiaries have exactly the same problems. And I'm referring of the biggest names of the software industry. OTOH, I don't think boost really cares about their compiler so... "Non ragioniam di lor, ma guarda e passa" ;) -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]
This is basically your last chance to point out better names for them; I've marked with a comment the ones which diverge significantly from the built-in identification macro names (e.g.: BOOST_CXX_CW, whereas the built-macro is named __MWERKS__). The file is in /boost/config:
Personally I would drop the C from BOOST_CXX_INTELC. John.
Hi Gennaro, On 7/8/06, Gennaro Prota <gennaro_prota@yahoo.com> wrote:
I've just committed a prefix file with the new macro names that will be used for compiler identification:
<http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostConfig>
The page asks for a few incomplete bits to be filled in - I've just filled in the necessary bits for HP aCC, which I'm sure you'll want to update your version with. I've also corrected the spelling of Tru64 - it's not True64, which I've seen in the Boost source before. See http://h30097.www3.hp.com/ for how the vendor spells it :-) Michael
Thanks to all of you for your suggestions. They are now applied in the CVS trunk. Michael is right about the wrong spelling of "Tru": many files have "True"; I'll fix "compaq_cxx.hpp" and leave others to the respective authors. Feel free to leave further comments and please let me know if the other final 'C's, such as in "BORLANDC" and "GNUC" are ok to you or not (on one hand they match the predefined macro name, on the other one they are inconsistent) -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]
On Saturday 08 July 2006 20:58, Gennaro Prota wrote:
I've just committed a prefix file with the new macro names that will be used for compiler identification:
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostConfig
// Microsoft Visual C++ #ifndef BOOST_CXX_MSVC #define BOOST_CXX_MSVC 0 #endif I'm against that. The point is that Visual C++ is a product name which includes a compiler. However, MS include their compiler into other products, too, e.g. an SDK to cross-compile for 64 bit, the (discontinued/merged, but still used) embedded Visual Studios or Platform Builder. If the above macro is used like it sometimes is, it further blurs the difference between the compiler, the standardlibrary and the available OS API (i.e. the SDK). In my experience this leads to people meaning one thing but creating a preprocessor check for something that is only related. BTW: in case anyone wonders, in my experience the MS compilers are 99% bug-to-bug compatible, no matter if they target the desktop win32 or any of the CE targets. I don't have any experience with the 64 bit targets, though, but what I heard is that they mostly behave the same. I'd suggest either *_MS or *_MICROSOFT, including a list of products saying which compiler versions are included there to help the ensuing initial confusion, here's the ones I know about: MSC12: - VC6 (Visual C++ 6) - eVC4 - eVC3(?, probably obsolete) - Platform Builder 4.2 MSC13.0: - VC7 (Visual Studio .Net 2002?) MSC13.10: - VC7.1 (Visual Studio .Net 2003?) - Platform Builder 5(?) MSC14: - VC8 (Visual Studio .Net 2005)
One other issue:
suppose a compiler defines M=0xMMmmpp to indicate version MM.mm.pp (a common case).
... which is a stupidity that makes people think that the version following 1.9 is 2.0. Should Boost support this half-knowledge? Or do you mean that the version number uses some kind of decimal in hex encoding?
Let's take 0x030411 as an example. Now, since we want the user to be able to write:
#if BOOST_CXX_FOO == BOOST_VERSION_NUMBER(3, 4, 11) // (a)
I'd prefer not to write this, because how would you express a different relationship than equality? Sometimes you simply want to say 'if major=2' or 'if major=3 and minor>2', so I'd rather need BOOST_CXX_FOO_MAJOR etc. I don't know if this discussion already took place and the rationale is somewhere else which I didn't look for, so I'll accept if you tell me that it's correct, but this just struck me as odd. Sorry for the noise in that case. Uli
Ulrich Eckhardt <doomster@knuut.de> writes:
Let's take 0x030411 as an example. Now, since we want the user to be able to write:
#if BOOST_CXX_FOO == BOOST_VERSION_NUMBER(3, 4, 11) // (a)
I'd prefer not to write this, because how would you express a different relationship than equality? Sometimes you simply want to say 'if major=2'
These cases are comparitively rare #if BOOST_CXX_FOO >= BOOST_VERSION_NUMBER(2,0,0) \ && BOOST_CXX_FOO < BOOST_VERSION_NUMBER(3,0,0)
or 'if major=3 and minor>2', so I'd rather need BOOST_CXX_FOO_MAJOR etc.
#if BOOST_CXX_FOO >= BOOST_VERSION_NUMBER(3,2,0) \ && BOOST_CXX_FOO < BOOST_VERSION_NUMBER(4,0,0) -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Sun, 16 Jul 2006 21:02:30 -0400, David Abrahams <dave@boost-consulting.com> wrote:
These cases are comparitively rare
#if BOOST_CXX_FOO >= BOOST_VERSION_NUMBER(2,0,0) \ && BOOST_CXX_FOO < BOOST_VERSION_NUMBER(3,0,0)
or 'if major=3 and minor>2', so I'd rather need BOOST_CXX_FOO_MAJOR etc.
#if BOOST_CXX_FOO >= BOOST_VERSION_NUMBER(3,2,0) \ && BOOST_CXX_FOO < BOOST_VERSION_NUMBER(4,0,0)
We can do better than that, stay tuned! :) The last piece of the puzzle, now, is choosing a migration plan. BOOST_WORKAROUND will have a different interface and I don't think it is feasible to replace all invocations in one sweep (though I haven't actually counted them) and even if it is the risk of destabilization is high. What about momentarily use BOOST_WORKAROUND_2 as name for the new macro and gradually do the transition? At the end, we would have just to change BOOST_WORKAROUND_2 to BOOST_WORKAROUND everywhere. Not that I like this too much but this is the only idea that I have. -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]
Gennaro Prota <gennaro_prota <at> yahoo.com> writes:
The last piece of the puzzle, now, is choosing a migration plan. BOOST_WORKAROUND will have a different interface and I don't think it is feasible to replace all invocations in one sweep (though I haven't actually counted them) and even if it is the risk of destabilization is high. What about momentarily use BOOST_WORKAROUND_2 as name for the new macro and gradually do the transition? At the end, we would have just to change BOOST_WORKAROUND_2 to BOOST_WORKAROUND everywhere. Not that I like this too much but this is the only idea that I have.
Why not rename BOOST_WORKAROUND to BOOST_WORKAROUND_OLD or similar, do a global replace and use the now vacant BOOST_WORKAROUND id for the new stuff? Unlike the global replace you talk about, the one required for this procedure is totally harmless and I'd say its associated risk of destabilization is close to zero. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Gennaro Prota <gennaro_prota@yahoo.com> writes:
On Sun, 16 Jul 2006 21:02:30 -0400, David Abrahams <dave@boost-consulting.com> wrote:
These cases are comparitively rare
#if BOOST_CXX_FOO >= BOOST_VERSION_NUMBER(2,0,0) \ && BOOST_CXX_FOO < BOOST_VERSION_NUMBER(3,0,0)
or 'if major=3 and minor>2', so I'd rather need BOOST_CXX_FOO_MAJOR etc.
#if BOOST_CXX_FOO >= BOOST_VERSION_NUMBER(3,2,0) \ && BOOST_CXX_FOO < BOOST_VERSION_NUMBER(4,0,0)
We can do better than that, stay tuned! :) The last piece of the puzzle, now, is choosing a migration plan. BOOST_WORKAROUND will have a different interface and I don't think it is feasible to replace all invocations in one sweep (though I haven't actually counted them) and even if it is the risk of destabilization is high. What about momentarily use BOOST_WORKAROUND_2 as name for the new macro and gradually do the transition? At the end, we would have just to change BOOST_WORKAROUND_2 to BOOST_WORKAROUND everywhere. Not that I like this too much but this is the only idea that I have.
You might be able to do something like BOOST_WORKAROUND(CXX_GCC, VERSION <= (3)(4)(2)) as a transition step, and then when you're done, just make "VERSION" optional. That would also allow checking just major, or just major+minor versions: BOOST_WORKAROUND(CXX_GCC, VERSION <= (3)(4)) -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Mon, 17 Jul 2006 09:48:03 -0400, David Abrahams <dave@boost-consulting.com> wrote:
You might be able to do something like
BOOST_WORKAROUND(CXX_GCC, VERSION <= (3)(4)(2))
as a transition step, and then when you're done, just make "VERSION" optional. That would also allow checking just major, or just major+minor versions:
BOOST_WORKAROUND(CXX_GCC, VERSION <= (3)(4))
That's nice :) You know, I like it as much as you do, but I'd rather be safe than sorry. What about the approach proposed by Joaquin? -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]
Gennaro Prota <gennaro_prota@yahoo.com> writes:
On Mon, 17 Jul 2006 09:48:03 -0400, David Abrahams <dave@boost-consulting.com> wrote:
You might be able to do something like
BOOST_WORKAROUND(CXX_GCC, VERSION <= (3)(4)(2))
as a transition step, and then when you're done, just make "VERSION" optional. That would also allow checking just major, or just major+minor versions:
BOOST_WORKAROUND(CXX_GCC, VERSION <= (3)(4))
That's nice :) You know, I like it as much as you do, but I'd rather be safe than sorry. What about the approach proposed by Joaquin?
Please be specific; I don't know what he proposed. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Mon, 17 Jul 2006 15:46:25 -0400, David Abrahams <dave@boost-consulting.com> wrote:
BOOST_WORKAROUND(CXX_GCC, VERSION <= (3)(4))
That's nice :) You know, I like it as much as you do, but I'd rather be safe than sorry. What about the approach proposed by Joaquin?
Please be specific; I don't know what he proposed.
I guess you've seen his message by the time I write this. Anyway, here's a link: <http://lists.boost.org/Archives/boost/2006/07/107917.php> -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]
Gennaro Prota <gennaro_prota@yahoo.com> writes:
On Mon, 17 Jul 2006 15:46:25 -0400, David Abrahams <dave@boost-consulting.com> wrote:
BOOST_WORKAROUND(CXX_GCC, VERSION <= (3)(4))
That's nice :) You know, I like it as much as you do, but I'd rather be safe than sorry. What about the approach proposed by Joaquin?
Please be specific; I don't know what he proposed.
I guess you've seen his message by the time I write this. Anyway, here's a link:
Seems like it creates more churn than necessary, but I don't care all that much. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Gennaro Prota <gennaro_prota@yahoo.com> writes:
On Mon, 17 Jul 2006 15:46:25 -0400, David Abrahams <dave@boost-consulting.com> wrote:
BOOST_WORKAROUND(CXX_GCC, VERSION <= (3)(4)) That's nice :) You know, I like it as much as you do, but I'd rather be safe than sorry. What about the approach proposed by Joaquin? Please be specific; I don't know what he proposed. I guess you've seen his message by the time I write this. Anyway, here's a link:
Seems like it creates more churn than necessary, but I don't care all that much.
And it requires that it be done after the 1.34 release. As otherwise it would be very difficult to do merging as the number of diffs would be large and difficult to track. -- -- 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
participants (9)
-
Chris Little -
David Abrahams -
Gennaro Prota -
Joaquin M Lopez Munoz -
John Maddock -
Michael van der Westhuizen -
Pavel Vozenilek -
Rene Rivera -
Ulrich Eckhardt