- Boost - lists.boost.org

[call traits] BCB workaround and updated version check
by AlisdairM 12 Feb '06

12 Feb '06

The following patch solves the bad array type being picked up in the call_traits tests, leaving one test unsolved. It also confirms the workarounds are still needed for BCB2006. Note the minor case of switching order of T and const. This is due to a bug I only fully appreciated today. depending on order of add_const and add_ref, BCB will deduce 2 *different* types. int const & int & const The latter does not sound like a 'real' type to me, so I suggest always placing const before the type, rather than after, when dealing with template type-parameters - unless we have cases where this makes a real difference for conforming compilers. Rest of the patch should be straightforward. AlisdairM cvs diff -u -wb -- boost\detail\call_traits.hpp (in directory E:\sourceforge\devel\boost\) Index: boost/detail/call_traits.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/detail/call_traits.hpp,v retrieving revision 1.15 diff -u -w -b -r1.15 call_traits.hpp --- boost/detail/call_traits.hpp 12 Aug 2005 19:06:10 -0000 1.15 +++ boost/detail/call_traits.hpp 12 Feb 2006 13:23:16 -0000 @@ -58,7 +58,7 @@ template <typename T, bool b1> struct ct_imp<T, true, b1> { - typedef T const param_type; + typedef const T param_type; }; } @@ -92,7 +92,7 @@ typedef T& param_type; // hh removed const }; -#if BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x570 ) ) +#if BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x581 ) ) // these are illegal specialisations; cv-qualifies applied to // references have no effect according to [8.3.2p1], // C++ Builder requires them though as it treats cv-qualified @@ -121,6 +121,15 @@ typedef const T& const_reference; typedef T& param_type; // hh removed const }; + +template <typename T> +struct call_traits< T * > +{ + typedef T * value_type; + typedef T * & reference; + typedef T * const & const_reference; + typedef T * const param_type; // hh removed const +}; #endif #if !defined(BOOST_NO_ARRAY_TYPE_SPECIALIZATIONS) template <typename T, std::size_t N> -- AlisdairM

2 2

[call traits] expected errors not detected for BCB
by AlisdairM 12 Feb '06

12 Feb '06

The call_traits test expects 2 errors from BCB, yet is counting none. Hence the failing test-case. When I look at the output, I still see 2 failing tests. What I can't work out is how these tests are supposed to increment the failed test count. And that makes me wonder if a platform expecting 0 failures started failing, would it show up? -- AlisdairM

2 1

bcp: towards a library dependency list
by John Maddock 12 Feb '06

12 Feb '06

I've just committed some changes to bcp that give it a shortened list option: bcp --list-short truncates the list so you just see directory names where appropriate, for example: bcp --list-short shared_ptr.hpp Gives the dependency list: boost/assert.hpp boost/checked_delete.hpp boost/config.hpp boost/config boost/current_function.hpp boost/detail boost/mpl boost/non_type.hpp boost/preprocessor boost/shared_ptr.hpp boost/static_assert.hpp boost/throw_exception.hpp boost/type.hpp boost/type_traits boost/version.hpp which is reasonably nice and compact :-) Now, here's the question: what did the folks who were asking for this functionality actually want to use the information for? I should stress that it's overkill for extracting subsets of Boost, because many libraries will depend on just one or two files inside boost/mpl or boost/preprocessor, so using the list for that purpose will result in an even "thicker" dependency than copying with bcp already produces. It's possible to contract the above list even further: for example by contracting to library names where possible, so for example contracting all of: boost/regex.hpp boost/regex libs/regex to just "regex" However there would still be a lot of Boost headers that can't automatically be assigned to any library name, so it's not clear to me how much use this would be? If folks can give me an idea of what they were looking to use a dependency list for it'll help me decide whether to stop here or to continue trying to contract the list further. John.

8 9

decltype, LVALUE_TYPEOF, and binding a reference
by Arkadiy Vertleyb 12 Feb '06

12 Feb '06

Hi all. The primary purpose of decltype, according to the decltype/auto proposal, seems to be to assist in creation forwarding functions, something like: template<class F> decltype(F()()) forward(F f) { return f(); } For example, if f is declared to return const rvalue: const x f(); using the real decltype (in the future, of course) would result in: const x forward(const x(*)()) { return f(); } Which is, of course, what we expect in this case. Since LVALUE_TYPEOF has a problem distinguishing const x from const x&, using it in the above case would result in: const x& forward(const x(*)()) { ^^^^^^^ return f(); } Now, my question is: isn't this fine? The same rule (extending the lifetime of const reference) that prevented LVALUE_TYPEOF from working correctly, seems to now ensure that it is fine to use this "incorrect" result. Another example of (it seems) the same thing is the treatment of "volatile" by Microsoft compilers (both 7.1 and 8.0). It seems to be fine to write: volatile x vf(); volatile x& vr = vf(); provided x is a UDT, and has a copy-constructor accepting [const] volatile x&. (I don't know if this is a compiler bug, or the lifetime is also extended. I also don't know if this standard-compliant.) Needless to say, LVALUE_TYPEOF(vf()) yields volatile x& instead of expected volatile x (my local version, after adding the treatment for volatiles). If x is not a UDT, the above binding doesn't work, but LVALUE_TYPEOF(vf()), guided by the same exact mechanism, would also yield just x. Let's generalize a bit. When writing a forwarding function, shouldn't we, instead of asking: what is the exact return type of the wrapped function? just ask: what is the type to which the result of the wrapped function can be bound without loosing functionality [on this particular compiler]? It seems to me that using the simple mechanism of binding a reference yelds the results that are at least as good (for this particulat purpose, of course) as those that the real decltype could provide... But maybe I am missing something? Regards, Arkadiy

4 6

Re: [boost] [serialization] serialization/nvp.hppmakes autolink kickin
by JOAQUIN LOPEZ MU?Z 12 Feb '06

12 Feb '06

----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Sábado, Febrero 11, 2006 10:26 pm Asunto: Re: [boost] [serialization] serialization/nvp.hppmakes autolink kickin > JOAQUIN LOPEZ MU?Z wrote: [...] > > > > #include <boost/serialization/nvp.hpp> > > // rest of serialization headers which must not trigger autolink > > #include <...> > > > > // declare some function of the serialization > > // lib (which shouldn't be linked) > > > > int some_f(); > > > > int main() > > { > > // use the function in whatever manner > > int x=some_f(); > > } > > > > Now, if autolink does not get activated, the > > program should fail as some_f is not linked in. > > So, in your Jamfile just mark this as a link-fail: > > > > [ link-fail auto_link_not_invoked.cpp ] > > > I didn't know about link-fail - but I'm still missing something here. > > If I refer to a function that is declared in one of my headers - then > auto-linking will be triggered. It doesn't matter whether this > reference occurs by taking its address or by invoking it by name. > I'm afraid I don't agree here --linkers are not that smart, in fact autolinking is triggered by the appropriate #pragmas only, when you include some header that have those. It doesn't have anything to do with whether the symbols of the lib are used or not. What I propose is that you declare some symbol of the lib *without* using the associate header, which would trigger autolinking. For instance (I haven't actually tested this): // all the serialization headers which mustn't trigger autolink #include <....> // unregister_void_casts is defined by the serialization lib. namespace boost { namespace serialization { class BOOST_SERIALIZATION_DECL(BOOST_PP_EMPTY()) extended_type_info; void BOOST_SERIALIZATION_DECL(BOOST_PP_EMPTY()) unregister_void_casts(extended_type_info *eti); } /* serialization */ } /* boost */ int main() { using namespace boost::serialization; typedef void BOOST_SERIALIZATION_DECL(BOOST_PP_EMPTY()) (* unregister_void_casts_type)(extended_type_info *); unregister_void_casts_type pf=&unregister_void_casts; return 0; } Only when the serialization lib is linked in can this program build OK --so, when autolinking has not been spuriously activated the expected outcome is link failure. > Now I "think" bjam sets up a path to the directory that contains > my pre-built boost libraries - so the reference will be found > and and the program will link. Its not clear to me that I can > suppress this and guarentee that the link will fail. > My comment above applies: autolinking is a #pragma thing, nothing to do with linker finding dangling symbol references --unless I'm grossly mistaken :) Best regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

First cut at Borland2006 config
by AlisdairM 12 Feb '06

12 Feb '06

I am working on cleaning up the Borland config, as it is a growing mess of compiler subversions and workarounds that come and go. I'm holding that back until everything is more stabalized in the test environment though, and till I've persuaded John it's a good idea ;¬) In the meantime, here is the basic adaption of the BCB6 config, that should clean up a lot of test failures for the new compiler. Essentially, all the old defect macros are still required. In practice they may not be required as often, compiler HAS improved, but it is still not 'clean' so it is safest to continue applying all the workarounds. [Yes, I stripped them out for testing, but eventually added them all back one-by-one as I discovered each was still needed] AlisdairM cvs diff -u -wb -- boost\config\compiler\borland.hpp (in directory E:\sourceforge\devel\boost\) Index: boost/config/compiler/borland.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/config/compiler/borland.hpp,v retrieving revision 1.36 diff -u -w -b -r1.36 borland.hpp --- boost/config/compiler/borland.hpp 6 Dec 2005 17:18:51 -0000 1.36 +++ boost/config/compiler/borland.hpp 12 Feb 2006 09:25:28 -0000 @@ -9,6 +9,14 @@ // Borland C++ compiler setup: +// +// versions check: +// we don't support Borland prior to version 5.4: +#if __BORLANDC__ < 0x540 +# error "Compiler not supported or configured - please reconfigure" +#endif + +// // Version 5.0 and below: # if __BORLANDC__ <= 0x0550 // Borland C++Builder 4 and 5: @@ -36,8 +44,8 @@ #endif #endif -// Version 7.0 (Kylix) and below: -#if (__BORLANDC__ <= 0x570) +// Borland C++ Builder 2006 Update 1 and below: +#if (__BORLANDC__ <= 0x581) # define BOOST_NO_SFINAE # define BOOST_NO_INTEGRAL_INT64_T # define BOOST_NO_DEPENDENT_NESTED_DERIVATIONS @@ -52,6 +60,7 @@ # define BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS # define BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL # define BOOST_NO_IS_ABSTRACT + # ifdef NDEBUG // fix broken <cstring> so that Boost.test works: # include <cstring> @@ -65,7 +74,7 @@ // // new bug in 5.61: -#if (__BORLANDC__ >= 0x561) && (__BORLANDC__ <= 0x570) +#if (__BORLANDC__ >= 0x561) //&& (__BORLANDC__ <= 0x570) // this seems to be needed by the command line compiler, but not the IDE: # define BOOST_NO_MEMBER_FUNCTION_SPECIALIZATIONS #endif @@ -156,16 +165,9 @@ #define BOOST_COMPILER "Borland C++ version " BOOST_STRINGIZE(__BORLANDC__) -// -// versions check: -// we don't support Borland prior to version 5.4: -#if __BORLANDC__ < 0x540 -# error "Compiler not supported or configured - please reconfigure" -#endif -// // last known and checked version is 1536 (Builder X preview) -// Or 0x580 (Borland C++ Builder 6 2006 Preview): -#if (__BORLANDC__ > 1536) || ((__BORLANDC__ < 0x600) && (__BORLANDC__ > 0x580)) +// Or 0x581 (Borland C++ Builder 2006 Update 1): +#if (__BORLANDC__ > 0x581) && (__BORLANDC__ != 0x600) # if defined(BOOST_ASSERT_CONFIG) # error "Unknown compiler version - please run the configure tests and report the results" # else

2 2

Bug list status
by Marshall Clow 12 Feb '06

12 Feb '06

Six weeks ago: 61 open bugs Five weeks ago: 59 open bugs Four weeks ago: 56 open bugs. Three weeks ago: 57 open bugs. Two week ago: 54 open bugs One week ago: 54 open bugs Today: 54 open bugs We seem to be stalled here; let's see if we can knock some of these out! (I know that there were bugs fixed this week; it's just that the total hasn't budged) As Jeff has pointed out, Mike Glassford (threads) and Stephen Cleary (pool) have been MIA for quite a while. If anyone wants to contribute fixes for their libraries, let me (or Jeff) know! [ Thanks to those who have already done this! ] If you think that a bug has been assigned incorrectly, please let me know. Bug counts per assignee: Mike Glassford 9 Doug Gregor 6 Stephen Cleary (shammah) 5 Jeff Garland (az_sw_dude) 4 Joerg Walter 4 Jeremy Siek 3 John R. Bandela 2 Marshall Clow 2 Joel de guzman (djowel) 2 Eric Friedman (ebf) 2 Thorsten Ottosen (nesotto) 2 Rene Rivera (grafik) 2 Jonathan Turkanis 2 David Abrahams 1 Beman Dawes 1 Kevlin Henney 1 Hubert Holin 1 Samuel Kremp 1 John Maddock 1 Jens Maurer 1 Vladimir Prus 1 Daniel Wallin 1 Here are the bugs, sorted by assignee: Assignee: az_sw_dude <http://sourceforge.net/users/az_sw_dude/> Summary: wrong usage of ios_base::narrow Bug #: 989487 <http://sourceforge.net/tracker/index.php?func=detail&aid=989487&group_id=75…> Assignee: az_sw_dude <http://sourceforge.net/users/az_sw_dude/> Summary: date_time type conversion warning Bug #: 1069225 <http://sourceforge.net/tracker/index.php?func=detail&aid=1069225&group_id=7…> Assignee: az_sw_dude <http://sourceforge.net/users/az_sw_dude/> Summary: local_adjustor::utc_to_local throws 'Time label invalid' Bug #: 1220011 <http://sourceforge.net/tracker/index.php?func=detail&aid=1220011&group_id=7…> Assignee: az_sw_dude <http://sourceforge.net/users/az_sw_dude/> Summary: bjam don`t copy lib & dll files to stage Bug #: 1402743 <http://sourceforge.net/tracker/index.php?func=detail&aid=1402743&group_id=7…> Assignee: beman_dawes <http://sourceforge.net/users/beman_dawes/> Summary: linker error mingw 3.4.5 Bug #: 1426819 <http://sourceforge.net/tracker/index.php?func=detail&aid=1426819&group_id=7…> Assignee: daniel_wallin <http://sourceforge.net/users/daniel_wallin/> Summary: [Parameter] Docco error section 2.7.2 Bug #: 1378446 <http://sourceforge.net/tracker/index.php?func=detail&aid=1378446&group_id=7…> Assignee: david_abrahams <http://sourceforge.net/users/david_abrahams/> Summary: bug in output the range to an ostream Bug #: 1427230 <http://sourceforge.net/tracker/index.php?func=detail&aid=1427230&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: EdgeListS = setS for adjacency_list does not work Bug #: 1163077 <http://sourceforge.net/tracker/index.php?func=detail&aid=1163077&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: LEDA graph adaptors do not handle hidden nodes properly Bug #: 1168431 <http://sourceforge.net/tracker/index.php?func=detail&aid=1168431&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: random_vertex/random_edge are unnecessarily inefficient Bug #: 1204684 <http://sourceforge.net/tracker/index.php?func=detail&aid=1204684&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: Document copy_component Bug #: 1204688 <http://sourceforge.net/tracker/index.php?func=detail&aid=1204688&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: reverse_graph and constness of property maps Bug #: 1246336 <http://sourceforge.net/tracker/index.php?func=detail&aid=1246336&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: Bundled graph properties Bug #: 1420498 <http://sourceforge.net/tracker/index.php?func=detail&aid=1420498&group_id=7…> Assignee: djowel <http://sourceforge.net/users/djowel/> Summary: Miss ' = ParserT()' Bug #: 907299 <http://sourceforge.net/tracker/index.php?func=detail&aid=907299&group_id=75…> Assignee: djowel <http://sourceforge.net/users/djowel/> Summary: spirit insert_key_actor.hpp Bug #: 1059936 <http://sourceforge.net/tracker/index.php?func=detail&aid=1059936&group_id=7…> Assignee: ebf <http://sourceforge.net/users/ebf/> Summary: boost::blank - missing operators Bug #: 1191356 <http://sourceforge.net/tracker/index.php?func=detail&aid=1191356&group_id=7…> Assignee: ebf <http://sourceforge.net/users/ebf/> Summary: [variant] Bug in recursive_wrapper_fwd.hpp Bug #: 1359257 <http://sourceforge.net/tracker/index.php?func=detail&aid=1359257&group_id=7…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: AIX 4.3 SIGSEGV at thread termination Bug #: 551577 <http://sourceforge.net/tracker/index.php?func=detail&aid=551577&group_id=75…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: boost::threads uses msvc only function? Bug #: 568951 <http://sourceforge.net/tracker/index.php?func=detail&aid=568951&group_id=75…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: BCB6 throw EExternelException Bug #: 596149 <http://sourceforge.net/tracker/index.php?func=detail&aid=596149&group_id=75…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: thread_cleanup problems Bug #: 649291 <http://sourceforge.net/tracker/index.php?func=detail&aid=649291&group_id=75…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: Mac implementation of threads is CPU hog Bug #: 885045 <http://sourceforge.net/tracker/index.php?func=detail&aid=885045&group_id=75…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: condition variables and recursive_mutex Bug #: 1072605 <http://sourceforge.net/tracker/index.php?func=detail&aid=1072605&group_id=7…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: compiler error on Mac implementation of threads Bug #: 1201779 <http://sourceforge.net/tracker/index.php?func=detail&aid=1201779&group_id=7…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: Exception safety in class 'thread' Bug #: 1305885 <http://sourceforge.net/tracker/index.php?func=detail&aid=1305885&group_id=7…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: Memory leak in tss Bug #: 1424965 <http://sourceforge.net/tracker/index.php?func=detail&aid=1424965&group_id=7…> Assignee: grafik <http://sourceforge.net/users/grafik/> Summary: boost jam problem with parallel builds Bug #: 1234224 <http://sourceforge.net/tracker/index.php?func=detail&aid=1234224&group_id=7…> Assignee: grafik <http://sourceforge.net/users/grafik/> Summary: boost.build needs fixes for HP/UX Bug #: 1395924 <http://sourceforge.net/tracker/index.php?func=detail&aid=1395924&group_id=7…> Assignee: hubert_holin <http://sourceforge.net/users/hubert_holin/> Summary: Cannot compile octonion_test.cpp because of bug in sinc.hpp Bug #: 751289 <http://sourceforge.net/tracker/index.php?func=detail&aid=751289&group_id=75…> Assignee: jbandela <http://sourceforge.net/users/jbandela/> Summary: Compiler error for tokenizer on Solaris Bug #: 976241 <http://sourceforge.net/tracker/index.php?func=detail&aid=976241&group_id=75…> Assignee: jbandela <http://sourceforge.net/users/jbandela/> Summary: token_iterator::at_end() result is inversed Bug #: 1338326 <http://sourceforge.net/tracker/index.php?func=detail&aid=1338326&group_id=7…> Assignee: jmaurer <http://sourceforge.net/users/jmaurer/> Summary: Diff in state of mersenne_twister gen between GCC3.41 & CW9 Bug #: 1115124 <http://sourceforge.net/tracker/index.php?func=detail&aid=1115124&group_id=7…> Assignee: joerg_walter <http://sourceforge.net/users/joerg_walter/> Summary: bug in ublas/storage.hpp Bug #: 1095697 <http://sourceforge.net/tracker/index.php?func=detail&aid=1095697&group_id=7…> Assignee: joerg_walter <http://sourceforge.net/users/joerg_walter/> Summary: dead links in uBLAS page Bug #: 1169273 <http://sourceforge.net/tracker/index.php?func=detail&aid=1169273&group_id=7…> Assignee: joerg_walter <http://sourceforge.net/users/joerg_walter/> Summary: Documentation not available on web site: Bug #: 1228242 <http://sourceforge.net/tracker/index.php?func=detail&aid=1228242&group_id=7…> Assignee: joerg_walter <http://sourceforge.net/users/joerg_walter/> Summary: uBLAS::subslice doesn't work Bug #: 1292635 <http://sourceforge.net/tracker/index.php?func=detail&aid=1292635&group_id=7…> Assignee: johnmaddock <http://sourceforge.net/users/johnmaddock/> Summary: Adding boost::is_complex to type_traits.hpp Bug #: 1315712 <http://sourceforge.net/tracker/index.php?func=detail&aid=1315712&group_id=7…> Assignee: jsiek <http://sourceforge.net/users/jsiek/> Summary: invalid result for File Dependency Examp Bug #: 551110 <http://sourceforge.net/tracker/index.php?func=detail&aid=551110&group_id=75…> Assignee: jsiek <http://sourceforge.net/users/jsiek/> Summary: Spelling of Edmonds-Karp-Algorithm Bug #: 1226292 <http://sourceforge.net/tracker/index.php?func=detail&aid=1226292&group_id=7…> Assignee: jsiek <http://sourceforge.net/users/jsiek/> Summary: g++ v3.2.3 inker error for read_graphviz ih boost v1.33.1 Bug #: 1378907 <http://sourceforge.net/tracker/index.php?func=detail&aid=1378907&group_id=7…> Assignee: kevlin <http://sourceforge.net/users/kevlin/> Summary: lexical_cast & pure virtual functions & VC 8 STL Bug #: 1358600 <http://sourceforge.net/tracker/index.php?func=detail&aid=1358600&group_id=7…> Assignee: mclow <http://sourceforge.net/users/mclow/> Summary: Solaris - once.cpp compile error Bug #: 549162 <http://sourceforge.net/tracker/index.php?func=detail&aid=549162&group_id=75…> Assignee: mclow <http://sourceforge.net/users/mclow/> Summary: mistake in documentation of condition Bug #: 1364416 <http://sourceforge.net/tracker/index.php?func=detail&aid=1364416&group_id=7…> Assignee: nesotto <http://sourceforge.net/users/nesotto/> Summary: boost.range and 'const char[]'. Bug #: 1272315 <http://sourceforge.net/tracker/index.php?func=detail&aid=1272315&group_id=7…> Assignee: nesotto <http://sourceforge.net/users/nesotto/> Summary: [Boost.Range]boost::const_begin calls non-qualified 'begin' Bug #: 1361686 <http://sourceforge.net/tracker/index.php?func=detail&aid=1361686&group_id=7…> Assignee: samuel_k <http://sourceforge.net/users/samuel_k/> Summary: format: assert when parsing invalid pattern Bug #: 1326132 <http://sourceforge.net/tracker/index.php?func=detail&aid=1326132&group_id=7…> Assignee: shammah <http://sourceforge.net/users/shammah/> Summary: ct_gcd_lcm.hpp compilation error Bug #: 558174 <http://sourceforge.net/tracker/index.php?func=detail&aid=558174&group_id=75…> Assignee: shammah <http://sourceforge.net/users/shammah/> Summary: pool::purge_memory() does not reset next_size Bug #: 984124 <http://sourceforge.net/tracker/index.php?func=detail&aid=984124&group_id=75…> Assignee: shammah <http://sourceforge.net/users/shammah/> Summary: Borland compiler error with Pool, boost::pool_allocator Bug #: 988124 <http://sourceforge.net/tracker/index.php?func=detail&aid=988124&group_id=75…> Assignee: shammah <http://sourceforge.net/users/shammah/> Summary: perfomance: memory cleanup for pool takes too long Bug #: 995270 <http://sourceforge.net/tracker/index.php?func=detail&aid=995270&group_id=75…> Assignee: shammah <http://sourceforge.net/users/shammah/> Summary: boost::pool_allocator breaks with vector of vectors Bug #: 1179641 <http://sourceforge.net/tracker/index.php?func=detail&aid=1179641&group_id=7…> Assignee: turkanis <http://sourceforge.net/users/turkanis/> Summary: rational operator&lt; can overflow Bug #: 798357 <http://sourceforge.net/tracker/index.php?func=detail&aid=798357&group_id=75…> Assignee: turkanis <http://sourceforge.net/users/turkanis/> Summary: problem with boost::iostreams when compiled with Visual C++ Bug #: 1365752 <http://sourceforge.net/tracker/index.php?func=detail&aid=1365752&group_id=7…> Assignee: vladimir_prus <http://sourceforge.net/users/vladimir_prus/> Summary: multitoken broken in program_options 1.33 Bug #: 1266877 <http://sourceforge.net/tracker/index.php?func=detail&aid=1266877&group_id=7…> -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

2 1

patches status
by Marshall Clow 12 Feb '06

12 Feb '06

These are the submitted patches that are waiting to be integrated/rejected/whatever. A bunch of these have been cleaned up in the last couple of weeks; we're down to only two! Thanks to everyone who has helped! As always, if you see one that is mis-assigned, or you think that one marked "nobody" is right for you, please don't hesitate to jump in. ;-) Thank you for your cooperation! Patches per assignee: Robert Ramey 1 Ronald Garcia 1 Here are the currently submitted patches, sorted by assignee. Assignee: ramey <http://sourceforge.net/users/ramey/> Summary: Boost.Serialization for std::bitset Bug #: 1029258 <http://sourceforge.net/tracker/index.php?func=detail&aid=1029258&group_id=7…> Assignee: rgarcia <http://sourceforge.net/users/rgarcia/> Summary: [concept_check.hpp] remove unused variable warning in msvc Bug #: 1388901 <http://sourceforge.net/tracker/index.php?func=detail&aid=1388901&group_id=7…> -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

[Review] Shmem Library
by fred＠styleadvisor.com 12 Feb '06

12 Feb '06

Hello everyone, The review of the proposed Boost Shmem library written by Ion Gaztañaga starts today (February 6th, 2006) and ends after 10 days (February 16, 2006). Documentation for the library can be found online here: http://tinyurl.com/e2os3 Both documentation and the library itself can be downloaded here: http://tinyurl.com/9t5qy --------------------------------------------------- About the library: The Shmem Library simplifies the use of shared memory and provides some STL compatible allocators that allow shared memory STL container placement. It also offers helper classes, such as offset pointers, process shared mutexes, condition variables, and named semaphores. Library users can apply all STL algorithms and utilities with created shared memory objects. Shmem also wants to present a portable implementation, unifying UNIX and Windows shared memory object creation, providing simple wrapper classes. Shmem offers the following to the user: - Portable synchronization primitives for shared memory, including shared mutexes and shared condition variables. - Dynamic allocation of portions of a shared memory segment. - Named allocation in shared memory. Shmem can create objects in shared memory and associate it with a c-string offering a similar mechanism to a named new/delete. Created object can be found by other processes using Shmem framework. - Offset pointers that can be safely placed in shared memory to point to another object of the same shared memory segment even if the memory is mapped to a different address. - STL compatible shared memory allocators so that STL containers can be placed in shared memory. Shmem also offers a pooled node allocator to save and optimize shared memory allocation in node containers. - STL compatible containers for systems with STL implementations that cannot deal with shared memory. The user can map shared memory to different addresses and use STL compatible containers and algorithms. Useful to store common data or implement shared memory databases. These containers also show how STL compatible containers can make use of shared memory STL compatible allocators to place such containers in the shared memory. Shmem also offers the basic_string pseudo-container to use full-powered C++ strings in shared memory. --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Fred Bertsch Review Manager

10 18

[hash] Code Warrior failure
by Daniel James 11 Feb '06

11 Feb '06

Hi, Does anyone have any idea why hash_fwd_test_2 is failing on Code Warrior? The point of the test is just to include the forwarding headers without the implementation to test that this works. For some reason test::hash_value<test::test_type1<std::string> >() is getting instantiated even though it isn't used - but it seems that test::hash_value<test::test_type1<int> >() isn't instantiated. Does anyone know how to prevent if from being instantiated? http://tinyurl.com/8ecfm Daniel

2 2