August 2006 - Boost - lists.boost.org

Re: [boost] Boost.Bimap - Informal Review Request
by JOAQUIN LOPEZ MU?Z 10 Aug '06

10 Aug '06

----- Mensaje original ----- De: Matias Capeletto <matias.capeletto(a)gmail.com> Fecha: Miércoles, Agosto 9, 2006 7:32 am Asunto: [boost] Boost.Bimap - Informal Review Request > Hello, > > Boost.Bimap, my SoC project is ready to confront the list. [...] > * Do you like the usage interface? Very much. I like the fact that in its most basic usage typedef bimap<A,B> bm_type; the syntax is as simple as it can get, yet the library allows for much more elaborated instantiations. > * In relation with Boost.MultiIndex, Do you think that it is > worth to have a bidirectional map library in Boost, that trades > generality for a better specialized user interface? > (Because this library was encouraged by the boost mentors the > answer will surely be yes, but it is a nice discussion to have) I think the barrier entry for Boost.Bimap is much lower that for Boost.MultiIndex, which is one of the main goals of the project. I also like the fact that Boost.Bimap is introduced without references to B.MI: many potential users of Boost.Bimap need not know anything about B.MI, so B.B can be regarded as a solution on its own in those cases rather than a transition stage to B.MI. > * Do you like the extended mapping framework? > Do you think it is intuitive for someone with a stl background? I think the framework is sound. I've got some doubts as to the understability of the part where the set of relation type is specified, this being perhaps the most unconventional aspect of the framework. > * What do you think of the design of operator[]? > Is there a better way to be coherent with the stl that does not > imply throwing exceptions? I think the current design of operator[] is almost dictated by the peculiarities of B.B: the semantics is as close as possible to that of std::map, but not closer. > * What is your evaluation of the implementation? > I am very interested in your reaction to the zero-overhead achieved > by the almost-standard mutant_relation class, and the standard > compliant label that this library acquires by including the > standard_relation class. Standardwise this is the most controversial part of the design. My personal opinion is that it's a deviation worth commiting to in order to achieve zero overhead. Others may dissent, though. Just to bring this issue forward to the list, let me state the problem in simple terms. Currently, Boost.Bimap is relying on the following three classes being layout-compatible for the same choice of arguments X and Y (actual names do not match those used inside B.B): template<typename X,typename Y> struct relation { X left; y right; }; template<typename X,typename Y> struct pair_by_left { X first; Y second; }; template<typename X,typename Y> struct pair_by_right { X second; Y first; }; Assuming layout compatibility allows us to "see" the elements of a bimap as pair_by_left's in the left view and pair_by_right's in the right view, thus matching the (first=key,second=data) syntax of a regular std::map. Needless to say all C++ compilers we know of do in fact provide such a layout compatibility. If we adhered strictly to the C++ standard, this kind of mirroring could only be achieved with non-zero overhead --for instance, holding references to left and right properly named "first" and "second" accordingly to the view. If I'm not wrong B.B assumes layout compatibility by default but can decay to a standard compliant solution for those (as of yet unknown) compilers where it could be needed. What do others think about this issue? > A big part of the library implementation is ContainerAdaptor. > Do you deem Boost.ContainerAdaptor worth eventually proposing to > Boost? Maybe the following can be tried to assess the power of this component: what about trying to implement Boost.PointerContainer using ContainerAdaptor, if only as a proof of concept? Would this result in a significant reduction in code size? > Looking forward to getting your feedback, I've got a feature request about list_of and vector_of. When writing for instance: bimap<set_of<X>,list_of<Y> > we know (unlike in Boost.MultiIndex) that the Y part does not belong to any index key and thus can be freely mutated. Could it be possible that, in those cases, the associated relation class held a mutable Y allowing for direct manipulation of that member? > Matias Capeletto Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 5

[regrex] Failure on newly added test regex_regress_threaded on Tru64/GCC
by Markus Schöpflin 10 Aug '06

10 Aug '06

For reference, see http://tinyurl.com/rm4dr and http://tinyurl.com/k53v2. Interestingly enough, the test passes on Tru64/CXX. Compiled with gcc 4.0.3 the test aborts with 'terminate called recursively', compiled with 3.4.4 it throws a SIGABRT. Is there anything I can do to help in debugging? Markus

2 9

[Boost-bugs] [ boost-Patches-1538176 ] VARNAMES bjam rule doesn't work for global module
by SourceForge.net 10 Aug '06

10 Aug '06

Patches item #1538176, was opened at 2006-08-10 16:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1538176&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Yakov Markovitch (markovitch) Assigned to: Nobody/Anonymous (nobody) Summary: VARNAMES bjam rule doesn't work for global module Initial Comment: VARNAMES bjam rule always returns empty list for the global module. This is due to the fact that builtin_varnames relies upon module_t::variables struct member being not NULL if there are variables in the module, which is wrong for the "currently running module" (i.e. frame->module->variables is _always_ NULL). This is due to the way enter_module() and var_hash_swap() work. Since builtin_varnames() always runs in the global module context, global module's 'variables' member is always NULL when builtin_varnames() is called. The proposed patch fixes this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1538176&group_… ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Boost regression notification (2006-08-10 [RC_1_34_0])
by Douglas Gregor 10 Aug '06

10 Aug '06

Boost Regression test failures Report time: 2006-08-10T06:50:05Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… 240 failures in 24 libraries algorithm/string (1) concept_check (1) filesystem (4) graph (5) io (1) iostreams (10) mpl (6) multi_array (1) numeric/conversion (4) numeric/interval (1) numeric/ublas (7) parameter (20) program_options (9) python (58) random (1) rational (4) regex (1) serialization (26) signals (16) spirit (1) test (2) tr1 (51) typeof (9) utility (1) |algorithm/string| regex: borland-5_6_4 |concept_check| class_concept_check_test: vc-7_1-stlport |filesystem| mbcopy: sun-5.8 operations_test: vc-7_1-stlport operations_test_dll: vc-7_1-stlport wide_test: sun-5.8 |graph| adjacency_matrix_test: vc-7_0 csr_graph_test: sun-5.8 graphviz_test: msvc-8.0 msvc-8.0 vc-7_1-stlport |io| ios_state_unit_test: gcc-4.1.0_linux_x86_64 |iostreams| bzip2_test: msvc-7.1 msvc-8.0 compose_test: borland-5_6_4 example_test: vc-6_5-stlport filtering_stream_test: vc-7_1-stlport finite_state_filter_test: cw-9.4 gzip_test: msvc-7.1 msvc-8.0 zlib_test: msvc-7.1 msvc-8.0 |mpl| multiset: gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc gcc-4_0_3_tru64 vector_c: sun-5.8 |multi_array| iterators: msvc-8.0 |numeric/conversion| converter_test: borland-5_8_2 traits_test: borland-5_8_2 udt_example_0: borland-5_8_2 udt_support_test: borland-5_8_2 |numeric/interval| test_float: vc-7_1-stlport |numeric/ublas| concepts: vc-7_1-stlport vc-7_1-stlport test1: vc-7_1-stlport test2: vc-7_1-stlport test4: vc-7_1-stlport test5: vc-7_1-stlport vc-7_1-stlport |parameter| duplicates: borland-5_6_4 borland-5_8_2 maybe: vc-6_5 vc-6_5-stlport vc-7_0 preprocessor: borland-5_6_4 borland-5_8_2 sun-5.8 vc-6_5 vc-6_5-stlport python-parameter-test: vc-6_5 vc-6_5-stlport vc-7_0 sfinae: borland-5_8_2 vc-6_5-stlport singular: borland-5_6_4 borland-5_8_2 unnamed_fail: vc-6_5 vc-6_5-stlport vc-7_0 |program_options| cmdline_test_dll: cw-9.4 options_description_test_dll: cw-9.4 parsers_test_dll: cw-9.4 positional_options_test_dll: cw-9.4 unicode_test_dll: borland-5_8_2 cw-9.4 variable_map_test_dll: borland-5_8_2 cw-9.4 winmain_dll: cw-9.4 |python| andreas_beyer: sun-5.8 args: sun-5.8 auto_ptr: sun-5.8 back_reference: sun-5.8 ben_scott1: sun-5.8 bienstman1: sun-5.8 bienstman2: sun-5.8 bienstman3: sun-5.8 callbacks: sun-5.8 data_members: sun-5.8 defaults: sun-5.8 docstring: sun-5.8 enum: sun-5.8 exec: cw-9.4 darwin-4.0.1 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp sun-5.8 extract: sun-5.8 implicit: sun-5.8 indirect_traits_test: sun-5.8 injected: sun-5.8 iterator: sun-5.8 keywords: sun-5.8 list: sun-5.8 long: sun-5.8 multi_arg_constructor: sun-5.8 nested: sun-5.8 numpy: sun-5.8 opaque: sun-5.8 operators: sun-5.8 pearu1: sun-5.8 pickle1: sun-5.8 pickle2: sun-5.8 pickle3: sun-5.8 pickle4: sun-5.8 pointer_vector: sun-5.8 polymorphism: sun-5.8 polymorphism2: sun-5.8 polymorphism2_auto_ptr: sun-5.8 properties: sun-5.8 raw_ctor: sun-5.8 return_arg: sun-5.8 select_from_python_test: darwin-4.0.1 shared_ptr: sun-5.8 slice: sun-5.8 staticmethod: sun-5.8 stl_iterator: sun-5.8 string_literal: sun-5.8 test_pointer_adoption: sun-5.8 try: sun-5.8 vector_indexing_suite: sun-5.8 virtual_functions: sun-5.8 voidptr: sun-5.8 wrapper_held_type: sun-5.8 |random| random_test: intel-linux-9.0 |rational| rational_test: borland-5_6_4 vc-6_5 vc-6_5-stlport vc-7_0 |regex| regex_regress_threaded: gcc-4_0_3_tru64 |serialization| test_class_info_load_text_warchive: vc-6_5 test_non_default_ctor2_text_archive: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_archive_dll: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_warchive: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_warchive_dll: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_primitive_text_warchive: msvc-8.0 test_registered_xml_archive_dll: msvc-8.0 test_reset_object_address: vc-7_0 test_reset_object_address_dll: vc-7_0 test_simple_class_binary_archive_dll: vc-6_5 test_simple_class_text_archive_dll: vc-6_5 test_simple_class_text_warchive_dll: vc-6_5 test_simple_class_xml_archive_dll: vc-6_5 test_simple_class_xml_warchive_dll: vc-6_5 test_variant_xml_archive: borland-5_8_2 test_variant_xml_archive_dll: borland-5_8_2 test_variant_xml_warchive: borland-5_8_2 test_variant_xml_warchive_dll: borland-5_8_2 |signals| dead_slot_test: gcc-3.3.6 gcc-3.3.6_linux qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp trackable_test: gcc-3.3.6 gcc-3.3.6_linux qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp |spirit| mix_and_match_trees: sun-5.8 |test| parameterized_test_test: vc-6_5 vc-6_5-stlport |tr1| run_random: sun-5.8 std_run_complex_overloads: sun-5.8 std_run_random: sun-5.8 std_test_bind: sun-5.8 std_test_complex: sun-5.8 std_test_function: sun-5.8 std_test_hash: sun-5.8 std_test_mem_fn: sun-5.8 std_test_random: sun-5.8 std_test_reference_wrapper: sun-5.8 std_test_reference_wrapper_tricky: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-4.0.3_linux gcc-4.1.0_linux_x86_64 intel-linux-9.0 mingw-3_4_2 msvc-7.1 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp vc-7_1-stlport std_test_result_of: sun-5.8 std_test_shared_ptr: sun-5.8 std_test_tuple: sun-5.8 std_test_tuple_tricky: sun-5.8 std_test_type_traits: sun-5.8 test_boost: vc-7_1-stlport test_hash: vc-7_1-stlport test_random: sun-5.8 vc-7_1-stlport test_reference_wrapper_tricky: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-4.0.3_linux gcc-4.1.0_linux_x86_64 intel-linux-9.0 mingw-3_4_2 msvc-7.1 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp test_regex: vc-7_1-stlport test_type_traits: sun-5.8 tr1_tky_function_type_test: sun-5.8 |typeof| function_binding_emulation: sun-5.8 function_binding_native: vc-6_5 vc-6_5-stlport vc-7_0 nested_typedef_emulation: cw-9.4 odr_no_uns: vc-6_5 vc-6_5-stlport vc-7_0 template_tpl_emulation: sun-5.8 |utility| operators_test: gcc-3.4.5_linux_x86_64

1 0

[program_options] bugfix partially correct
by Ovanes Markarian 10 Aug '06

10 Aug '06

An assertion bug with VC 8.0 is partially correct at least in the version I found in CVS. options_description.cpp revision=1.16.2.1 This calculation does not assume the indent in the line used. The line_length added produces longer line sequence as would fit in the line, so a line wrap occurs. The output looks somehow ugly: -v [--version] test line dkakal alalalala a sdk dkdkdkd instead of: -v [--version] test line dkakal alalalala a sdk dkdkdkd Current calc: LineNo. 393 // Take care to never increment the iterator past 394 // the end, since MSVC 8.0 (brokenly), assumes that 395 // doing that, even if no access happens, is a bug. 396 unsigned remaining = distance(line_begin, par_end); 397 string::const_iterator line_end = line_begin + 398 ((remaining < line_length) ? remaining : line_length); My proposal would be adding before the while loop (line 377): size_t offset = line_length - indent; LineNo. 393 // Take care to never increment the iterator past 394 // the end, since MSVC 8.0 (brokenly), assumes that 395 // doing that, even if no access happens, is a bug. 396 unsigned remaining = distance(line_begin, par_end); 397 string::const_iterator line_end = line_begin + 398 ((remaining < offset) ? remaining : offset); With Kind Regards, Ovanes Markarian With Kind Regards, Ovanes

1 0

Re: [boost] Boost.Bimap - Informal Review Request
by JOAQUIN LOPEZ MU?Z 10 Aug '06

10 Aug '06

----- Mensaje original ----- De: John Maddock <john(a)johnmaddock.co.uk> Fecha: Jueves, Agosto 10, 2006 11:13 am Asunto: Re: [boost] Boost.Bimap - Informal Review Request [...] > However, looking at the reference docs for the list view, I'm > confused, for > example what is: > > O(I(n)) ? > > Looked a lot like a mis-spelled O(log(n)) when I looked at the html. > > What is O(D(n)) , O(R(n)) , O(M(n)) ? > > None of these have immediately obvious meanings to me. This notation is inherited from Boost.MultiIndex, so let me explain it briefly: the problem with documenting complexities for B.MI is that the overall O() estimate for a given operation depends on the number and type of indices the container is composed of: for instance, inserting into a container with a hashed index and a list-like index is O(1), but if we add an oredred index (which is based on a rb-tree) then the overall insertion complexity raises to O(log n). To document all this with precision, I analyze (complexity-wise) every operation in terms of six "primitives": * copying, * insertion, * hinted insertion, * deletion, * replacement, * modification, Each index, viewed in isolation, is characterized by a so-called complexity signature composed of functions c(n),i(n),h(n),d(n), r(m) and m(n). We use uppercase to refer to the sum of all individual contributions, for instance C(n)=c1(n)+...+cN(n) where ci is the copying complexity of the i-th index. Then, I can say that insertion into a multi-index container is O(I(n)): the exact expression of I(n) can be then calculated by summing the correspoding i(n) of each index, which are given in the reference. This is all explained in http://boost- consulting.com/boost/libs/multi_index/doc/reference/indices.html#comple xity_signature and also replicated (in the context of Boost.Bimap) in the reference of this lib. Is this clear now? > Thanks, John. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Sun-5.8 failures
by Gennaro Prota 10 Aug '06

10 Aug '06

Hi guys, among the various Sun CC failures that permeate our regression tests there's one which seems quite straightforward to fix (so it probably isn't :-)): the compiler claims ambiguity between test_tools::tt_detail::print_helper<char[1]> (const char(&)[1]) test_tools::tt_detail::print_helper<const char, 1>(const char(&)[1]) in "boost/test/test_tools.hpp". AFAICT, that's correct and we should fix the code between lines 377 and 389. -- [ Gennaro Prota, C++ developer for hire ]

6 22

[Boost-bugs] [ boost-Bugs-1537844 ] format zero length string msvc-8
by SourceForge.net 10 Aug '06

10 Aug '06

Bugs item #1537844, was opened at 2006-08-10 16:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1537844&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: John (drjohnfoster) Assigned to: Nobody/Anonymous (nobody) Summary: format zero length string msvc-8 Initial Comment: Since Microsoft have deprecated most of the standard library, their debug libraries also check for unsafe pointers. The following code gives an assertion: (boost::format("%s") % "").str(); In debug mode, basic_string<char>::append(0, 0) called from mk_str in feed_args.hpp is tested by the macro _DEBUG_POINTER, and decides the pointer is invalid even though the count is 0. I imagine this toxic behaviour is repeated in a number of places. It would be nice if the boost library could work around this problem at a low level. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1537844&group_… ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Borland Turbo* is back?
by Rene Rivera 10 Aug '06

10 Aug '06

In case people haven't seen the announcements... http://turboexplorer.com/ There's a claim of ANSI and Boost compatibility in the Turbo C++ product. Does this mean that this is the new compiler series? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

5 4

[program_options] bug in split_winmain
by Philipp Henkel 10 Aug '06

10 Aug '06

Hi, I discovered a bug in split_winmain. If the wstring version of the function is used the result vector is always empty: Original code in libs/program_options/src/winmain.cpp: #ifndef BOOST_NO_STD_WSTRING BOOST_PROGRAM_OPTIONS_DECL std::vector<std::wstring> split_winmain(const std::wstring& cmdline) { vector<wstring> result; vector<string> aux = split_winmain(to_internal(cmdline)); for (unsigned i = 0, e = result.size(); i < e; ++i) result.push_back(from_utf8(aux[i])); return result; } #endif The expression result.size() in the for-loop has to be replaced with aux.size(). At least boost lib 1.33.0 and 1.33.1 contain this bug but I think nobody used the function for years... Best regards, Philipp

2 1