March 2006 - Boost - lists.preview.boost.org

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

Re: [boost] [database] - guid class / Next Release
by Marc Viala 02 Mar '06

02 Mar '06

<snip> > This does make sense. I have added a constructor to initialize from raw data: > template <ByteInputIterator> > guid(ByteInputIterator first, ByteInputIterator last); > and a function to get out the raw bytes: > template <ByteOutputIterator> > void output_bytes(ByteOutputIterator out) { > std::copy(data_.begin(), data_.end(), out); } > Is output_bytes what you are looking for? Andy. Hi Andy, I'm sorry to be quite < pushy > but are you making some progress on the next release of you proposal of guid class? The functionalities of your proposal are really present in our current project development and I would like to know when you plan to publish your next release. By the way, do you have a look on my previous email 22/02? Best regards, Marc Viala

3 3

Re: [boost] VC7.1 ICE
by Peder Holt 02 Mar '06

02 Mar '06

On 2/26/06, Tobias Schwinger <tschwinger(a)neoscientists.org> wrote: > Peder Holt wrote: > > In confix_parser_gen: > > Adding another level of indirection solves the problem: > > [...] > > > > Now rule_parser_1_1 passes without problems. > > Great! > > > > Attached is a patch with this fix. > > > > I applied the workaround to all functions in the CVS version of confix.hpp. > Unfortunately the same trick won't help to get rid of the ICE in rule_parser_2_2 when applied to the subscript operator of spirit::parser (would've been too easy)... I have looked at this, and this is a problem between VC7.1 and the way the typeof emulation works, as you showed in the simplified test-case. The problem lies in the use of the operator[] with function pointers. The only workaround for this problem that I have found, apart from rewriting the user code, is to separate the sizeof operation and the typedef. (like in the #if ! defined BOOM clause) Problem is, this has to be done inside a struct, and can not be made to emulate the BOOST_TYPEOF syntax. The proposed solution is then to add a new macro called something like: BOOST_TYPEOF_NESTED_TYPEDEF(name,expr) which looks roughly like this: struct name { //Twophase typeof using expr typedef resulting_type_calculated type; }; To access the type, you have to do a typedef typename name::type my_type; outside BOOST_TYPEOF_NESTED_TYPEDEF. Introducing this construct has two positive effects: 1. rule_parser_2_2 (and similar tests) pass. 2. In emulation mode, there is no longer any limit to the complexity of the types passed to BOOST_TYPEOF_NESTED_TYPEDEF. BOOST_TYPEOF_LIMIT_SIZE is no longer a limiting factor. The downside is the added complexity of the library. It also doesn't reflect any proposed C++ features. Is there any interest in adding this feature to the typeof library? Regards, Peder

2 2

[wave] test_re2c_lexer / V2
by Vladimir Prus 02 Mar '06

02 Mar '06

Hi, the test_re2c_lexer test of Wave fails under msvc-7.1/Boost.Build V2, as shown at: http://tinyurl.com/joupe The error says that dllimport/dllexport directives are wrong. This was not detected with V1, but V2 uses shared linking by default and so detects the problem. In other words, it's possible that the re2c lexer cannot be used when Wave is built as DLL. Hartmut, can you look into this? - Volodya

2 2

Re: [boost] VC7.1 ICE
by Tobias Schwinger 01 Mar '06

01 Mar '06

Peder Holt wrote: > Tobias Schwinger wrote: >>Unfortunately the same trick won't help to get rid of the ICE in >>rule_parser_2_2 when applied to the subscript operator of >>spirit::parser (would've been too easy)... > > > I have looked at this, and this is a problem between VC7.1 and the way > the typeof emulation works, as you showed in the simplified test-case. > The problem lies in the use of the operator[] with function pointers. > > The only workaround for this problem that I have found, apart from > rewriting the user code, is to separate the sizeof operation and the > typedef. > (like in the #if ! defined BOOM clause) > Problem is, this has to be done inside a struct, and can not be made > to emulate the BOOST_TYPEOF syntax. > The proposed solution is then to add a new macro called something like: > BOOST_TYPEOF_NESTED_TYPEDEF(name,expr) which looks roughly like this: > struct name { > //Twophase typeof using expr > typedef resulting_type_calculated type; > }; > > To access the type, you have to do a typedef typename name::type > my_type; outside BOOST_TYPEOF_NESTED_TYPEDEF. > > Introducing this construct has two positive effects: > 1. rule_parser_2_2 (and similar tests) pass. > 2. In emulation mode, there is no longer any limit to the complexity > of the types passed to BOOST_TYPEOF_NESTED_TYPEDEF. > BOOST_TYPEOF_LIMIT_SIZE is no longer a limiting factor. Wow! Sounds like a pretty cool workaround to me. Will the proposed interface allow me to inject static variables into the context the expression is evaluated in? Clarification: Using a SPIRIT_RULE_PARSER with the expression p >> *(d >> p) , p and d being templated parameters, the macro generates // ... struct __parser { // Injected names // (these are member variables in the "runtime version" of the // expression which is assigned to a member variable of type // __parser::type) static P0 & p; static P1 & d; typedef typeof( p >> *(d >> p) ) type; }; // ... Wouldn't I have to declare p and d inside the nested struct in this case? > The downside is the added complexity of the library. > It also doesn't reflect any proposed C++ features. So what? It's closer to the semantics of native typeof because the limits aren't so tight and because it's stable. It would be interesting to know whether it also eliminates the ADL failure and the weird "deduction from base fails for non-overloaded functions" bug in VC8 [ see http://tinyurl.com/7j9me ] ... > Is there any interest in adding this feature to the typeof library? YES! It also seems very well-suited for planned Spirit-2 http://spirit.sourceforge.net/dl_docs/redesigning_spirit.html as we'll easily hit the current limits trying to handle the results of the proposed kind of parser-transformation, I figure. In fact, I was tempted to make "subexpression registration" [ discussed with Arakdiy here: http://tinyurl.com/asnxq ], which can significantly reduce the required TYPEOF_LIMIT_SIZE, an official feature request for Typeof after reading that document. Thanks again -you da man- ;-), Tobias

1 0

[MPL] lambda and gcc 4
by João Abecasis 01 Mar '06

01 Mar '06

Hi! Using current CVS or version 1.33.1 the following simplified test case fails to compile with gcc 4.0.2 #include <boost/mpl/lambda.hpp> int main() { using boost::mpl::lambda; typedef lambda<lambda<int> >::type type; } What I'm actually trying to do is mpl::transform< PredSequence, mpl::lambda<mpl::_1> > , where PredSequence is a MPL Sequence. The result of this operation is subsequently used with fold/reverse_fold to chain together all the metafunctions in PredSequence and create a single metafunction, where the result of one metafunction is passed as argument to the next. For the current CVS HEAD the errors I get with the above test case are, boost/mpl/aux_/preprocessed/gcc/template_arity.hpp: In instantiation of ‘boost::mpl::aux::template_arity<T1>’: test.cpp:7: instantiated from here boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:98: error: ‘boost::mpl::aux::template_arity<T1>::value’ is not a valid template argument for type ‘int’ because it is a non-constant expression test.cpp: In function ‘int main()’: test.cpp:7: error: ‘boost::mpl::aux::template_arity<T1>::value’ is not a valid template argument for type ‘int’ because it is a non-constant expression test.cpp:7: error: ‘boost::mpl::aux::template_arity<T1>::value’ is not a valid template argument for type ‘int’ because it is a non-constant expression The full compiler version is 4.0.2 20051125 (Red Hat 4.0.2-8), from Fedora Core 4. When using gcc 3.2.3 from the same linux distribution both simplified test and the real use case compile cleanly. Am I doing something wrong? What am I missing? Best regards, João

1 0