- Boost - lists.boost.org

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

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