[ 297 open tickets today, 304 yesterday ] [ Thanks to everyone for their work on triage; those three slackers "None", "Nobody", and "<Blank>" are no longer responsible for half the open bugs! ] If you are maintaining a library, and have not logged into the trac system at <http://svn.boost.org/trac/boost/>, please do so ASAP. Until you do that, no tickets can be assigned to you, and will remain under "None". Instructions on working with tickets can be found at: <http://svn.boost.org/trac/boost/wiki/TicketWorkflow> 22 grafik 22 dgregor 21 bemandawes 18 johnmaddock 17 None 15 jsiek 15 az_sw_dude 14 vladimir_prus 13 rogeeff 11 turkanis 11 dave 9 agurtovoy 8 ramey 7 speedsnail 7 samuel_k 7 pdimov 6 shammah 6 nesotto 6 jbandela 6 anthonyw 5 witt 4 urzuga 4 nobody 4 mark_rodgers 4 fcacciola 4 doug_gregor 4 djowel 3 jmaurer 3 ebf 3 dlwalker 3 danielw 2 hubert_holin 2 alnsn 2 <Blank> 1 nmusatti 1 mistevens 1 kevlin 1 hkaiser 1 garcia 1 eric_niebler 1 danieljames 1 asutton 1 aaron_windsor None 1080 boost::interprocess win32 global file mapping issue None 1079 boost-1.34.0 fails to compile. concept checks not satisfied. None 1074 FreeBSD specific patches to boost 1.34.0 None 1070 [iostreams]boost\iostreams\copy.hpp line80 copy_impl None 1068 Mersenne twister disables streaming for Visual C++ None 1059 random_on_sphere can be made 10 times faster! None 1033 iostreams::restrict doesn't work on an iostreams::file_source None 1027 [ptr_container] optional serialization support None 1023 inspect None 1006 No mingw.jam None 1003 [iostreams] copy-paste error in typedefs for wchar multichar_filters None 1002 [iostreams] close_impl<closable_tag> does not comply with spec None 991 [pool] None 987 configure passes wrong toolset to bjam None 982 x64 documentation for windows None 980 boost.format vc8/win32 compilation warning None 960 [random] lognormal_distribution problem <Blank> 1011 amd64: #error Boost.Numeric.Interval: Please specify rounding control mechanism. <Blank> 924 Convenience function for const map read aaron_windsor 778 top-level configure is broken agurtovoy 1051 MPL header ordering triggers bug agurtovoy 1049 Getting mpl/has_xxx.hpp to compile on AIX agurtovoy 1001 gcc 4.1.2 segfaults on mpl/test/apply.cpp agurtovoy 861 [mpl] Detect nested template members with has_template_xxx agurtovoy 816 duplicat initial members -> erase_key postcond. fail agurtovoy 761 [mpl] evc4 port agurtovoy 640 documentation mistake agurtovoy 637 Adjusts mpl::pair concept to be compatible with STL pairs agurtovoy 588 mpl::remove compile error with gcc 4.1.0 alnsn 839 lexical_cast - local variable shadow patch alnsn 754 boost::any - typeid comparison across shared boundaries anthonyw 1053 Error using boost::mutex and C++/CLI anthonyw 659 provide an abstract "Task" type based on Boost.Threads anthonyw 881 errors when build with Apache stdcxx anthonyw 876 xtime documentation incomplete anthonyw 868 [thread] thread_specific_ptr::element_type ? anthonyw 802 [thread] MSVS: Allow use of thread headers with /Za asutton 693 Add clique detection algorithms DFMax_ Bron-Kerbosch az_sw_dude 1078 from_iso_string cannot read the output from to_iso_string az_sw_dude 1028 typo in boost header: date_time/time_defs.hpp az_sw_dude 224 Extensions to std::string: compareIgnoreCase()_ trim()_ ... az_sw_dude 187 locale az_sw_dude 17 Socket wrapper class az_sw_dude 890 date_time library supports only the current dst rule az_sw_dude 889 Insane Dependencies az_sw_dude 827 Unused variable in format date parser az_sw_dude 642 operator<< for gregorian::date_duration not found az_sw_dude 614 new timezone db file for #1471723 - 2007 DST support az_sw_dude 605 support new 2007 DST rules for timezone db az_sw_dude 604 from_ftime incorrectly processes FILETIME filled with zeros az_sw_dude 596 make timezone csv file C/C++ compatible az_sw_dude 316 date_time type conversion warning az_sw_dude 287 wrong usage of ios_base::narrow bemandawes 1073 operations.cpp_ dummy_first_name lifetime bemandawes 1065 cannot find -lboost_filesystem bemandawes 1061 boost::filesystem::basic_recursive_directory_iterator fails on empty directories. bemandawes 1014 rename throws an exception that is not documented bemandawes 995 'multiply defined symbols' when including <boost/filesystem.hpp> in different source files bemandawes 897 exists() throws exeption on existing but locked file on wind bemandawes 842 typo in auto_unit_test.hpp Revision 1.17 bemandawes 824 BOOST_IOSTREAMS_HAS_LSEEK64 on Mac OS X bemandawes 823 Seekable file_descriptor_source /sink? bemandawes 800 [filesystem] chdir() bemandawes 752 directory_iterator doesn't work with catch bemandawes 680 significantly different timer class behaviour on Win and Lin bemandawes 662 [filesystem] portable_posix_name() may fail on premain call bemandawes 621 filesystem::path as a template bemandawes 607 Log level names wrong in documentation bemandawes 600 VC8 can't find windows.h even though environment is correct! bemandawes 590 mkstemp bemandawes 559 linker error mingw 3.4.5 bemandawes 366 handle double '/' in the boost::filesystem bemandawes 294 unicode support in boost::filesystem bemandawes 222 Code analysis_ flaw detection_ debugging danieljames 1064 problem on platforms with no errno.h header file danielw 1054 Parameter takes an "infinite" amount of time to compile with the Intel compiler. danielw 1044 Argument pack inaccessable in a functions return type danielw 863 [parameter] fix operator|| for lazy binding dave 1085 Python rules for compiling in Mac OS X dave 1066 Patch to make Boost.Python compile on SunCC dave 1020 Boost.Iterator proposal to add is_constant_iterator dave 1019 iterator_facade::pointer should be the return type of operator-> (DR 445) dave 1010 linking boost.python on freebsd dave 918 __doc__ strings dave 916 BPL Support for Python Callable Objects dave 910 gcc strict-aliasing problems with python dave 903 inconsistent usage of function pointer typedefs dave 865 Use of C++0x keyword as identifier dave 857 add shared_ptr< const T> support dgregor 954 boost::dynamic_properties has no copy-constructor dgregor 862 [utility] Make result_of handle lambda expressions dgregor 746 max flow with lower bounds (capacities) dgregor 1067 Function needs to use pass-by-reference internally dgregor 891 Bunch of compilation error reported while using function.hpp dgregor 870 boost::graph::graph_utility.hpp is_connected() bad call dgregor 852 Problem with Boost and GCC 4.1 dgregor 829 Implicit graph not implement dgregor 738 Memory leaks with signal::connect? dgregor 736 Const correctness violation dgregor 735 Fruchterman-Reingold grid performance can be improved dgregor 733 Numbered headers don't work with "preferred" syntax dgregor 732 Johnson All-Pairs needs better "no path" information dgregor 708 Dijkstra no_init version should not require VertexListGraph dgregor 556 Bundled graph properties dgregor 447 reverse_graph and constness of property maps dgregor 403 Document copy_component dgregor 402 random_vertex/random_edge are unnecessarily inefficient dgregor 395 BGL graph types do not support allocators dgregor 375 LEDA graph adaptors do not handle hidden nodes properly dgregor 373 LEDA graph adaptors for undirected graphs dgregor 372 adjacency_matrix should model BidirectionalGraph djowel 664 crash in boost::spirit::parse djowel 543 Embedded python won't compile djowel 314 spirit insert_key_actor.hpp djowel 241 Miss " = ParserT()" dlwalker 766 "Bug" in comment (x2) dlwalker 653 [integer] add support for integers longer than long dlwalker 613 boost/crc.hpp uses non-standard conforming syntax doug_gregor 1087 Mismatch between BBv2 and bjam toolsets in configure script. doug_gregor 1076 compile error: disconnecting struct with operator()() doesn't work in VS2005 SP1 doug_gregor 1072 assertion failed in dijkstra algorithm doug_gregor 1021 [Graph][reverse_graph] Problem using reverse_graph adapter with an adapted user defined graph ebf 993 Variant should use least common multiple of alignments_ rather than maximum ebf 965 [doc] boost::variant tutorial - final example uses v1_v2 should be seq1_seq2 ebf 547 [variant] Compile time checked getter eric_niebler 1071 Request for BOOST_REVERSE_FOREACH and rationale fcacciola 818 No zero-argument in_place() fcacciola 765 optional documentation fcacciola 617 Numeric Conversion Documentation minor bug fcacciola 282 boost::optional<enum> fails with /CLR garcia 1045 [multi_array] Need a proper swap operation grafik 1088 Docs for template escape feature. grafik 1041 Cygwin requires PATH setting. grafik 1040 boost.devel archive at ActiveState disconnected grafik 1031 AmigaOS fixes for bjam grafik 989 Boost build does not support building universal binaries on macintosh grafik 714 [jam] HardLink rule on NT platform grafik 121 toolset initialization grafik 94 Better reporting of failed expectation. grafik 93 Testing problems on AIX and OSF grafik 1062 Cygwin install stage fails with combination of patches grafik 977 bjam crashes when compiled with gcc 4.2 grafik 959 linking fails when Boost is compiled with STLport 5.1.* on Linux (names mismatch) grafik 896 <native-wchar_t>off does not work when build with vc-8.0 grafik 798 bjam: always define OSPLAT grafik 721 Generated files "@()" don't work in regular expressions. grafik 683 libraries won't build grafik 616 Boost Jam_ and non english directorys grafik 552 Building universal binary on MacOSX grafik 546 boost.build needs fixes for HP/UX grafik 497 Unable to build boost with Dinkumware STL version 4.02 grafik 481 Linker Problems with VC .NET 2003 / STLPort / Boost grafik 431 boost jam problem with parallel builds hkaiser 1077 Spirit integer parser does not always detect integer overflow hubert_holin 647 octonion documentation bug hubert_holin 162 Cannot compile octonion_test.cpp because of bug in sinc.hpp jbandela 665 bug in char_separator jbandela 501 token_iterator::at_end() result is inversed jbandela 306 Visual C++ "Language Extensions" support jbandela 283 Compiler error for tokenizer on Solaris jbandela 279 SLOOOWW tokenizer compilation on VC++6.0 jbandela 259 Problem compiling :/ jmaurer 920 Proposed extension to random library jmaurer 819 uniform_int<> with type's maximum availaible range error jmaurer 351 Diff in state of mersenne_twister gen between GCC3.41 & CW9 johnmaddock 1083 boost_regex 1.34.0 uses ICU library without linking to it johnmaddock 1081 Empty string rejected as perl-style regex johnmaddock 1075 [doc] incorrect comment johnmaddock 1008 Undocumented type traits. johnmaddock 905 Assertion failed in token_iterator.hpp johnmaddock 871 Problem build boost 1.33.1 on Aix 4.3.3 johnmaddock 883 errors when build with Apache stdcxx johnmaddock 812 Crash on RH machine with gcc < 3.4 johnmaddock 775 Warnings on MSVC 2005 johnmaddock 764 [regex] add support for a BOOST_NO_CREGEX mode johnmaddock 679 regex - perl syntax affects what gets matched johnmaddock 633 [config] evc4 port johnmaddock 591 make portable stdint.h from boost code johnmaddock 540 Please add support for Borland C++ Builder 2006 johnmaddock 502 Problem running configure for unsupported platform johnmaddock 492 Adding boost::is_complex to type_traits.hpp johnmaddock 360 Regex johnmaddock 315 Implement operator[] for Tokenizer jsiek 900 graphml reader namespace handling is broken jsiek 875 No iterator based constructor for adjacency_matrix jsiek 815 remove_edge core dumps on self-circle jsiek 813 concept_check.hpp unused variable warning jsiek 694 Add Maximum Common Subgraph (MCS) algorithm jsiek 636 strange compiling problem for transitive_closure jsiek 580 Max Flow Algorithm jsiek 575 Calling subgraph::global_to_local on a root graph jsiek 541 [concept_check.hpp] remove unused variable warning in msvc jsiek 416 Spelling of Edmonds-Karp-Algorithm jsiek 193 Check ordering for mutexes jsiek 182 Support aspect-orientation jsiek 116 creating my own properties jsiek 100 more use of the concept "allocator" jsiek 69 Boost with Dinkumware C++ Library !? kevlin 913 Specialization of lexical_cast mark_rodgers 821 allow_unregistered improvement mark_rodgers 558 add database library? mark_rodgers 87 function to get the size of a array mark_rodgers 30 parser mistevens 688 ublas: bug in mapped_vector_of_mapped_vector nesotto 807 boost::assignment documentation: mathematical "typo" nesotto 730 The ptr_map iterator cannot be dereference to value type nesotto 723 local_time_facet error in VS2005 Win2003 nesotto 624 bug in boost::range_detail nesotto 518 [Boost.Range]boost::const_begin calls non-qualified 'begin' nesotto 471 boost.range and "const char[]". nmusatti 285 Borland compiler error with Pool_ boost::pool_allocator nobody 930 iostream and zlib nobody 922 Lexical cast and wide characters nobody 884 [iostreams] workaround for the boost + stdcxx on MSVC 7.1 nobody 795 [ublas] vector::back() pdimov 1084 atomic_count_gcc.hpp tries to #include nonexistant header pdimov 1069 _InterlockedExchange_ _InterlockedExchangeAdd have wrong signature pdimov 997 error in boost::bind doc pdimov 911 [bind] inline placeholder macro pdimov 810 support for weak_ptr binding pdimov 445 Can't delete automatically in circularly included object. pdimov 398 Support for embedded VC++ 4.0 ramey 1086 Serialization of weak_ptr produces invalid XML ramey 1038 "<" and ">" should be excaped in xml_oarchive ramey 1036 assert failure in oserializer.hpp:418 ramey 969 basic_binary_iprimitive::load_binary bug ramey 968 xml_grammar - incorrect define char ramey 961 boost::basic_binary_oprimitive not instantiated correctly ramey 874 Ability to partially specialize implementation_level ramey 878 error C2039: 'mbstate_t' : is not a member of 'std' rogeeff 1060 no example sources in online docs for Boost::Test rogeeff 1050 BOOST_CHECK_CLOSE_FRACTION documentation missing rogeeff 1032 typo in Boost.Test documentation rogeeff 1030 execution_monitor.ipp #warning directive breaks compilation on MSVC 8.0 rogeeff 999 prg_exec_fail3 fails on release variant rogeeff 998 prg_exec_fail2 fail on ppc rogeeff 962 Missing links in Test library documentation rogeeff 956 Doc error in test examples. rogeeff 893 grammatical error in error message rogeeff 847 [Test Library] How to init/free a singleton rogeeff 762 [test] evc4 issue with SEH support rogeeff 747 failing on 6 targets in MacOS X rogeeff 645 [test] no eh exception handling functions on evc4 samuel_k 859 boost::format ignores a user defined locale samuel_k 849 boost::format and operator priority rule samuel_k 713 Boost.Format doesn't work on MSVC with /vd2 compiler option samuel_k 704 format zero length string msvc-8 samuel_k 585 64 bit compile warning/error for boost::format samuel_k 570 boost::format parse method doesn't work samuel_k 493 format: assert when parsing invalid pattern shammah 840 pool allocator - local variable shadow patch shammah 836 warning using pool.hpp shammah 386 boost::pool_allocator breaks with vector of vectors shammah 290 perfomance: memory cleanup for pool takes too long shammah 284 pool::purge_memory() does not reset next_size shammah 88 ct_gcd_lcm.hpp compilation error speedsnail 615 thread identification and getting the id speedsnail 204 Add a monitor class speedsnail 194 Exchange results between several thread calls speedsnail 174 cooperation with ACE framework speedsnail 173 more synchronization primitives for the threads classes speedsnail 172 cooperation with ZThread package speedsnail 171 class for function calls that are not thread safe turkanis 869 [iostreams] patch for building by BBv2 turkanis 856 iostreams file_descriptor::write fails under Win32 turkanis 822 Incorrect usage of bad_write()_ bad_seek() etc. turkanis 817 Performance problem in iostreams turkanis 791 iostreams::tee_filter is for output only turkanis 786 bug in iostreams/copy.hpp line 81 turkanis 699 Changing size of memory-mapped file on Windows turkanis 586 iostreams // file_descriptor::seek BUG on files > 4 GB turkanis 579 boost.iostreams file_descriptor and sharing turkanis 525 problem with boost::iostreams when compiled with Visual C++ turkanis 484 Boost.Iostreams and newline translation urzuga 864 [lambda][utility] Make lambda support result<> urzuga 781 Lambda: (_1 + "y")(string("x")) Doesn't Compile urzuga 574 [boost::lambda] Compile error with libstdc++ debug mode urzuga 426 lambda vs pure virtual functions vladimir_prus 1058 Cygwin libraries & GNU libtool vladimir_prus 1055 boost build system uses wrong `ar` for cross compilation. vladimir_prus 1042 Build: Incorrect parameters for IA64 architecture in MSVC toolset vladimir_prus 985 Free features don't work when building boost vladimir_prus 879 Building Boost with Apache C++ Standard Library (STDCXX) vladimir_prus 853 path with spaces not always handled vladimir_prus 428 Please add support for PDSK compilers for x64 and IA64 vladimir_prus 850 program_options strips off escaped quotes in some situations vladimir_prus 808 [program_options] parse_config_file documentation bug vladimir_prus 689 [program_options] Endless loop with long default arguments vladimir_prus 674 find-library for boost decorated names vladimir_prus 644 Boost.Build v2 build script help for evc4 vladimir_prus 469 multitoken broken vladimir_prus 342 program_options Can one have options with optional values? witt 1046 Boost.Python quickstart instructions mention nonexistent target witt 973 zip_iterator has value_type == reference witt 957 The "Getting Started" page does not mention the stdlib option witt 834 Homepage regression links witt 145 filter iterator adaptor should be able to be bidirectional -- -- 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.
From: Marshall Clow
[ 297 open tickets today, 304 yesterday ] [ Thanks to everyone for their work on triage; those three slackers "None", "Nobody", and "<Blank>" are no longer responsible for half the open bugs! ]
Would it be worth assigning all the tickets belonging to Nobody and <Blank> to None? (And while we are at it, dgregor should probably take over all of doug_gregor's tickets). -- Martin Bonner Project Leader PI SHURLOK LTD Telephone: +44 1223 441434 / 203894 (direct) Fax: +44 1223 203999 Email: martin.bonner@pi-shurlok.com www.pi-shurlok.com
At 3:05 PM +0100 7/12/07, Martin Bonner wrote:
From: Marshall Clow
[ 297 open tickets today, 304 yesterday ] [ Thanks to everyone for their work on triage; those three slackers "None", "Nobody", and "<Blank>" are no longer responsible for half the open bugs! ]
Would it be worth assigning all the tickets belonging to Nobody and <Blank> to None?
Actually, I know who the <Blank> tickets belong to - he just hasn't created a trac ID yet, so I can't assign them to him/them. I think that's a short term problem, which will go away pretty quickly.
(And while we are at it, dgregor should probably take over all of doug_gregor's tickets).
Yeah, he probably should ;-) -- -- 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.
on Thu Jul 12 2007, "Martin Bonner" <Martin.Bonner-AT-pi-shurlok.com> wrote:
From: Marshall Clow
[ 297 open tickets today, 304 yesterday ] [ Thanks to everyone for their work on triage; those three slackers "None", "Nobody", and "<Blank>" are no longer responsible for half the open bugs! ]
Would it be worth assigning all the tickets belonging to Nobody and <Blank> to None?
There's no easy way to do it :-{ -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
All, I'm attempting to upgrade to boost_1_34_0 from boost_1_33_1 and I get the following warnings from a hashed_unique index. The same code compiles clean on boost_1_33_1 with gcc-4.1.1 and gcc-4.1.2. Am I doing something wrong or this is a deficiency introduced in 1_34_0? Thanks, Marius Sample code: boost::multi_index::hashed_unique < boost::multi_index::tag<server>, boost::multi_index::const_mem_fun < SessionLink, int, &SessionLink::serverFD > > Generated warnings: /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:353: warning: passing 'bool' chooses 'int' over 'long unsigned int' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:353: warning: in call to 'size_t boost::hash_value(int)' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:353: warning: passing 'bool' chooses 'int' over 'long int' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:353: warning: in call to 'size_t boost::hash_value(int)' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:353: warning: passing 'bool' chooses 'int' over 'unsigned int' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:353: warning: in call to 'size_t boost::hash_value(int)' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp: In member function 'size_t boost::hash<unsigned char>::operator()(unsigned char) const': /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:356: warning: passing 'unsigned char' chooses 'int' over 'long unsigned int' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:356: warning: in call to 'size_t boost::hash_value(int)' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:356: warning: passing 'unsigned char' chooses 'int' over 'long int' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:356: warning: in call to 'size_t boost::hash_value(int)' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:356: warning: passing 'unsigned char' chooses 'int' over 'unsigned int' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:356: warning: in call to 'size_t boost::hash_value(int)' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp: In member function 'size_t boost::hash<short unsigned int>::operator()(short unsigned int) const': /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:361: warning: passing 'short unsigned int' chooses 'int' over 'long unsigned int' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:361: warning: in call to 'size_t boost::hash_value(int)' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:361: warning: passing 'short unsigned int' chooses 'int' over 'long int' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:361: warning: in call to 'size_t boost::hash_value(int)' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:361: warning: passing 'short unsigned int' chooses 'int' over 'unsigned int' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:361: warning: in call to 'size_t boost::hash_value(int)' ********************************************************************** This communication and all information (including, but not limited to, market prices/levels and data) contained therein (the "Information") is for informational purposes only, is confidential, may be legally privileged and is the intellectual property of ICAP plc and its affiliates ("ICAP") or third parties. No confidentiality or privilege is waived or lost by any mistransmission. The Information is not, and should not be construed as, an offer, bid or solicitation in relation to any financial instrument or as an official confirmation of any transaction. The Information is not warranted, including, but not limited, as to completeness, timeliness or accuracy and is subject to change without notice. ICAP assumes no liability for use or misuse of the Information. All representations and warranties are expressly disclaimed. The Information does not necessarily reflect the views of ICAP. Access to the Information by anyone else other than the recipient is unauthorized and any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. **********************************************************************
Hello Marius, Marius Lazer ha escrito:
All,
I'm attempting to upgrade to boost_1_34_0 from boost_1_33_1 and I get the following warnings from a hashed_unique index. The same code compiles clean on boost_1_33_1 with gcc-4.1.1 and gcc-4.1.2.
Am I doing something wrong or this is a deficiency introduced in 1_34_0?
Thanks, Marius
Sample code:
boost::multi_index::hashed_unique < boost::multi_index::tag<server>, boost::multi_index::const_mem_fun < SessionLink, int, &SessionLink::serverFD > >
Generated warnings:
/home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:353: warning: passing 'bool' chooses 'int' over 'long unsigned int'[...]
I think this problem is not actually related to Boost.MultiIndex, but to Boost.Hash. Could you please try to compile the following // just including this #include <boost/functional/hash/hash.hpp> both with Boost 1.33.1 and 1.34? Same behavior? Looking fwd to your feedback. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín, I figured out the problem is in boost.hash which is used by multi-index. That #include alone compiles clean on both 1.31.1 and 1.34.0. I also compared the source code and lots of static_cast<> disappeared in 1.34.0. Thanks, Marius -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Joaquín Mª López Muñoz Sent: Thursday, July 12, 2007 10:43 AM To: boost@lists.boost.org Subject: Re: [boost] multi-index warnings Hello Marius, Marius Lazer ha escrito:
All,
I'm attempting to upgrade to boost_1_34_0 from boost_1_33_1 and I get the following warnings from a hashed_unique index. The same code compiles clean on boost_1_33_1 with gcc-4.1.1 and gcc-4.1.2.
Am I doing something wrong or this is a deficiency introduced in 1_34_0?
Thanks, Marius
Sample code:
boost::multi_index::hashed_unique < boost::multi_index::tag<server>, boost::multi_index::const_mem_fun < SessionLink, int, &SessionLink::serverFD > >
Generated warnings:
/home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:353: warning: passing 'bool' chooses 'int' over 'long unsigned int'[...]
I think this problem is not actually related to Boost.MultiIndex, but to Boost.Hash. Could you please try to compile the following // just including this #include <boost/functional/hash/hash.hpp> both with Boost 1.33.1 and 1.34? Same behavior? Looking fwd to your feedback. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ********************************************************************** This communication and all information (including, but not limited to, market prices/levels and data) contained therein (the "Information") is for informational purposes only, is confidential, may be legally privileged and is the intellectual property of ICAP plc and its affiliates ("ICAP") or third parties. No confidentiality or privilege is waived or lost by any mistransmission. The Information is not, and should not be construed as, an offer, bid or solicitation in relation to any financial instrument or as an official confirmation of any transaction. The Information is not warranted, including, but not limited, as to completeness, timeliness or accuracy and is subject to change without notice. ICAP assumes no liability for use or misuse of the Information. All representations and warranties are expressly disclaimed. The Information does not necessarily reflect the views of ICAP. Access to the Information by anyone else other than the recipient is unauthorized and any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. **********************************************************************
One other detail that might help in the investigation: I use hashed indexes in other places with custom key extractors as opposed to const_mem_fun and I get no warnings. Thanks, Marius -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Joaquín Mª López Muñoz Sent: Thursday, July 12, 2007 10:43 AM To: boost@lists.boost.org Subject: Re: [boost] multi-index warnings Hello Marius, Marius Lazer ha escrito:
All,
I'm attempting to upgrade to boost_1_34_0 from boost_1_33_1 and I get the following warnings from a hashed_unique index. The same code compiles clean on boost_1_33_1 with gcc-4.1.1 and gcc-4.1.2.
Am I doing something wrong or this is a deficiency introduced in 1_34_0?
Thanks, Marius
Sample code:
boost::multi_index::hashed_unique < boost::multi_index::tag<server>, boost::multi_index::const_mem_fun < SessionLink, int, &SessionLink::serverFD > >
Generated warnings:
/home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:353: warning: passing 'bool' chooses 'int' over 'long unsigned int'[...]
I think this problem is not actually related to Boost.MultiIndex, but to Boost.Hash. Could you please try to compile the following // just including this #include <boost/functional/hash/hash.hpp> both with Boost 1.33.1 and 1.34? Same behavior? Looking fwd to your feedback. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ********************************************************************** This communication and all information (including, but not limited to, market prices/levels and data) contained therein (the "Information") is for informational purposes only, is confidential, may be legally privileged and is the intellectual property of ICAP plc and its affiliates ("ICAP") or third parties. No confidentiality or privilege is waived or lost by any mistransmission. The Information is not, and should not be construed as, an offer, bid or solicitation in relation to any financial instrument or as an official confirmation of any transaction. The Information is not warranted, including, but not limited, as to completeness, timeliness or accuracy and is subject to change without notice. ICAP assumes no liability for use or misuse of the Information. All representations and warranties are expressly disclaimed. The Information does not necessarily reflect the views of ICAP. Access to the Information by anyone else other than the recipient is unauthorized and any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. **********************************************************************
----- Mensaje original ----- De: Marius Lazer <Marius.Lazer@us.icap.com> Fecha: Jueves, Julio 12, 2007 4:53 pm Asunto: Re: [boost] multi-index warnings Para: boost@lists.boost.org
One other detail that might help in the investigation: I use hashed indexes in other places with custom key extractors as opposed to const_mem_fun and I get no warnings.
When using custom key extractors, was your key also an int as in the example you've provided? If not, could you try to custom extract an int to see if we can rule const_mem_fun out or not? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín, I changed one of my key extractors to return an int and no warnings. Other extractors return uchar_t, std::string, std::basic_string<uchar_t> and no warnings. Thanks, Marius -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of "JOAQUIN LOPEZ MU?Z" Sent: Thursday, July 12, 2007 10:59 AM To: boost@lists.boost.org Subject: Re: [boost] multi-index warnings ----- Mensaje original ----- De: Marius Lazer <Marius.Lazer@us.icap.com> Fecha: Jueves, Julio 12, 2007 4:53 pm Asunto: Re: [boost] multi-index warnings Para: boost@lists.boost.org
One other detail that might help in the investigation: I use hashed indexes in other places with custom key extractors as opposed to const_mem_fun and I get no warnings.
When using custom key extractors, was your key also an int as in the example you've provided? If not, could you try to custom extract an int to see if we can rule const_mem_fun out or not? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ********************************************************************** This communication and all information (including, but not limited to, market prices/levels and data) contained therein (the "Information") is for informational purposes only, is confidential, may be legally privileged and is the intellectual property of ICAP plc and its affiliates ("ICAP") or third parties. No confidentiality or privilege is waived or lost by any mistransmission. The Information is not, and should not be construed as, an offer, bid or solicitation in relation to any financial instrument or as an official confirmation of any transaction. The Information is not warranted, including, but not limited, as to completeness, timeliness or accuracy and is subject to change without notice. ICAP assumes no liability for use or misuse of the Information. All representations and warranties are expressly disclaimed. The Information does not necessarily reflect the views of ICAP. Access to the Information by anyone else other than the recipient is unauthorized and any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. **********************************************************************
----- Mensaje original ----- De: Marius Lazer <Marius.Lazer@us.icap.com> Fecha: Jueves, Julio 12, 2007 5:19 pm Asunto: Re: [boost] multi-index warnings Para: boost@lists.boost.org
Joaquín,
I changed one of my key extractors to return an int and no warnings. Other extractors return uchar_t, std::string, std::basic_string<uchar_t> and no warnings.
That's most weird: the differences in mem_fun.hpp between 1.34 and 1.33.1 do not look like being able to trigger the warning you report. Let's do the following: Could you provide me with a *complete* test program that reproduces the problem, i.e., such that it compiles warning-free with Boost 1.33.1 and warns with Boost 1.34, along with as much contextual info as possible (GCC version, command line options, etc.)? If I'm able to reproduce the problem locally I'll surely spot the reason also. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín, Here it is (as succinct as I could). All is running on Solaris 10. Thanks, Marius Script to compile with (mk.sh): echo "with 34 ---------------------------" /usr/local/gcc-4.1.1/bin/g++ -c m.C -Wsign-promo -I/home/mlazer/boost_1_34_0 echo "with 33 ---------------------------" /usr/local/gcc-4.1.1/bin/g++ -c m.C -Wsign-promo -I/home/mlazer/boost_1_33_1 echo "DONE ---------------------------" Source for m.C: #include <boost/multi_index_container.hpp> #include <boost/multi_index/mem_fun.hpp> #include <boost/multi_index/hashed_index.hpp> struct Int { int i() const { return 5; } }; struct A {}; typedef boost::multi_index_container < Int, boost::multi_index::indexed_by < boost::multi_index::hashed_unique < boost::multi_index::tag<A>, boost::multi_index::const_mem_fun < Int, int, &Int::i > >
IndexTest;
Output of the script: with 34 --------------------------- /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp: In member function 'size_t boost::hash<bool>::operator()(bool) const': /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:353: warning: passing 'bool' chooses 'int' over 'long unsigned int' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:353: warning: in call to 'size_t boost::hash_value(int)' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:353: warning: passing 'bool' chooses 'int' over 'long int' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:353: warning: in call to 'size_t boost::hash_value(int)' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:353: warning: passing 'bool' chooses 'int' over 'unsigned int' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:353: warning: in call to 'size_t boost::hash_value(int)' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp: In member function 'size_t boost::hash<unsigned char>::operator()(unsigned char) const': /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:356: warning: passing 'unsigned char' chooses 'int' over 'long unsigned int' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:356: warning: in call to 'size_t boost::hash_value(int)' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:356: warning: passing 'unsigned char' chooses 'int' over 'long int' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:356: warning: in call to 'size_t boost::hash_value(int)' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:356: warning: passing 'unsigned char' chooses 'int' over 'unsigned int' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:356: warning: in call to 'size_t boost::hash_value(int)' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp: In member function 'size_t boost::hash<short unsigned int>::operator()(short unsigned int) const': /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:361: warning: passing 'short unsigned int' chooses 'int' over 'long unsigned int' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:361: warning: in call to 'size_t boost::hash_value(int)' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:361: warning: passing 'short unsigned int' chooses 'int' over 'long int' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:361: warning: in call to 'size_t boost::hash_value(int)' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:361: warning: passing 'short unsigned int' chooses 'int' over 'unsigned int' /home/mlazer/boost_1_34_0/boost/functional/hash/hash.hpp:361: warning: in call to 'size_t boost::hash_value(int)' with 33 --------------------------- DONE --------------------------- -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of "JOAQUIN LOPEZ MU?Z" Sent: Thursday, July 12, 2007 11:31 AM To: boost@lists.boost.org Subject: Re: [boost] multi-index warnings ----- Mensaje original ----- De: Marius Lazer <Marius.Lazer@us.icap.com> Fecha: Jueves, Julio 12, 2007 5:19 pm Asunto: Re: [boost] multi-index warnings Para: boost@lists.boost.org
Joaquín,
I changed one of my key extractors to return an int and no warnings. Other extractors return uchar_t, std::string, std::basic_string<uchar_t> and no warnings.
That's most weird: the differences in mem_fun.hpp between 1.34 and 1.33.1 do not look like being able to trigger the warning you report. Let's do the following: Could you provide me with a *complete* test program that reproduces the problem, i.e., such that it compiles warning-free with Boost 1.33.1 and warns with Boost 1.34, along with as much contextual info as possible (GCC version, command line options, etc.)? If I'm able to reproduce the problem locally I'll surely spot the reason also. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ********************************************************************** This communication and all information (including, but not limited to, market prices/levels and data) contained therein (the "Information") is for informational purposes only, is confidential, may be legally privileged and is the intellectual property of ICAP plc and its affiliates ("ICAP") or third parties. No confidentiality or privilege is waived or lost by any mistransmission. The Information is not, and should not be construed as, an offer, bid or solicitation in relation to any financial instrument or as an official confirmation of any transaction. The Information is not warranted, including, but not limited, as to completeness, timeliness or accuracy and is subject to change without notice. ICAP assumes no liability for use or misuse of the Information. All representations and warranties are expressly disclaimed. The Information does not necessarily reflect the views of ICAP. Access to the Information by anyone else other than the recipient is unauthorized and any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. **********************************************************************
----- Mensaje original ----- De: Marius Lazer <Marius.Lazer@us.icap.com> Fecha: Jueves, Julio 12, 2007 7:22 pm Asunto: Re: [boost] multi-index warnings Para: boost@lists.boost.org
Joaquín,
Here it is (as succinct as I could). All is running on Solaris 10.
Thanks, Marius [...]
Hello Marius, OK, I've been able to reproduce the problem and after analyzing it I think that, unless I'm grossly mistaken, the problem lies inside Boost.Hash --which is not to say this lib has any error, it's just an effect of this overzealous -Wsign-promo switch. Let me explain my findings: I've been able to reproduce the warnings using exclusively Boost.Hash: ***code1*** // warns with Boost 1.34, clean compile with Boost 1.31 #include <boost/functional/hash/hash.hpp> int main(){} ***code1*** This warns with Boost 1.34 and does not warn wih Boost 1.33.1, under GCC 3.4.4 for Cygwin, always using the -Wsign-promo switch. This is in contradiction with some previous reports by you, my guess is that you forgot to include the switch (could you confirm this?) According to GCC docs, -Wsign-promo "warn[s] when overload resolution chooses a promotion from unsigned or enumeral type to a signed type over a conversion to an unsigned type of the same size.[...]" The relevant portion of Boost 1.34 Boost.Hash can be isolated and simplified to more easily show the issue: ***code2*** #include <cstddef> std::size_t hash_value(int){return 0;} std::size_t hash_value(long int){return 0;} template<typename> struct hash; template<> struct hash<bool> { std::size_t operator()(bool x)const{return hash_value(x);} }; int main(){} ***code2*** This emits the same kind of warnings you've seen: -Wsign-promo informs about the int overload having been chosen in preference to the long int overload (you can try yourself). As for why Boost.Hash 1.33.1 does not produce warnings, the reason is that in Boost 1.33.1 hash<T> is defined (roughly) as: template<typename> struct hash { std::size_t operator()(T x)const{return hash_value(t);} }; whereas in Boost 1.34 the class template hash is left undefined and a number of full specializations (like bool and other integral types) are explicitly defined, in the spirit of the code2 snippet. Matter of fact, the following will emit the warnings *both* with Boost 1.33.1 and 1.34: ***code3*** // warns with Boost 1.33.1 and 1.34 #include <boost/functional/hash/hash.hpp> int main() { boost::hash<bool> h; h(true); } ***code3*** Again, I'd be grateful if you can confirm all of this in your own environment. What to do about this? Of course if you can skip the -Wsign-promo switch no warnings will arise. If this is not an option, the author of Boost.Hash should have to be convinced to fix this, possibly by providing more overloads of hash_value (for bool and the rest of offending types) so as to avoid integral promotions altogether. Hope this helps, please come back if your experiments do not agree with this analysis. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín, Yes, I forgot the compiler flag when I compiled standalone boost/functional/hash/hash.hpp. Sorry for the confusion. I can confirm that your analysis is both complete and accurate. We use the highest level of warnings (in the spirit of terseness I omitted all the others like -Wall, etc.) and -Wsign-promo actually found problems so I'd be inclined to keep it. If someone in the Boost team can guarantee that these warnings are 100% benign (i.e. noise) I can live with them (or just turn -Wsign-promo off for the offending modules), otherwise I'd like to have them fixed. Thanks for your help, Marius -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of "JOAQUIN LOPEZ MU?Z" Sent: Thursday, July 12, 2007 5:29 PM To: boost@lists.boost.org Subject: [boost] [hash] GCC warnings with -Wsign-promo (was: multi-indexwarnings) ----- Mensaje original ----- De: Marius Lazer <Marius.Lazer@us.icap.com> Fecha: Jueves, Julio 12, 2007 7:22 pm Asunto: Re: [boost] multi-index warnings Para: boost@lists.boost.org
Joaquín,
Here it is (as succinct as I could). All is running on Solaris 10.
Thanks, Marius [...]
Hello Marius, OK, I've been able to reproduce the problem and after analyzing it I think that, unless I'm grossly mistaken, the problem lies inside Boost.Hash --which is not to say this lib has any error, it's just an effect of this overzealous -Wsign-promo switch. Let me explain my findings: I've been able to reproduce the warnings using exclusively Boost.Hash: ***code1*** // warns with Boost 1.34, clean compile with Boost 1.31 #include <boost/functional/hash/hash.hpp> int main(){} ***code1*** This warns with Boost 1.34 and does not warn wih Boost 1.33.1, under GCC 3.4.4 for Cygwin, always using the -Wsign-promo switch. This is in contradiction with some previous reports by you, my guess is that you forgot to include the switch (could you confirm this?) According to GCC docs, -Wsign-promo "warn[s] when overload resolution chooses a promotion from unsigned or enumeral type to a signed type over a conversion to an unsigned type of the same size.[...]" The relevant portion of Boost 1.34 Boost.Hash can be isolated and simplified to more easily show the issue: ***code2*** #include <cstddef> std::size_t hash_value(int){return 0;} std::size_t hash_value(long int){return 0;} template<typename> struct hash; template<> struct hash<bool> { std::size_t operator()(bool x)const{return hash_value(x);} }; int main(){} ***code2*** This emits the same kind of warnings you've seen: -Wsign-promo informs about the int overload having been chosen in preference to the long int overload (you can try yourself). As for why Boost.Hash 1.33.1 does not produce warnings, the reason is that in Boost 1.33.1 hash<T> is defined (roughly) as: template<typename> struct hash { std::size_t operator()(T x)const{return hash_value(t);} }; whereas in Boost 1.34 the class template hash is left undefined and a number of full specializations (like bool and other integral types) are explicitly defined, in the spirit of the code2 snippet. Matter of fact, the following will emit the warnings *both* with Boost 1.33.1 and 1.34: ***code3*** // warns with Boost 1.33.1 and 1.34 #include <boost/functional/hash/hash.hpp> int main() { boost::hash<bool> h; h(true); } ***code3*** Again, I'd be grateful if you can confirm all of this in your own environment. What to do about this? Of course if you can skip the -Wsign-promo switch no warnings will arise. If this is not an option, the author of Boost.Hash should have to be convinced to fix this, possibly by providing more overloads of hash_value (for bool and the rest of offending types) so as to avoid integral promotions altogether. Hope this helps, please come back if your experiments do not agree with this analysis. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ********************************************************************** This communication and all information (including, but not limited to, market prices/levels and data) contained therein (the "Information") is for informational purposes only, is confidential, may be legally privileged and is the intellectual property of ICAP plc and its affiliates ("ICAP") or third parties. No confidentiality or privilege is waived or lost by any mistransmission. The Information is not, and should not be construed as, an offer, bid or solicitation in relation to any financial instrument or as an official confirmation of any transaction. The Information is not warranted, including, but not limited, as to completeness, timeliness or accuracy and is subject to change without notice. ICAP assumes no liability for use or misuse of the Information. All representations and warranties are expressly disclaimed. The Information does not necessarily reflect the views of ICAP. Access to the Information by anyone else other than the recipient is unauthorized and any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. **********************************************************************
Marius Lazer ha escrito:
Joaquín,
Yes, I forgot the compiler flag when I compiled standalone boost/functional/hash/hash.hpp. Sorry for the confusion.
I can confirm that your analysis is both complete and accurate. We use the highest level of warnings (in the spirit of terseness I omitted all the others like -Wall, etc.) and -Wsign-promo actually found problems so I'd be inclined to keep it.
If someone in the Boost team can guarantee that these warnings are 100% benign (i.e. noise) I can live with them (or just turn -Wsign-promo off for the offending modules), otherwise I'd like to have them fixed.
I think they're harmless, but the author of Boost.Hash has the final say. I've created a ticket for the issue at: http://svn.boost.org/trac/boost/ticket/1095 Best regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (6)
-
"JOAQUIN LOPEZ MU?Z" -
David Abrahams -
Joaquín Mª López Muñoz
-
Marius Lazer -
Marshall Clow -
Martin Bonner