- Boost - lists.boost.org

Re: [boost] [multi_index] BOOST_MULTI_INDEX_CONST_MEM_FUN and membertemplate functions
by JOAQUIN LOPEZ MU?Z 04 Mar '06

04 Mar '06

Hello Felipe, ----- Mensaje original ----- De: Felipe Magno de Almeida <felipe.m.almeida(a)gmail.com> Fecha: Viernes, Marzo 3, 2006 11:22 pm Asunto: [boost] [multi_index] BOOST_MULTI_INDEX_CONST_MEM_FUN and membertemplate functions > Hi, > > BOOST_MULTI_INDEX_CONST_MEM_FUN is implemented ths way: > > #define BOOST_MULTI_INDEX_CONST_MEM_FUN(Class,Type,MemberFunName) \ > ::boost::multi_index::const_mem_fun<Class,Type,&Class::MemberFunName> > > But when I need to do something like this: > > typedef boost::tuple<std::string, std::string> tuple; > > BOOST_MULTI_INDEX_CONST_MEM_FUN(tuple, std::string const&, get<0>); > > It doesnt work because of the two closing brackets that results from > the macro expansion. > Couldnt be added a space after &Class::MemberFunName ? > Here it works ok adding the space. > Of course, count on this being committed asap. I've got a couple of questions, though: 1. Regardless of whether your compiler takes the expanded macro as containing a '>>' instead of two '>'s, it is my understanding that a *conformant* preprocessor shouldn't do this. Is this correct? (I'll add the blank, anyway.) 2. Do you say this particular use of const_mem_fun (macro problems aside) works for you? Which compiler and version of Boost (1.33.1,CVS) are you using? I'm a little surprised because accessing tuple::get with const_mem_fun is a very tricky issue, as discussed for instance in the following thread: http://lists.boost.org/boost-users/2005/12/16087.php Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[multi_index] BOOST_MULTI_INDEX_CONST_MEM_FUN and member template functions
by Felipe Magno de Almeida 03 Mar '06

03 Mar '06

Hi, BOOST_MULTI_INDEX_CONST_MEM_FUN is implemented ths way: #define BOOST_MULTI_INDEX_CONST_MEM_FUN(Class,Type,MemberFunName) \ ::boost::multi_index::const_mem_fun<Class,Type,&Class::MemberFunName> But when I need to do something like this: typedef boost::tuple<std::string, std::string> tuple; BOOST_MULTI_INDEX_CONST_MEM_FUN(tuple, std::string const&, get<0>); It doesnt work because of the two closing brackets that results from the macro expansion. Couldnt be added a space after &Class::MemberFunName ? Here it works ok adding the space. Thanks, -- Felipe Magno de Almeida

1 0

[test] Possible design flaw in execution_monitor::catch_signals
by Jim Douglas 03 Mar '06

03 Mar '06

A recent problem I encountered that caused the total failure of a regression test run has highlighted what I (and others) believe to be a design flaw in execution_monitor::catch_signals (in file execution_monitor.ipp). IIUC the purpose of the code in question is to intercept UNIX signals and convert them to exceptions which contain a diagnostic message indicating the signal type. For most signals this should work reliably. However, we suggest that this mechanism is prone to failure when attempting to deal with a SIGSEGV, as happened in my case. What I observed was a test process that had stalled by blocking against a mutex. Detailed analysis showed that the test failed with a memory segment violation resulting in a SIGSEGV. In brief, the primary execution failure corrupts the program heap. When the C++ exception is thrown at execution_monitor:462, the exception handling mechanism calls __cxa_allocate_exception which then calls std::malloc. But, because of the corrupted heap, this call blocks against the malloc mutex. This is the specific case with QNX, and other OSs will deal with this in different ways. The general point I would like to make is that after a memory segment violation, any process's memory will be in an undefined state and it is unreasonable to assume that it will be capable of continued execution as per the present design. I propose that there is no safe way to intercept a SIGSEGV and that it should be allowed to terminate the process without intervention. Comments please... Jim

3 4

Decimal floating point library
by Stefan Slapeta 03 Mar '06

03 Mar '06

Hi all, I think it's correct to say that many of us would like to see an IEEE conforming implementation of a decimal floating point library in boost. AFAIK C++ is the last of the important programming languages which has none in it's standard library. While it's for sure a major project to start from scratch and write a complete implementation (I don't know if there ever will be a group of people who are able *and* willing to do that...), there's maybe another option: IBM has recently put their C implementation (which is widely known as reference implementation) under GPL as part of GCC. It would be quite easy to write a C++ wrapper around this library and put it all together into boost, and I would volunteer to do that. So: - are we allowed to do that? - is this desirable? Thoughts? Stefan

6 12

Simple function_template.hpp warning fix
by Peter Dimov 02 Mar '06

02 Mar '06

Line 293: void init(FunctionPtr f, function_ptr_tag) needs to be changed to: void init(FunctionPtr /*f*/, function_ptr_tag) to silence the "unreferenced formal parameter" warning. OK to commit? -- Peter Dimov http://www.pdimov.com

2 2

FYI: gcc-4.1.0 is released
by Neal Becker 02 Mar '06

02 Mar '06

FYI: gcc-4.1.0 is released

7 7

Rationale question wrt boost::get_pointer()
by Hartmut Kaiser 02 Mar '06

02 Mar '06

Hi all, could anybody please explain to me why there is no general overload for the boost::get_pointer() function: template <typename T> T* get_pointer(T& t) { return &t; } which would catch all the non-specialized cases? Regards Hartmut

1 0

[MPL] why is apply<_1, _2> not a placeholder expression?
by João Abecasis 02 Mar '06

02 Mar '06

Hi! Currently, apply does not meet the criteria for a Placeholder Expression because the number of template parameters is one too many. Still, I think it would be useful to be able to use apply as a lambda expression. For my use case, I needed a lazy metafunction that took a function and its argument, evaluating the passed function with the argument. My initial approach to this was to use lambda<apply<_2, _1> >::type this approach failed, it turns out, because lambda returns apply<_2, _1> unchanged, while I expected to get protect< bind2< quote2<apply>, arg<2>, arg<1> > > A simple workaround is to use apply1, instead or to directly use the expression above, which diminishes code readability. Would it be possible and desirable to give apply special treatment in lambda, if only to avoid surprises in similar use cases? Best regards, João

1 0

Introduction for Boost contact for IBM XL C++ compiler - Michael Wong
by Michael Wong 02 Mar '06

02 Mar '06

Hi, my name is Michael Wong. Some of you already know me from the C++ standard committee. I am designated by IBM as the representative for submitting Boost changes that affect our XL C++ compiler (previously called VisualAge C++) back to the CVS line. My backup is my colleague Christopher Cambly. Over the last 2 releases of the XL ++ compiler (v7 and 8) we have been striving for as much compatibility as possible. The V7 compiler supports Boost-1.30.2 and the V8 compiler supports 1.32.0. We maintain the latest XLC++ V8 results testing with 1.32.0 on AIX/RHEL4/SLES9 here: http://www-1.ibm.com/support/docview.wss?rs=2239&context=SSJT9L&dc=DA420&dc… I know you are planning the 1.34 release. I would like to submit changes that we have verified back to the CVS line before you cut the release. Here are the two most urgent changes which are to the jam tools based on the CVS code base in unified diffs for tools/build/v1/vacpp-tools/jam and tools/build/v1/allyourbase.jam: --- ../boost-CVS.orig/tools/build/v1/allyourbase.jam 2005-11-01 09:05:46.000000000 -0500 +++ allyourbase.jam 2006-02-13 02:40:03.000000000 -0500 @@ -2195,7 +2195,7 @@ $(RANLIB) "$(<)" } -actions quietly updated piecemeal together RmTemps +actions quietly ignore updated piecemeal together RmTemps { $(RM) "$(>)" }--- ../boost-CVS.orig/tools/build/v1/vacpp-tools.jam 2006-02-13 09:28:53.000000000 -0500 +++ vacpp-tools.jam 2006-02-13 02:39:34.000000000 -0500 @@ -10,10 +10,15 @@ # IBM VisualAge C++ compiler # version 5.0 # version 6.0 +# version 7.0 +# IBM XL C++ compiler +# version 8.0 # # These settings are created and tested with VisualAge running on # IBM/Aix 4.3.3.0. They should also work for VisualAge on Windows NT, # OS/2 and AS/400. +# These settings are created and tested with IBM XL C++ running on +# IBM/Aix 5.2.0.0. # The following #// line will be used by the regression test table generation # program as the column heading for HTML tables. Must not include version number. @@ -34,6 +39,10 @@ # This disables the automatic generation of separate include files for # template functions and class declarations. flags vacpp C++FLAGS : -qnotempinc ; +flags vacpp C++FLAGS : -qnotemplateregistry ; + +# Allow C++ style comments in C files +flags vacpp CFLAGS : -qcpluscmt ; # The following is needed to get rid of most of the annoying linker warnings # about duplicated symbols when you use templates. @@ -44,37 +53,72 @@ # contained in such an object file won't be invoked. flags vacpp LINKFLAGS : -qtwolink ; +# Optimization levels flags vacpp CFLAGS <optimization>off : -qNOOPTimize ; flags vacpp CFLAGS <optimization>default : -O ; -flags vacpp CFLAGS <optimization>speed : -O3 -qstrict ; +flags vacpp CFLAGS <optimization>two : -O2 ; +flags vacpp CFLAGS <optimization>three : -O3 ; +flags vacpp CFLAGS <optimization>four : -O4 ; flags vacpp CFLAGS <optimization>space : -O2 -qcompact ; +# Automatic inlining flags vacpp CFLAGS <inlining>off : -qnoinline ; flags vacpp CFLAGS <inlining>on : -qinline ; flags vacpp CFLAGS <inlining>full : -qinline ; +# Exception handling flags vacpp C++FLAGS <exception-handling>off : -qnoeh ; flags vacpp C++FLAGS <exception-handling>on : -qeh ; +# Runtime Type Identification flags vacpp C++FLAGS <rtti>off : -qnortti ; flags vacpp C++FLAGS <rtti>on : -qrtti ; -flags vacpp LINKFLAGS <runtime-link>static : -bstatic ; +# Enable 64bit memory addressing model +flags vacpp CFLAGS <address-model>64 : -q64 ; +flags vacpp LINKFLAGS <address-model>64 : -q64 ; +flags vacpp ARFLAGS <address-model>64 : -X 64 ; + +# Disable weaksymbol support to help with debugging using xldb on AIX +flags vacpp C++FLAGS <weaksymbols>off : -qnoweaksymbol ; + +# Dynamic Link options +flags vacpp LINKFLAGS <target-type>$(SHARED_TYPES) : -G ; + +#Platform Specific options +switch $(JAMUNAME) + { + case Linux : + { + # Add -qpic for IBM XL C++ on Linux + flags vacpp CFLAGS <shared-linkable>true : -qpic ; + } + case AIX* : + { + # Runtime linking options + flags vacpp LINKFLAGS <runtime-link>dynamic : -brtl -bdynamic ; + } + } + # We want the full path to the sources in the debug symbols because otherwise # the debugger won't find the sources when we use boost.build. -flags vacpp CFLAGS <debug-symbols>on : -g -qfullpath ; +flags vacpp CFLAGS <debug-symbols>on : -qfullpath ; +flags vacpp CFLAGS <debug-symbols>on : -g ; flags vacpp LINKFLAGS <debug-symbols>on : -g ; +#strips the symbol table, line number info, and relocation info from output flags vacpp LINKFLAGS <debug-symbols>off : -s ; +# Enable profiling flags vacpp CFLAGS <profiling>on : -pg ; flags vacpp LINKFLAGS <profiling>on : -pg ; + flags vacpp CFLAGS <cflags> ; flags vacpp C++FLAGS <cxxflags> ; flags vacpp DEFINES <define> ; flags vacpp UNDEFS <undef> ; flags vacpp HDRS <include> ; -flags vacpp SYSHDRS <sysinclude> ; +flags vacpp STDHDRS <sysinclude> ; flags vacpp LINKFLAGS <linkflags> ; flags vacpp ARFLAGS <arflags> ; @@ -84,26 +128,12 @@ if ! $(ARFLAGS) { - flags xlc ARFLAGS : "" ; + flags vacpp ARFLAGS : "" ; } -# Clear the STDHDRS variable which contains /usr/include. Vacpp does not like -# that this sys directory is included (vacpp related headers are in -# /usr/vacpp/include) -STDHDRS = ; - #### Link #### - rule Link-action { - if $(gTARGET_TYPE($(<))) = EXE - { - LINKFLAGS on $(<) += -brtl ; - } - if $(gTARGET_TYPE($(<))) in $(SHARED_TYPES) - { - LINKFLAGS on $(<) += -G ; - } xlc-Link-action $(<) : $(>) ; } @@ -112,7 +142,7 @@ { $(SHELL_SET)$(gSHELL_LIBPATH)=$(LINK_LIBPATH)$(gAPPEND_LD_LIBRARY_PATH) $(SHELL_EXPORT)$(gSHELL_LIBPATH) - $(VA_CXX_COMPILER:R=$(VA_TOOL_PATH)) $(LINKFLAGS) -o "$(<[1])" -L$(LIBPATH) -L$(STDLIBPATH) "$(>)" "$(NEEDLIBS)" "$(NEEDLIBS)" -bdynamic -l$(FINDLIBS) + $(VA_CXX_COMPILER:R=$(VA_TOOL_PATH)) $(LINKFLAGS) -o "$(<[1])" -L$(LIBPATH) -L$(STDLIBPATH) "$(>)" "$(NEEDLIBS)" "$(NEEDLIBS)" -l$(FINDLIBS) } #### Cc ##### @@ -125,7 +155,7 @@ # Always allow C++ comments in C source files! actions xlc-Cc-action { - $(VA_C_COMPILER:R=$(VA_TOOL_PATH)) -qcpluscmt -c -I$(BOOST_ROOT) -U$(UNDEFS) -D$(DEFINES) $(CFLAGS) -I"$(HDRS)" -I"$(STDHDRS)" -I"$(SYSHDRS)" -o "$(<)" "$(>)" + $(VA_C_COMPILER:R=$(VA_TOOL_PATH)) -c -I$(BOOST_ROOT) -U$(UNDEFS) -D$(DEFINES) $(CFLAGS) -I"$(HDRS)" -I"$(STDHDRS)" -o "$(<)" "$(>)" } #### C++ #### @@ -136,7 +166,7 @@ actions xlc-C++-action { - $(VA_CXX_COMPILER:R=$(VA_TOOL_PATH)) -c -I$(BOOST_ROOT) -U$(UNDEFS) -D$(DEFINES) $(CFLAGS) $(C++FLAGS) -I"$(HDRS)" -I"$(STDHDRS)" -I"$(SYSHDRS)" -o "$(<)" "$(>)" + $(VA_CXX_COMPILER:R=$(VA_TOOL_PATH)) -c -I$(BOOST_ROOT) -U$(UNDEFS) -D$(DEFINES) $(CFLAGS) $(C++FLAGS) -I"$(HDRS)" -I"$(STDHDRS)" -o "$(<)" "$(>)" } #### Archive #### @@ -148,5 +178,5 @@ actions updated together piecemeal xlc-Archive-action { - ar ru$(ARFLAGS) "$(<)" "$(>)" + ar $(ARFLAGS) ru "$(<)" "$(>)" } I know about the tracker, but I am uncertain how to use it correctly especially since I am posting changes for V1 build and that seems to be used for the V1 build. Or may be I am mistaken. So I am posting here. https://zigzag.cs.msu.su:7813/boost.build/ Michael Wong XL C++ Compiler kernel Development IBM Canada Ltd., C2/KD2/8200/MKM 8200 Warden Avenue Markham, Ontario L6G 1C7 W:905-413-3283 F:905-413-4839 http://www.ibm.com/software/awdtools/ccompilers/ http://www.ibm.com/software/awdtools/fortran/ XL Overview http://www-1.ibm.com/support/docview.wss?uid=swg27005175&aid=1 Optimization http://www-1.ibm.com/support/docview.wss?uid=swg27005174&aid=1 XL C/C++ for Mac OS X http://www-1.ibm.com/support/docview.wss?uid=swg27005176&aid=1 XL Fortran for Mac OS X http://www-1.ibm.com/support/docview.wss?uid=swg27005173&aid=1

4 4

[type_traits] Borland 2006 tests
by Zara 02 Mar '06

02 Mar '06

I am working for bcbboost, and I have begun making regression test, going from basics upwards. I have found (with my current configuration) therer *hundreds* of type_traits library tests that fail. I am trying to find a solution to those, but I cannot keep from wondering, was BCB6 also failing, and it is not important? Was it failing and nobody noticed? Am I failing to see the evident, and all my work process is poisoned form the beginning? To give an example, remove_const fails for the following cases: 2: volatile -> volatile 3: const volatile -> volatile 7: *volatile -> *volatile 8: *const volatile -> *volatile 13: volatile[2] -> volatile[2] As I have seen on other threads, there might be an issue with the order of quialifications, so maybe the soltunio is to redefine the test macros, but I hope someone will give me some idea to continue with minimum effort. TIA, bes regards, Zara

2 3