- Boost - lists.boost.org

Boost regression notification (2006-07-16 [RC_1_34_0])
by Douglas Gregor 16 Jul '06

16 Jul '06

Boost Regression test failures Report time: 2006-07-16T09:04:39Z 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… 400 failures in 30 libraries algorithm/string (1) concept_check (1) conversion (1) filesystem (5) graph (6) integer (3) io (1) iostreams (61) iterator (1) lambda (2) mpl (20) numeric/conversion (4) numeric/interval (2) numeric/ublas (7) optional (2) parameter (33) pool (3) program_options (19) python (92) random (1) rational (5) serialization (42) signals (16) spirit (12) test (8) tr1 (39) typeof (9) utility (2) utility/enable_if (1) wave (1) |algorithm/string| regex: borland-5_6_4 |concept_check| class_concept_check_test: vc-7_1-stlport |conversion| lexical_cast_test: sun-5.8 |filesystem| fstream_test: sun-5.8 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 bidir_remove_edge: vc-7_0 csr_graph_test: sun-5.8 graphviz_test: msvc-8.0 msvc-8.0 vc-7_1-stlport |integer| integer_traits_test: qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp |io| ios_state_unit_test: gcc-4.1.0_linux_x86_64 |iostreams| array_test: vc-6_5 auto_close_test: sun-5.8 vc-6_5 buffer_size_test: sun-5.8 vc-6_5 bzip2_test: msvc-7.1 msvc-8.0 sun-5.8 code_converter_test: sun-5.8 vc-6_5 component_access_test: sun-5.8 vc-6_5 compose_test: borland-5_6_4 sun-5.8 vc-6_5 copy_test: vc-6_5 counter_test: sun-5.8 vc-6_5 direct_adapter_test: vc-6_5 example_test: vc-6_5 vc-6_5-stlport file_descriptor_test: vc-6_5 file_test: vc-6_5 filtering_stream_test: sun-5.8 vc-6_5 vc-7_1-stlport finite_state_filter_test: cw-9.4 sun-5.8 flush_test: sun-5.8 vc-6_5 gzip_test: msvc-7.1 msvc-8.0 sun-5.8 invert_test: vc-6_5 line_filter_test: sun-5.8 vc-6_5 mapped_file_test: vc-6_5 newline_test: sun-5.8 vc-6_5 null_test: vc-6_5 pipeline_test: sun-5.8 vc-6_5 positioning_test: vc-6_5 regex_filter_test: sun-5.8 vc-6_5 restrict_test: sun-5.8 vc-6_5 seekable_file_test: sun-5.8 vc-6_5 seekable_filter_test: sun-5.8 vc-6_5 stdio_filter_test: sun-5.8 vc-6_5 symmetric_filter_test: sun-5.8 vc-6_5 tee_test: sun-5.8 vc-6_5 wide_stream_test: sun-5.8 vc-6_5 zlib_test: msvc-7.1 msvc-8.0 |iterator| is_lvalue_iterator: sun-5.8 |lambda| extending_rt_traits: sun-5.8 operator_tests_simple: sun-5.8 |mpl| apply: gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc sun-5.8 count: sun-5.8 count_if: sun-5.8 equal: sun-5.8 erase: sun-5.8 find: sun-5.8 insert: sun-5.8 insert_range: sun-5.8 lambda_args: sun-5.8 multiset: gcc-3.4.5_linux_x86_64 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 partition: sun-5.8 stable_partition: sun-5.8 vector_c: sun-5.8 |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| det: sun-5.8 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 |optional| optional_test: sun-5.8 optional_test_ref: sun-5.8 |parameter| basics: borland-5_6_4 borland-5_8_2 sun-5.8 duplicates: borland-5_6_4 borland-5_8_2 earwicker: borland-5_6_4 borland-5_8_2 macros: borland-5_6_4 borland-5_8_2 sun-5.8 maybe: vc-6_5 vc-6_5-stlport vc-7_0 mpl: borland-5_6_4 borland-5_8_2 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_6_4 borland-5_8_2 vc-6_5-stlport singular: borland-5_6_4 borland-5_8_2 unnamed: borland-5_6_4 borland-5_8_2 unnamed_fail: vc-6_5 vc-6_5-stlport vc-7_0 |pool| test_pool_alloc: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp |program_options| cmdline_test: sun-5.8 cmdline_test_dll: cw-9.4 sun-5.8 options_description_test: sun-5.8 options_description_test_dll: cw-9.4 sun-5.8 parsers_test: sun-5.8 parsers_test_dll: cw-9.4 sun-5.8 positional_options_test: sun-5.8 positional_options_test_dll: cw-9.4 sun-5.8 unicode_test_dll: borland-5_8_2 cw-9.4 variable_map_test: sun-5.8 variable_map_test_dll: borland-5_8_2 cw-9.4 sun-5.8 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 bases: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux sun-5.8 ben_scott1: sun-5.8 bienstman1: sun-5.8 bienstman2: sun-5.8 bienstman3: sun-5.8 borrowed: sun-5.8 callbacks: sun-5.8 const_argument: sun-5.8 crossmod_exception: sun-5.8 data_members: sun-5.8 defaults: sun-5.8 dict: sun-5.8 docstring: sun-5.8 enum: sun-5.8 exception_translator: sun-5.8 exec: cw-9.4 darwin-4.0.1 gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux 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 minimal: sun-5.8 multi_arg_constructor: sun-5.8 nested: sun-5.8 numpy: sun-5.8 object: sun-5.8 object_manager: 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 pointee: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux sun-5.8 pointer_type_id_test: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux 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_arg_to_python_test: sun-5.8 select_from_python_test: darwin-4.0.1 qcc-3.3.5_cpp qcc-3.3.5_gpp sun-5.8 select_holder: sun-5.8 shared_ptr: sun-5.8 slice: sun-5.8 staticmethod: sun-5.8 stl_iterator: sun-5.8 str: sun-5.8 string_literal: sun-5.8 test_pointer_adoption: sun-5.8 try: sun-5.8 tuple: sun-5.8 upcast: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux 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 sun-5.8 vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_class_info_load_text_warchive: vc-6_5 test_codecvt_null: qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp test_demo_fast_archive: sun-5.8 test_demo_fast_archive_dll: sun-5.8 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_reset_object_address: vc-7_0 test_reset_object_address_dll: vc-7_0 test_shared_ptr_132_binary_archive: sun-5.8 test_shared_ptr_132_binary_archive_dll: sun-5.8 test_shared_ptr_132_text_archive: sun-5.8 test_shared_ptr_132_text_archive_dll: sun-5.8 test_shared_ptr_132_text_warchive: sun-5.8 test_shared_ptr_132_text_warchive_dll: sun-5.8 test_shared_ptr_132_xml_archive: sun-5.8 test_shared_ptr_132_xml_archive_dll: sun-5.8 test_shared_ptr_132_xml_warchive: sun-5.8 test_shared_ptr_132_xml_warchive_dll: sun-5.8 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_utf8_codecvt: qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp 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| bug_fixes: sun-5.8 bug_fixes_debug: sun-5.8 char_strings_test: sun-5.8 char_strings_test_debug: sun-5.8 epsilon_tests: sun-5.8 epsilon_tests_debug: sun-5.8 file_iterator_tests: sun-5.8 file_iterator_tests_debug: sun-5.8 if_p_as_parser_tests: sun-5.8 mix_and_match_trees: sun-5.8 scanner_value_type_tests: intel-linux-9.0 while_p_as_parser_tests: sun-5.8 |test| basic_cstring_test: sun-5.8 boost_check_equal_str: sun-5.8 foreach_test: sun-5.8 ifstream_line_iterator_test: sun-5.8 output_test_stream_test: sun-5.8 parameterized_test_test: vc-6_5 vc-6_5-stlport token_iterator_test: sun-5.8 |tr1| run_random: sun-5.8 std_run_complex_overloads: sun-5.8 std_run_random: sun-5.8 std_test_bind: darwin-4.0.1 sun-5.8 std_test_complex: sun-5.8 std_test_function: sun-5.8 std_test_hash: qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp 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_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_bind: darwin-4.0.1 test_boost: vc-7_1-stlport test_hash: qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp vc-7_1-stlport test_random: sun-5.8 vc-7_1-stlport test_regex: vc-7_1-stlport test_type_traits: sun-5.8 tr1_extent_test: sun-5.8 tr1_is_abstract_test: sun-5.8 tr1_is_empty_test: sun-5.8 tr1_is_function_test: sun-5.8 tr1_is_member_func_test: sun-5.8 tr1_is_member_obj_test: sun-5.8 tr1_is_object_test: sun-5.8 tr1_is_reference_test: sun-5.8 tr1_rank_test: sun-5.8 tr1_tricky_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| addressof_test: sun-5.8 operators_test: gcc-3.4.5_linux_x86_64 |utility/enable_if| lazy: sun-5.8 |wave| test_re2c_lexer: sun-5.8

1 0

Re: [boost] [regex]Including regex.hpp causes error in anskeletonwin32 project of VS.net2003 with MFC support
by Wang Weiwei 16 Jul '06

16 Jul '06

>On Sat, 15 Jul 2006 18:12:57 +0100, "John Maddock" ><john(a)johnmaddock.co.uk> wrote: > >>Ah, that might do it, it's not a placement new, it's a call to ::operator >>new. There's no way to suppress macro expansion on a non-function macro >>either is there? > >AFAIK, no, but nobody can be sure of any pp statement without talking >to Paul Mensonides, first :) You could detect whether "new" remains >the same after an attempted expansion or not, though. > >Quite depressing, I know. As you'll see, this causes problems to >themselves too: > > <http://support.microsoft.com/kb/317799/EN-US/> > >-- >[ Gennaro Prota, C++ developer for hire ] >[ resume: available on request ] Yes, the MS nasty macro definition is the source of problem. The workaround is commenting out the macro as follows: //#ifdef _DEBUG //#define new DEBUG_NEW //#endif As indicated in the MS web page, the drawbak of this solution is, as quoted from the page: "NOTE: This method has the disadvantage of not using features in MFC that help you track memory allocations and leaks." Thanks Max

2 1

Re: [boost] [regex]Including regex.hpp causes error in anskeletonwin32 project of VS.net2003 with MFC support
by Wang Weiwei 16 Jul '06

16 Jul '06

>Wang Weiwei wrote: >>> Hello, >>> >>> I have done a test, on WinXP + VS.net 2003, with regex lib as >>> follows , >>> >>> A created a new 'Win32 Console Project', I selected MFC and >>> pre-compiled header support. Leave other settings default. >>> >>> Then I created a skeleton project that can compile. Then I added >>> >>> #include <boost/regex.hpp> >>> >>> in the main cpp file. When I then compiled the program in debug >>> mode, I got a "error C2665" at regex_raw_buffer.hpp(177) - “operator >>> new. >>> When I compiled it in release mode, it's Ok. >>> >>> Anybody know how about this phenomenom? > >Weird, no. > >Regex is used and tested with VC8 a lot, although I admit I'm not in a >position to test it with MFC. It's not as simple as adding: > >#include <new> > >to the top of that file is it? > >John. > Hello John, Thank you for your hint. But unfortunately the error persists after I adding #include <new> before #include <boost/regex.hpp> Max

1 0

Dispatcher Library Initial Implementation
by Dean Michael Berris 15 Jul '06

15 Jul '06

Hi Everyone, Uploaded to the vault [0] is the implementation of the dispatcher library. If there is enough interest, I would like to propose this library for inclusion into the Boost C++ Library. The documentation is yet unfinished, though I am not very sure about the contents of the documentation. However, I have put enough documentation with regards to how the library is designed, and used. A synopsis on how it can be used can be summed up in the following example code: [start code] #include <boost/dispatch.hpp> using boost::dispatch; //... dispatcher<int()> d; d[0] = int_function_1; d[1] = int_function_2; d[0]() // calls `int_function_1' d[1]() // calls `inf_function_2' d.unset(1); try { d[1]() // throws an unregistered_handler exception } catch (unregistered_handler & e) { // .. do nothing }; dispatcher<int()>::invoke_ d; d[1] = int_function_2; d << 0 << 1 ; // calls d[0] and d[1] in specified order. [end code] It also supports multiple argument callback registration (ala Signals): [start code] dispatcher<int (double, int, std::string)> d; d[0] = function_returns_int_and_takes_double_int_and_string; [end code] It also allows for parameterized index type definition: [start code] dispatcher<int(int), std::string> d; d["zero"] = function_returns_int_and_takes_int; [end code] The included documentation (doc/html) contains more information on the uses of the library, while the unit test (test/dispatch_test.cpp) can be referred to regarding the actual details on the usage. The project is currently hosted in sourceforge [1] and has been tested/built against RC_1_34_0 using MSVC 8.0 -- this is configured to be built only with BBv2. Have a great day everyone! Your comments and insights will be most appreciated. References: [0] Dispatcher Initial Implementation http://tinyurl.com/q9oux [1] Sourceforge.net project page http://tinyurl.com/mo2ds -- Dean Michael C. Berris C/C++ Software Architect Orange and Bronze Software Labs http://3w-agility.blogspot.com/ http://cplusplus-soup.blogspot.com/ Mobile: +639287291459 Email: dean [at] orangeandbronze [dot] com

4 8

[regex]Including regex.hpp causes error in an skeleton win32 project of VS.net2003 with MFC support
by Wang Weiwei 15 Jul '06

15 Jul '06

Hello, I have done a test, on WinXP + VS.net 2003, with regex lib as follows , A created a new 'Win32 Console Project', I selected MFC and pre-compiled header support. Leave other settings default. Then I created a skeleton project that can compile. Then I added #include <boost/regex.hpp> in the main cpp file. When I then compiled the program in debug mode, I got a "error C2665" at regex_raw_buffer.hpp(177) - “operator new. When I compiled it in release mode, it's Ok. Anybody know how about this phenomenom? Thanks Max

6 6

[regex]How to get Content-Type's parameter pairs using boost.regex?
by Mockey Chen 15 Jul '06

15 Jul '06

Hi, experts, I using boost.regex parse the content-type header's value in MIME. A typical content-type's BNF like following: Content-Type = "Content-Type:" SP media-type media-type = type "/" subtype *( ";" gen-param ) type = token subtype = token gen-param = pname [ "=" pval ] pname = token pval = token / quoted-string An example content-type as following: multipart/mixed; boundary="theboundary" ;id=33 There may be zero or one more parameters in content-type. My parse code as following: #include <boost/regex.hpp> #include <iostream> #include <string> #define COUT(x) std::cout << x << std::endl #define VAR(v) std::cout << #v << ": " << v << std::endl #define TOKEN "[a-zA-Z0-9]+" #define TYPE "(" TOKEN ")" #define SUBTYPE "(" TOKEN ")" #define PNAME "(" TOKEN ")" #define PVALUE "(" TOKEN ")" #define PARAM "(;" PNAME "=" PVALUE ")" #define CONTENT_TYPE_EXPRESS TYPE "/" SUBTYPE PARAM "*" int main() { std::string ct("multipart/mixed;boundary=theboundary;id=33"); COUT(CONTENT_TYPE_EXPRESS); boost::regex regex_content_type(CONTENT_TYPE_EXPRESS); boost::smatch result; if (boost::regex_match(ct, result, regex_content_type)) { VAR(result.size()); for (unsigned int i=0; i<result.size(); ++i) { if (result[i].matched) { COUT("result[" << i << "] = " << result[i]); } } } else { COUT("match failed."); } return 0; } /** output: ([a-zA-Z0-9]+)/([a-zA-Z0-9]+)(;([a-zA-Z0-9]+)=([a-zA-Z0-9]+))* result.size(): 6 result[0] = multipart/mixed;boundary=theboundary;id=33 result[1] = multipart result[2] = mixed result[3] = ;id=33 result[4] = id result[5] = 33 */ I want to get the parameter "boundary" and its value. Any way to do it? Thanks in advance. -- Regards. Mockey Chen

2 1

Re: [boost] Please don't define a fake"operator<"just for ordered containers
by Sean Parent 15 Jul '06

15 Jul '06

> I think I have a basic understanding of your logic, but let's think > about > practicality for a moment. I'm not saying logical and philosophical > reasons > are not appropriate for this discussion, but let's try and not > think about > them for a second. I haven't heard mathematics described as "philosophical reasons" but okay. > The ordering defined by the operator< overload for shared_ptr has the > following important property: it is independent of shared_ptr's > template > parameter. You can order shared_ptr<void> objects, if you like. Or, a > shared_ptr<void> and a shared_ptr<int>. I understand, total ordering is important and useful. The question is, what are the semantics of operator < ? If we fail to establish such principals then generic programming is a futile exercise. A generic algorithm is a theorem - it's correctness depends on a collection of semantic requirements (Concepts), these are the axioms for the theorem. Does it matter if share_ptr provides an operator <? No, but it isn't useful for generic code unless such an operation is tied to semantics which are generally accepted. T* does not provide such an operator < and I see no semantic difference between the two. The two should be consistent - I don't really much care which way we go but there are important semantics at play here for operator <. Specifically we're pinning down whether operator < should or should not guarantee a stable ordering across executions of the application. We can say that the C and C++ standard got the rules for T* wrong and lobby to change them, or that shared_ptr<> shouldn't have a less than operator. We might even still provide it under the claim that it shouldn't be defined but is so that std::less<> will work consistently with T* (assuming you don't want to just specialize std::less<> - which I think would be a better solution). Since we can't reasonably check semantic requirements, it is important for code correctness that we associate the requirements with the name of the operation. The signature is the only thing I can check. > Can you think of any problems that operator< could cause, in its > current > definition? In my mind, since you can't use T in your ordering > semantics, > you have no reasons to define your own ordering for shared_ptr. > Therefore, > you have no other use for operator<, and therefore if the one > defined by the > library causes no problems, we should keep it because it is practical. Not any realistic one - in general providing such an operator only breaks concept checks (when we are able to check if a function exists). But without consistent semantics it also doesn't allow me to develop any useful algorithms which rely on this. ----- > > Christoph Ludwig posted the correct reason why std::complex should > > not have an operator < () defined - sorry, my follow up using > > addition was poorly constructed. > > > > What I am proposing is that std::less should be defined for > > std::complex. > > Disagree. That could potentially break other template programming > using std::less, to support std::unary_negate etc. Suddenly this would > "work" for std::complex, when it shouldn't. Allowing code which otherwise would not be allowed is hardly breaking anything. I can see the argument that std::less<> should also be consistent with other operators. I think it is then important to define a general total order operation for this case and develop the rules. Please propose a set of rules for when operator<() should and should not be defined. > > Why would we have a separate default relation for set/map then > > std::less? std::less is intended to map to operator <() on the type > > _or_ to a total ordering for the type if operator <() is not > > defined. > > No, that's just for pointers. 20.5.7/8 says: > > "For templates greater, less, greater_equal, and less_equal, the > specializations for any pointer type yield a total > order, even if the built-in operators <, >, <=, >= do not." > > It doesn't mention std::complex or any other composite types. That still doesn't answer the question of why have another relation for set/map then std::less? And as for the intent for STL I can assure you that the intent of the designer was std::less was intended to provide a total ordering on all types. That standard also does not prohibit us from specializing std::less for use defined types. > > For pair<shared_ptr<>, int> - what makes shared_ptr special? > > The fact that it is a pointer? I don't care much if it doesn't have an > ordering. Then it shouldn't be different from T*. > > > > std::less is supposed to be operator <, unless operator < is not > > defined in which case std::less provides a total ordering. It isn't > > ambiguous. > > Where does the standard say that? I have the advantage of having Alex Stepanov on my team. I asked him. > If you want to have an ordered collection of otherwise unordered data, > the relation must be an application specific attribute. So define an > appropriate functor, and use that with std::map, etc. If we want to introduce a third (or more) way to define a standard ordering other than operator <, std::less I'm fine with that. Just specify the semantics of them. ---- > That is also how I interpret his intent based on what is currently > in the > standard, and that is why I maintain that *under the current > standard*, the > appropriate way to make a type ordered (even if only for the > associatives) > is via defining operator<. If we do this for shared_ptr it should be with a clear statement that we expect the rules for T* should be changed (or consider T* to be a legacy exception which cannot be changed). > > Why would we have a separate default relation for set/map then > > std::less? > > and: > > > As for what I expect std::greater<> et al. to do - I had that in my > > earlier 6 point note - they _better_ be defined consistently with > > std::less. > > If the standard was written with this in mind, greater<>, > less_equal<> and > greater_equal<> would have been defined in terms of less<>. It is not > reasonable to provide four customization points that the user is > supposed to > keep in sync. For me the fact that less_equal returns x <= y is strong > evidence that it is not supposed to be a customization point, but a > function > object alias of operator<=. You can make the same arguments that operator < is not intended to be a customization point because the compiler doesn't automatically provide a consistent >, >=, <= (and == and !=). The standard is a legacy that must be dealt with - this should be done by providing a consistent set of rules and then lobbying for how the standard should change to be compliant. Ideally the rules should be as consistent with the standard as possible, but the important thing is that we are always striving for a correct solution. > > For pair<shared_ptr<>, int> - what makes shared_ptr special? > > Why should it be special? If a type K is ordered, pair<K, int> > should also > be. That isn't true for T*. I contend that either both should have operator < () defined or neither. I believe for shared_ptr is is probably best to try to be consistent with T* then to lobby to get T* changed. Note that this likely still means that you want to define std::less on pair<> to be less of each of the elements. Either way, the standard is flawed. Sean

3 2

Re: [boost] [BGL] Add edge with vertex' properties instead ofvertex descriptors
by Wang Weiwei 15 Jul '06

15 Jul '06

> >On Jul 14, 2006, at 10:54 AM, Wang Weiwei wrote: > >> Hello, >> >> I have a graph type as follows: >> >> namespace boost >> { >> enum vertex_flag_t { vertex_flag = 111 }; >> BOOST_INSTALL_PROPERTY(vertex, flag); >> } >> >> typedef boost::adjacency_list<boost::vecS, boost::vecS, >> boost::undirectedS, >> property<vertex_name_t, std::string, >> property<vertex_flag_t, bool, >> property<vertex_color_t, default_color_type> > >, >> no_property> graph_t; >> >> graph_t g; >> >> That means I want to associate a string as name, a flag, and a >> default color to each vertex of my graph, >> now I want to add edges to my graph directly using the vertex' >> properties instead of their descriptors, >> e.g. >> >> boost::add_edge("vertex1", "vertex2", g); >> >> How can I accomplish this? > >You'll need to create a separate mapping from vertex names to vertex >descriptors: > > std::map<std::string, graph_t::vertex_descriptor> name_to_vertex; > > Doug I've made the following template function to do the jod I want, as indicated by its name - add vertices using their properties. template<typename InputPropIterator, typename Graph, typename VertexPropMap> //// AddVerticesByProp(InputPropIterator first, InputPropIterator last, Graph& g, VertexPropMap& pmap, //// typename std::map< typename std::iterator_traits<InputPropIterator>::value_type, typename boost::graph_traits<Graph>::vertex_descriptor >& Prop2VertexMap) { typedef boost::graph_traits<Graph>::vertex_descriptor vertex_t; typedef std::iterator_traits<InputPropIterator>::value_type prop_t; typedef std::map<prop_t, vertex_t> prop_vertex_map_t; for(; first != last; ++last) { prop_vertex_map_t::iterator pos; bool inserted; vertex_t v; boost::tie(pos, inserted) = Prop2VertexMap.insert(std::make_pair(*first, vertex_t())); if(inserted) { v = add_vertex(g); pmap[v] = *first; pos->second = v; } else { v = pos->second; } } } I suppose it could more elegant if one can remove the template param 'VertexPropMap' and the corresponding function param 'VertexPropMap& pmap', because the type 'VertexPropMap' is determined and should be derived (I think) if the other 2 types are given. To be clearer, the VertexPropMap is a map from 'typename std::iterator_traits<InputIterator>::value_type' to 'typename boost::graph_traits<Graph>::vertex_descriptor'. Similarly, as far as internal property map is concerned, the function param 'pmap' is also determined and should be derived (I think) from 'g' and type info gien by the InputPropIterator. What I need now is any help that can eliminate these 2 param's to make the funtion interface not so tedious. Thanks. Max

1 0

Interest? Virtual preprocessor functions and more
by Matt Calabrese 15 Jul '06

15 Jul '06

This email actually introduces a few different concepts, so at least skim the following paragraphs if the first couple of topics don't capture your interest. As a summary, I am introducing manipulatable preprocessor function and function template descriptions, a macro which automatically generates a "result" template for use with result_of that does not rely of typeof (based off of such function descriptions), the possibilty of macros which use function descriptions to generate tempalte metafunctions which can yield if a function object call is ambiguous or if there is no match for provided parameter types, and finally an "object" concept for preprocessor metaprogramming which allows for simulation of "virtual" or "overloaded" macros which could potentially be used to join Boost.Preprocessor containers by "overloaded" macros, allowing for fewer named preprocessor macros exposed to the user and opens the possibilty up for more generic preprocessor algorithms. _____ Preprocessor function descriptions: While developing my current library, I had to come up with a way to describe functions, member functions, function templates, and member functions in such away that they could be examined and manipulated easily by the preprocessor, ideally all with the same generic code. Such descriptions contain named template parameters in the case of a template, a specifier, a return type, named function parameters, and a qualifier in the case of member functions. Using macros, programmers can then easily change the name of the function, change the return type, transform paramters in order to change their types and/or name, and automatically generate function headers. First, is there any interest for such macros outside of use from my library. For clarity, usage is as such: // where int isthe return type, test is the name, float left is the first parameter, and float right is the second parameter #define A_FUNCTION BOOST_FUN( (int), test, ((float),left)((double),right) ) BOOST_FUN_IMPL_HEADER( A_FUNCTION ) { return static_cast< int >( left + right ); } Uses for this primarily include things such as automatic creation of forwarding functions which may alter parameter types, but also allow for several more interesting applications. ___________ That brings me to perhaps a more common use. Using this little sublibrary of functions, I am making a result template generator for function objects which allows a user to very easily create a result metafunction which is automatically defined, without the need for typeof. For instance: struct fun_obj { BOOST_RESULT( ( BOOST_MEM_FUN( (int), operator (), ((float),left)((double),right) ) ) ( BOOST_CONST_MEM_FUN( (int), operator (), ((float),left)((double),right) ) ) ( BOOST_MEM_FUN_T( ((typename),L)((typename),R), (float), operator (), ((L),left)((R),right) ) ) ) // rest of object body }; // result is equal to float typedef result_of< fun_obj( float, float ) >::type result; ____________ Going further, a macro could easily be created which also produces a metafunction that tells you if a function object call is ambiguous, and a macro could be created which produces a metafunction which tells you if a function object call has no matches for the provided argument types. Such metafunctions could potentially improve error reporting, particularly for forwarding functions. ___________ Finally, if none of that is of immediate interest, the underlying mechanism for all of this may be. What I do in order to get polymorphic behavior for different kinds of functions (normal functions, member functions, and templates), is I use a form of object system. The concept is simple, but is applicable to a large amount of areas in preprocessor metaprogramming, and I offer it as a potential fundamental change to the way Boost.Preprocessor is interfaced with by simulating macro overloading, allowing for fewer named functions but with the same functionality and for more simple creation of generic preprocessor algorithms. The concept is simply this: An object is represented by the form ( OBJECT_ID, (object_data) ) Where OBJECT_ID is a unique "type" for the object and object_data is the internal implementation fo the container. The way it works is you "construct" an object by calling a macro which takes in the data and assembles it into the object representation just described, then, internally when calling overloaded" macros arguments are forwarded to a macro which internally concatenates the function name to the OBJECT_ID and forwards the arguments once more along with the internal representation of the object. The result is a seemingly "overloaded" or "virtual" macro. As an example of how this could be extremely useful for Boost.Preprocessor is it allows for an easy way to represent consistent container concepts. For instance, as Boost.Preprocessor stands, common container operations for arrays and sequences use different names, making it difficult to work with containers generically as you would in the STL or even in MPL. However, this could all be changed, and done so by merely building on top of code that is already there. As an example, here is a BOOST_PP_FRONT macro that works with either BOOST_PP_ARRAYs or BOOST_PP_SEQs (and could be easily be made to work with lists as well). // Seq constructor #define BOOST_PP_SEQ( seq ) ( BOOST_PP_SEQ_OBJ, (seq) ) // Seq FRONT implementation #define BOOST_PP_SEQ_OBJ_FRONT( seq ) BOOST_PP_SEQ_HEAD( seq ) // Array constructor #define BOOST_PP_ARRAY( size, tuple ) ( BOOST_PP_ARRAY_OBJ, ((size,tuple)) ) // Array FRONT implementation #define BOOST_PP_ARRAY_OBJ_FRONT( array ) BOOST_PP_ARRAY_ELEM( 0, array ) // FRONT implementation #define BOOST_PP_FRONT( obj ) BOOST_PP_NULLARY_VFUN( obj, FRONT ) // And here is how the code is used: #define SOME_ARRAY BOOST_PP_ARRAY( 5, (a,b,c,d,e) ) #define SOME_SEQ BOOST_PP_SEQ( (a)(b)(c)(d)(e) ) int main() { // int a; int BOOST_PP_FRONT( SOME_ARRAY ); // a = 5; BOOST_PP_FRONT( SOME_SEQ ) = 5; } __________ Of course, front is a simple operation, but the same technique can be used to join all common container operations. For instance, a generic BOOST_PP_FOR_ALL macro could be made as well as generic transformation algorithms, etc. No longer would you have to be concerned about which preprocessor container types you are dealing with and you don't have to explicitly append the container name to container macros. With this functionality, Boost.Preprocessor could be described in a much more familiar sense to generic C++ programmers, through concepts, models, and overloaded macros. -- -Matt Calabrese

3 2

Re: [boost] [BGL] Graphviz
by Wang Weiwei 15 Jul '06

15 Jul '06

>On Fri, 14 Jul 2006 11:33:22 -0300, Wang Weiwei <wwwang(a)ccsdl.org> wrote: > >> >>> On Fri, 14 Jul 2006 10:58:00 -0300, Wang Weiwei <wwwang(a)ccsdl.org> >>> wrote: >>> >>>> I know BGL is compatible with Graphviz file format. >>>> and Graphviz is also an open source library. >>>> >>>> Is Graphviz ported to windows platform? >>> >>> Yes. >>> >>> http://www.graphviz.org/Download_windows.php >> >> I have downloaded the .src.tgz file and unzipped it. But can only get a >> .src file >> instead of an organised folder containing the C++ source files, which is >> what I expected. > >I don't know what's wrong. I just downloaded the file and WinRAR opens it >correctly. > >Bruno > Hello Bruno, Mmmm, :-( Whould you mind email a copy to me directly? Thanks Max

1 0