February 2006 - Boost - lists.preview.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

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

[SIGNAL/BIND] Regressions with GCC 4.1 RC.
by larsbj＠gullik.net 01 Mar '06

01 Mar '06

We se some strange problems with GCC 4.1 (the prerelease/release candidate) with use of boost::signal and boost::bind. Have anyone run the regressions tests for this GCC version? g++ (GCC) 4.1.0 20060219 (prerelease We get errors of this form: g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./.. -I../../boost -Wextra -Wall -I/usr/X11R6/include -g -O -MT render_graphic.lo -MD -MP -MF .deps/render_graphic.Tpo -c render_graphic.C -o render_graphic.o In file included from ../../boost/boost/config.hpp:35, from ../../boost/boost/bind.hpp:23, from ../../src/support/translator.h:16, from ../../src/graphics/GraphicsTypes.h:18, from ../../src/graphics/GraphicsLoader.h:27, from render_graphic.h:17, from render_graphic.C:13: ../../boost/boost/config/compiler/gcc.hpp:92:7: warning: #warning "Unknown compiler version - please run the configure tests and report the results" ../../boost/boost/bind.hpp: In function 'void boost::visit_each(V&, const boost::_bi::value<T>&, int) [with V = boost::signals::detail::bound_objects_visitor, T = const InsetBase*]': ../../boost/boost/bind.hpp:296: instantiated from 'void boost::_bi::list2<A1, A2>::accept(V&) const [with V = boost::signals::detail::bound_objects_visitor, A1 = boost::reference_wrapper<const LyX>, A2 = boost::_bi::value<const InsetBase*>]' ../../boost/boost/bind/bind_template.hpp:150: instantiated from 'void boost::_bi::bind_t<R, F, L>::accept(V&) const [with V = boost::signals::detail::bound_objects_visitor, R = const Buffer* const, F = boost::_mfi::cmf1<const Buffer* const, LyX, const InsetBase*>, L = boost::_bi::list2<boost::reference_wrapper<const LyX>, boost::_bi::value<const InsetBase*> >]' ../../boost/boost/bind.hpp:1110: instantiated from 'void boost::visit_each(V&, const boost::_bi::bind_t<R, F, L>&, int) [with V = boost::signals::detail::bound_objects_visitor, R = const Buffer* const, F = boost::_mfi::cmf1<const Buffer* const, LyX, const InsetBase*>, L = boost::_bi::list2<boost::reference_wrapper<const LyX>, boost::_bi::value<const InsetBase*> >]' ../../boost/boost/visit_each.hpp:25: instantiated from 'void boost::visit_each(Visitor&, const T&) [with Visitor = boost::signals::detail::bound_objects_visitor, T = boost::_bi::bind_t<const Buffer* const, boost::_mfi::cmf1<const Buffer* const, LyX, const InsetBase*>, boost::_bi::list2<boost::reference_wrapper<const LyX>, boost::_bi::value<const InsetBase*> > >]' ../../boost/boost/signals/slot.hpp:121: instantiated from 'boost::slot<SlotFunction>::slot(const F&) [with F = boost::_bi::bind_t<const Buffer* const, boost::_mfi::cmf1<const Buffer* const, LyX, const InsetBase*>, boost::_bi::list2<boost::reference_wrapper<const LyX>, boost::_bi::value<const InsetBase*> > >, SlotFunction = boost::function<void ()(), std::allocator<void> >]' render_graphic.C:44: instantiated from here ../../boost/boost/bind.hpp:1105: error: no matching function for call to 'visit_each(boost::signals::detail::bound_objects_visitor&, const InsetBase* const&, int)' This patch "fixes" the compile problems but we do not really want to apply it. Any opinions on this? Is it something strange hidden in our code, boost or a real regression in gcc? -- Lgb

3 10

[tools/regression] Borland patch for process_jam_log.cpp
by Nicola Musatti 01 Mar '06

01 Mar '06

Hallo, the following patch makes it possible to compile process_jam_log.cpp with the Borland compilers. In a ternary operator the Borland compiler doesn't apply the implicit conversin from a [const] char * to a std::string. Cheers, Nicola Musatti Index: process_jam_log.cpp =================================================================== RCS file: /cvsroot/boost/boost/tools/regression/process_jam_log.cpp,v retrieving revision 1.38 diff -d -b -u -r1.38 process_jam_log.cpp --- process_jam_log.cpp 28 Jun 2005 00:24:41 -0000 1.38 +++ process_jam_log.cpp 23 Jan 2006 23:06:22 -0000 @@ -462,7 +462,7 @@ // add the "run" stop_message action tl.add_action( action_name, - result == "succeed" && note() ? "note" : result, + result == "succeed" && note() ? std::string("note") : result, timestamp, content ); }

2 1

C++ Mystery: [Fwd: Re: [Boost-users] [statechart] Template States, Compile Error]
by David Greene 01 Mar '06

01 Mar '06

Since both I and Andreas are baffled by this problem, I thought I'd forward this on to the larger Boost community. Anyone have any ideas about it? It seems like it should be a simple thing but something about the way lookup works in C++ is causing the inner_context_type member of simple_state to be missed. The problem persists even if typedef typename sc::simple_state< NormalMode< Type >, Switch, Off<Type> >::inner_context_type inner_context_type; is added to the NormalMode class template. -Dave

2 1

Statechart bug? [Fwd: [Boost-users] [statechart] Template States, Compile Error]
by David Greene 01 Mar '06

01 Mar '06

Forwarding because this might be a library bug. I can't figure out why these error messages are generated. -Dave

2 1

[serialization] [ublas] - ublas::matrix, ublas::vector serialization patch
by Janek Kozicki 01 Mar '06

01 Mar '06

hi serialization of ublas matrix and vector is missing in boost 1.33, therefore I've written missing functions: /usr/include/boost/serialization/ublas_matrix.hpp /usr/include/boost/serialization/ublas_vector.hpp files are in the attachment. I'm afraid that the idea of converting matrix to std::vector<std::vector<U> > is not optimal, perhaps someone can make it better? Please include those files in next boost version. File are very short, so review should not take too long. I bet that some people out there need them. best regards -- Janek Kozicki |

3 6

Sourceforge + Subversion (finally)
by Caleb Epstein 01 Mar '06

01 Mar '06

I think Boost already has another host in mind for an eventual (?) switch to Subversion, but in case I'm wrong it appears that Sourceforge now officially supports Subversion repositories: http://sourceforge.net/docman/display_doc.php?docid=31070&group_id=1 They even offer automatic repository conversion (e.g. cvs2svn). -- Caleb Epstein caleb dot epstein at gmail dot com

2 1

[shmem] Some proposals for open issues from the review
by Ion Gaztañaga 01 Mar '06

01 Mar '06

Hi to all, After Shmem review, I've been re-reading some review comments and there were some issues not completely solved during the review: * Library name: Some don't like the Shmem name for the library and since the library offers also a process shared message queue and memory mapped files and surely we will have more interprocess mechanisms in the future (pipes, for example), I'm proposing the Boost.IPC or Boost.InterProcess name (boost::ipc or boost::interprocess namespace). I don't know if it's even worse or if it expresses better the purpose of the library. Just an idea. * Class names: I propose changing "mmaped_file" class to simply "mapped_file", so we have "mapped_file" and "mapped_region" classes. The classes that I call "front-ends" (a name that some don't like and if someone has a better I would be glad to use it) have the following names: ->named_shared_object (the class that allows named object construction in shared memory) ->named_mfile_object (the class that allows named object construction in memory mapped files) ->named_heap_object (the class that allows named object construction in a heap memory buffer) ->named_user_object (the class that allows named object construction in an user provided buffer) I don't like much those names but I couldn't find better alternatives. In response to Kim Barrett's review I proposed the following: ->shared_memory_xxx ->mapped_file_xxx ->heap_memory_xxx ->external_memory_xxx where xxx can be something like "services", "framework", "objects", or we can add a "smart" prefix to those names. I would like to receive suggestions for better names. I think it's important to choose better names before the library is released. * Changes from Boost.Thread interface: Now that Boost.Date_Time has been chosen as time representation for timed functions of the synchronization primitives, I would also propose a simplification of synchronization primitives. Currently, following Boost.Thread interface, mutex lock and unlock functions are private, but I would prefer making them public, and implement a unique scoped lock class that can lock any "lockable" object (shared_mutex, shared_recursive_mutex, named_mutex). This general locker could be moved to boost utilities or be just for this library. Or do you consider "too dangerous" to have lock functions public?. This is a proposal based on Howard Hinnant's much more complete scoped_lock proposal (http://home.twcny.rr.com/hinnant/cpp_extensions/threads_move.html) namespace boost { namespace shmem/ipc/interprocess { template <class Mutex> class scoped_lock { public: typedef Mutex mutex_type; explicit scoped_lock(mutex_type& m); scoped_lock(mutex_type& m, detail::dont_lock_type); scoped_lock(mutex_type& m, detail::try_lock_type); scoped_lock(mutex_type& m, const boost::posix_time::ptime &time); private: scoped_lock(scoped_lock const&); scoped_lock& operator= (scoped_lock const&); public: ~scoped_lock(); public: void lock(); bool try_lock(); bool timed_lock(const boost::posix_time::ptime &time); void unlock(); bool locked() const; operator unspecified_bool_type () const; mutex_type* mutex() const; private: mutex_type& m_mut; bool m_locked; }; }} This locker can be used would be usable with any class that has required lock()/unlock/try_lock()/timed_lock() functions. The mutex doesn't need try_lock/timed_lock functions if we don't use scoped_lock's try_lock/timed_lock functions. Since the class is a template, try_lock()/timed_lock() won't be instantiated. I also think that there too many mutex types: -> shared_mutex -> shared_try_mutex -> shared_timed_mutex -> shared_recursive_mutex -> shared_recursive_try_mutex -> shared_recursive_timed_mutex -> named_mutex I think that all can be condensed in shared_mutex, shared_recursive_mutex and named_mutex types without overhead, since Windows and POSIX systems offer try/timed functions for mutexes. So we can pass from 7 mutex types to 3 and from 3 lockers to just 1. To sum up proposals regarding this point: -> Public lock/unlock functions? -> Merging 7 mutex types into 3? -> Merging 3 scoped_lock types into 1? Regards, Ion

12 24

[serialization] CW8.3 patch
by David Abrahams 28 Feb '06

28 Feb '06

The enclosed patch makes serialization work with CW8.3 -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0