September 2005 - Boost - lists.boost.org

Re: [boost] BOOST_ASSUME_review_needed?
by brangdon＠cix.compulink.co.uk 22 Sep '05

22 Sep '05

In-Reply-To: <4331E462.8000700(a)dcook.org> darren(a)dcook.org (Darren Cook) wrote (abridged): > But instead of adding BOOST_ASSUME() I'd prefer the use of _assume() in > BOOST_ASSERT be controlled by a define and off by default. It is a > relatively minor optimization so could just be enabled by those who need > the speed and know their code does not do ASSERT(false). If it is controlled by a #define, switching it on would usually affect a large amount of code, with many ASSERTs written by other people. It seems too risky to me. -- Dave Harris, Nottingham, UK.

1 0

[config] win32 identification macros
by Jonathan Turkanis 22 Sep '05

22 Sep '05

Hi, The header <boost/config/select_platform_config.hpp> contains the lines #elif defined(_WIN32) || defined(__WIN32__) || defined(WIN32) // win32: # define BOOST_PLATFORM_CONFIG "boost/config/platform/win32.hpp" Does anyone know why it's necessary to test __WIN32__ and WIN32? A quick test showed that vc6-7.1, cw8-9.4, como 4.3.3, gcc 3.4.2 (minGW), dmc, bcc 5.6.4, and intel 7.1-8.0 all define _WIN32. What's left over? Jonathan

3 6

Re: [boost] BOOST_ASSUME_review_needed?
by brangdon＠cix.compulink.co.uk 22 Sep '05

22 Sep '05

In-Reply-To: <loom.20050921T155516-756(a)post.gmane.org> nesotto(a)cs.aau.dk (Thorsten Ottosen) wrote (abridged): > I don't get it. If you put BOOST_ASSERT( false ) anywhere, then you > effectively say "never exceute this code". Otherwise there is an error > in the assertion itself. Although that's a reasonable point of view, it is not supported by the current documentation, according to which executing BOOST_ASSERT(false) is well-defined and not an error. With some configurations it will invoke boost::assertion_failed(), which will pop up a message box offering to ignore, abort or break into the debugger. As I said in my previous post, I find the current behaviour quite useful. I sometimes use assert as a convenient way of saying, "issue a warning message, but only in debug builds." I actually work with MFC and use their ASSERT macro rather than BOOST_ASSERT. From a selfish point of view I don't care what boost does here because it won't hurt me. My concern is that other people may have used BOOST_ASSERT the same way I use MFC ASSERT. If you're confident no-one has, fine - but I don't see anything in the documentation which says my use is wrong. The documentation does say, "The macro is intended to be used in Boost libraries", which I suppose means we don't need to worry about breaking end-user code. > (The effect of removing an assertion must not be any in a correct > program). Having assert expand to __assume would not be the same as removing it. -- Dave Harris, Nottingham, UK.

7 8

Re: [boost] Errors compiling multi_index hashed.cpp
by Martin Bonner 22 Sep '05

22 Sep '05

----Original Message---- From: David Crayford [mailto:david_crayford@fundi.com.au] Sent: 22 September 2005 15:32 To: boost(a)lists.boost.org Subject: Re: [boost] Errors compiling multi_index hashed.cpp >> 1. Globally search "__IBMCPP__" in the codebase (about 100 >> occurrences) and replace it with, say, BOOST_IBMCPP. >> This task should be simple if you're a Unix man. > > Nitto, I'm an MVS man, but SlickEdit is my friend...although > we do have UNIX systems services running as a task, so I suppose GREP > is the go. > >> 2. Compile your test code with a compiler switch >> defining the macro BOOST_IBMCPP to 600. I think in your case the >> compiler switch is -DBOOST_IBMCPP=600 >> 3. Shake and serve. >> > I'm crossing my fingers. It's define(DBOOST_IBMCPP=600) on MVS. Are you sure about that leading capital D? From a position of TOTAL ignorance of MVS, I would have expected: define(BOOST_IBMCPP=600) If I'm right, I assume this is a copy and paste error - but it might be a copy and paste error that creeps into your test! -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

1 0

Re: [boost] [scope_guard] New revisionavailable + namingconsideration
by Greer, Joe 22 Sep '05

22 Sep '05

Naming issues are always interesting. You could always use 'attention' when you want the guard to pay attention and 'at_ease' when you want it to remember its commands but not act upon them. 'dismiss' would then mean go have your coffee and be more permanent. joe

1 0

Re: [boost] Errors compiling multi_index hashed.cpp
by David Crayford 22 Sep '05

22 Sep '05

-----boost-bounces@list= s.boost.org wrote: ----- >To: boost(a)lists.boost.org >= ;From: Joaquín Mª López Muñoz >Sent by: boos= t-bounces(a)lists.boost.org >Date: 2005-09-22 07:27PM >Subject: R= e: [boost] Errors compiling multi_index hashed.cpp > >David C= rayford ha escrito: > >> >From: Joaquín Mª López= Muñoz >> >What is the value then of __IBMCPP__ on= your platform? > >> The version is 41060, as des= cribed in the doco snippet >abo defined the BOOST_ASSERT_CONFIG= macro and got the following >error (as expected). >> &= gt;> "Unknown compiler version - ple report the results". &g= t;> I suppos results ;-). Unf UNIX script on an MVS Any &g= t;ideas for a quick fix? > >The compiler version is 6.0, right?= If so, you might want to first >change >the definition of _= _IBMCPP__ to 600, it must lie somewhere inside >your stdlib = >includes (remember to backup first.). If this gets things to compile,>Boost.Config >maintainers should be contacted as for what the b= est method to handle >this is: >a possible approach is to repla= ce __IBMCPP__ for BOOST_IBMCPP >everywhere >in the Bo= ost code base and then define BOOST_IBMCPP in >boost/config/compile= r/vacpp.h so as to handle z/OS deviant case --but >anyway >I'm = sure John Maddock will have better ideas for solving this. > >J= oaquín M López Muñoz >Telefónica, Investigación y Desarroll= o > Thanks Joaquin, actually the z/OS release is 6. I t= ried changing __IBMCPP__ to 600 but it screwed the compile. "'CEE.SCEEH(ALGORITH)'", line 21.6: CCN5859 (S) #e= rror directive: This file to be used only with IBM z/OS C++ V1R2 and lat= er compilers. &n= bsp; = ; &n bsp; = ; &n= bsp; = ; &n bsp; = ; I'm new to this list, how do I contact J= ohn Maddock? BTW, I'm sorry if my mails are mang= led, it seems to be a problem with the lotus notes browser client.

1 0

Re: [boost] Errors compiling multi_index hashed.cpp
by Joaquín Mª López Muñoz 22 Sep '05

22 Sep '05

David Crayford ha escrito: > >From: Joaquín Mª López Muñoz > >What is the value then of __IBMCPP__ on your platform? > The version is 41060, as described in the doco snippet abo defined the BOOST_ASSERT_CONFIG macro and got the following error (as expected). > > "Unknown compiler version - ple report the results". > I suppos results ;-). Unf UNIX script on an MVS Any ideas for a quick fix? The compiler version is 6.0, right? If so, you might want to first change the definition of __IBMCPP__ to 600, it must lie somewhere inside your stdlib includes (remember to backup first.). If this gets things to compile, Boost.Config maintainers should be contacted as for what the best method to handle this is: a possible approach is to replace __IBMCPP__ for BOOST_IBMCPP everywhere in the Boost code base and then define BOOST_IBMCPP in boost/config/compiler/vacpp.h so as to handle z/OS deviant case --but anyway I'm sure John Maddock will have better ideas for solving this. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

BOOST_ASSERT and __assume on MSVC
by Marcin Kalicinski 22 Sep '05

22 Sep '05

Hi All, Have you considered modifying BOOST_ASSERT to use __assume on MSVC? Briefly speaking __assume(expr) is a hint for optimizer that 'expr' evaluates to nonzero. It can help optimize the code. Standalone use of __assume is not recommended because compiler does not check if the assumption is correct, and if it isn't the program is ill formed. But it fits perfectly in ASSERT macro. This way putting many ASSERTs will not only help to verify the code - it will also help the optimizer. Wow! To be sure I did a small test with MSVC: int f(int n) { // __assume(n == 0); if (n == 1) return 1; else return 0; } produces: xor eax, eax cmp DWORD PTR _n$[esp-4], 1 sete al ret 0 with __assume uncommented: xor eax, eax ret 0 And the comparison is gone. Microsoft docs for __assume are here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/ht… cheers, Marcin

5 9

Re: [boost] Errors compiling multi_index hashed.cpp
by David Crayford 22 Sep '05

22 Sep '05

-----boost-bounces@= lists.boost.org wrote: ----- >To: boost(a)lists.boost.org >From: Joaquín Mª López Muñoz >Sent by: = boost-bounces(a)lists.boost.org >Date: 2005-09-22 06:00PM >Subjec= t: Re: [boost] Errors compiling multi_index hashed.cpp > > >David Crayford ha escrito: > >> > Hi all, >&= gt; > >> > I've recently downloaded boost to run on an IBM= mainfram z/OS >system >> > (a port of vacpp). I'm tryin= g to compile >multi_index\example\hashed. >> > cpp (wh= ich I called stuff.cpp) >> > and I'm getting the following err= ors. I'm a relative newbie with >C++ >> > so I'm complet= ely bamboozled by the compiler errors. Help with >this >> &g= t; will be greatly appreciated as I am currently in the process of >= > > trying to convince management to switch to C++ from C, and boost >is >> > one of my big hitting selling points. >&= gt; > >> > "'DOC.USER.CPP(STUFF)'", line 47.60: CCN6281 (W= ) "offsetof" >cannot >> > be applied to "struct word_c= ounter_entry". It is not a POD >> > (plain old data) type.<= BR>> >This warning is harmless, check http://tinyurl.com/e44yvfor = info on >how to supress it. > >> I think this problem = is due to a difference in the version number >in the >> _= _IBMCPP__ macro. >> Although the z/OS compiler is ported fro= m VACPP the __IBMCPP__ >macro has a >> different ver= sion number. >> >> >From the z/OS 1.6 programming refe= rence: >> >> __IBMCPP__ C ++ Only. >> >> This macro indicates the version number of the z/OS C++ compiler. >The >> format of the version number that is provided by th= e macro is >integer >> PVRRM, where : P Represents the compi= ler product v 0 for C/370 v 1 >for >> AD/Cycle C/370 and C/C= ++ for MVS/ESA v 2 for OS/390 C/C++ and 4 for >z/OS >> C/C++= v 4 for z/OS C/C++ Release 2 and laterV Represents the >version numb= er >> RR Represents the release number M Represents the modificati= on >numberIn >> z/OS C/C++ Version 1 Release 6, the value of= the macro is 41060. > >I also think your problems must be some= how related to __IBMCPP__. >What is the value then of __I= BMCPP__ on your platform? >boost/config/compiler/vacpp.h triggers= an error if __IBMCPP__ > 600, >so I guess your value's l= ower than that. > >Joaquín M López Muñoz >Telefón= ica, Investigación y Desarrollo > >________ _______________________ 5F_= ______________ >Unsubscribe & other c= hanges: >http://lists.boost.org/mailman/listinfo.cgi/boost The version is 41060, as described in the doco snippet abo= ve. I defined the BOOST_ASSERT_CONFIG macro and got the following error (as expected). "Unknown compiler version - ple= ase run the configure tests and report the results". I suppos= e I had better run the configure tests and report the results ;-). Unf= ortunately I'm not going to have much luck running a UNIX script on an MVS = mainframe... Any ideas for a quick fix?

1 0

Re: [boost] Errors compiling multi_index hashed.cpp
by Joaquín Mª López Muñoz 22 Sep '05

22 Sep '05

David Crayford ha escrito: > > Hi all, > > > > I've recently downloaded boost to run on an IBM mainfram z/OS system > > (a port of vacpp). I'm trying to compile multi_index\example\hashed. > > cpp (which I called stuff.cpp) > > and I'm getting the following errors. I'm a relative newbie with C++ > > so I'm completely bamboozled by the compiler errors. Help with this > > will be greatly appreciated as I am currently in the process of > > trying to convince management to switch to C++ from C, and boost is > > one of my big hitting selling points. > > > > "'DOC.USER.CPP(STUFF)'", line 47.60: CCN6281 (W) "offsetof" cannot > > be applied to "struct word_counter_entry". It is not a POD > > (plain old data) type. This warning is harmless, check http://tinyurl.com/e44yv for info on how to supress it. > I think this problem is due to a difference in the version number in the > __IBMCPP__ macro. > Although the z/OS compiler is ported from VACPP the __IBMCPP__ macro has a > different version number. > > >From the z/OS 1.6 programming reference: > > __IBMCPP__ C ++ Only. > > This macro indicates the version number of the z/OS C++ compiler. The > format of the version number that is provided by the macro is integer > PVRRM, where : P Represents the compiler product v 0 for C/370 v 1 for > AD/Cycle C/370 and C/C++ for MVS/ESA v 2 for OS/390 C/C++ and 4 for z/OS > C/C++ v 4 for z/OS C/C++ Release 2 and laterV Represents the version number > RR Represents the release number M Represents the modification numberIn > z/OS C/C++ Version 1 Release 6, the value of the macro is 41060. I also think your problems must be somehow related to __IBMCPP__. What is the value then of __IBMCPP__ on your platform? boost/config/compiler/vacpp.h triggers an error if __IBMCPP__ > 600, so I guess your value's lower than that. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0