- Boost - lists.boost.org

Port to z/OS
by Harry Goldschmitt 03 Nov '06

03 Nov '06

I'm not sure this is the right mailing list. I'm trying to port to IBM z/OS, using the IBM c89 compiler. Has anyone done this or can someone give me some help. From what I can tell, there are a lot of checks for _IBMCPP in the code. They, however, assume AIX and vacpp. I guess architecture checks would have to be added to the mix. For what it's worth, pwd.c in boost_1_33_1/tools/build/jam_src, assumes PATH_MAX is defined. Unfortunately, z/OS doesn't define it, since the maximum path names vary depending on the file system, hfs, zfs or MVS. I've kludged around it by #define PATH_MAX _POSIX_PATH_MAX, but the "correct" solution would probably be to use pathconf. Thanks, Harry

1 0

[RegEx] does match_extra flag follow the specification ?
by Luc LA. ALQUIER 03 Nov '06

03 Nov '06

The boost documentation located (HYPERLINK "http://www.boost.org/libs/regex/doc/match_flag_type.html"http://www.boost.org/libs/regex/doc/match_flag_type.html) tell this : “match_extra Instructs the matching engine to retain all available HYPERLINK "http://www.boost.org/libs/regex/doc/captures.html"capture information; if a capturing group is repeated then information about every repeat is available via HYPERLINK "http://www.boost.org/libs/regex/doc/match_results.html#m17"match_results::captures() or HYPERLINK "http://www.boost.org/libs/regex/doc/sub_match.html#m8"sub_match_captures(). “ This feature was for me THE great feature that can provide a great way to link related information together. But the behavior using this flag with search (algorithm) was not the one expected (for me). Because instead of getting information about every repeat, sub_match_captures() contains all the captures obtained for corresponding sub-expression (as documentation HYPERLINK "http://www.boost.org/libs/regex/doc/sub_match.html"http://www.boost.org/libs/regex/doc/sub_match.html of sub_match’s captures member says). A capturing group repeat differ from captures and the fact that regex behave this way prevent me to link information that were captured in the same repeat. For example (with use of named capture syntax (wich is not supported today in boost) to clarify regular expression): ^(?<time>[^ ]+)(?: (?<attr>[A-Za-z]+)=(?:"(?<qvalue>[^"]+)"|(?<svalue>[^ ]+)))+ which intend to parse this kind of lines 12/05/2006_12:04:25 id=5 msg="this is a problem" user=paul captures for this example time={‘12/05/2006_12:04:25’} attr={‘id’,’msg’,’user’} qvalue={‘this is a problem’} svalue={‘5’,’paul’} and I was expecting time={‘12/05/2006_12:04:25’} attr={‘id’,’msg’,’user’} qvalue={null,‘this is a problem’,null} svalue={‘5’,null,’paul’} I’ve got “useless” data because we loose the data structure, no way to link paul to user neither to link “msg” to “this is a problem”. Sorry for my English that’s may be a starting point for misunderstanding, but it should be cool that documentation match specification and or behave like I was expecting. I understand that there a limitation to the behavior i was expecting since it does not take care of underneath structure if there is repeated group in repeated group. There is several way to prevent loosing these relationship between data (with different degree of relevance) : - build a hierarchical tree of capture (syntactical tree) - Provide iterator on all captures that keep track apparition’s order. - Allow named capture with duplicate group name. So, is it documentation to fix or a bug? Alquier Luc -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.13.25/515 - Release Date: 03/11/2006

3 2

Boost inspection notification (2006-11-03/RC_1_34_0) *X*
by Rene Rivera 03 Nov '06

03 Nov '06

Boost Inspection Report Run Date: 17:02:37 UTC, Friday 03 November 2006 An inspection program <http://www.boost.org/tools/inspect/index.html> checks each file in the current Boost CVS for various problems, generating this as output. Problems detected include tabs in files, missing copyrights, broken URL's, and similar misdemeanors. Totals: 11675 files scanned 906 directories scanned (including root) 157 problems reported Problem counts: 0 files with invalid line endings 0 bookmarks with invalid characters 3 invalid urls 89 broken links 22 unlinked files 7 file/directory names issues 1 files with tabs 0 violations of the Boost min/max guidelines 35 usages of unnamed namespaces in headers (including .ipp files) Summary: archive (3) bind (1) boost-root (1) build (3) date_time (1) doc (2) filesystem (36) graph (3) iostreams (2) lambda (3) mpl (1) multi_array (2) parameter (2) ptr_container (1) regex (1) regression (13) serialization (1) signals (1) test (79) type_traits (1) Details: *R* invalid (cr only) line-ending *A* invalid bookmarks, invalid urls, broken links, unlinked files *N* file/directory names issues *T* tabs in file *M* uses of min or max that have not been protected from the min/max macros, or unallowed #undef-s *U* unnamed namespace in header |archive| boost/archive/basic_streambuf_locale_saver.hpp: *N* name exceeds 31 characters boost/archive/impl/xml_wiarchive_impl.ipp: *U* unnamed namespace at line 53 boost/archive/iterators/remove_whitespace.hpp: *U* unnamed namespace at line 57 |bind| boost/bind/placeholders.hpp: *U* unnamed namespace at line 25 |boost-root| index.htm: *A* broken link: ../doc/html/signals.html |build| tools/build/v1/variables.html: *A* unlinked file tools/build/v2/example/make/main.cpp.pro: *N* name contains more than one dot character ('.') tools/build/v2/test/test_system.html: *A* unlinked file |date_time| libs/date_time/xmldoc/date_time_docs_howto.html: *A* unlinked file |doc| doc/html/boost_math/inverse_complex.html: *A* unlinked file doc/html/jam.html: *A* unlinked file |filesystem| libs/filesystem/doc/do-list.htm: *A* invalid URL (hardwired file): file://?/ *A* invalid URL (hardwired file): file://?/UNC/ libs/filesystem/doc/i18n.html: *A* broken link: convenience.htm#basic_recursive_directory_iterator *A* broken link: exception.htm *A* broken link: operations.htm *A* broken link: operations.htm#Do-the-right-thing *A* broken link: operations.htm#is_directory *A* broken link: operations.htm#is_file *A* broken link: operations.htm#status libs/filesystem/doc/index.htm: *A* broken link: convenience.htm *A* broken link: fstream.htm *A* broken link: operations.htm#create_directory *A* broken link: operations.htm#create_hard_link *A* broken link: operations.htm#current_path *A* broken link: operations.htm#directory_iterator *A* broken link: operations.htm#equivalent *A* broken link: operations.htm#file_size *A* broken link: operations.htm#initial_path *A* broken link: operations.htm#is_file *A* broken link: operations.htm#is_symlink *A* broken link: operations.htm#status *A* broken link: operations.htm#symlink_status *A* broken link: path.htm#Canonical *A* broken link: path.htm#Grammar *A* broken link: path.htm#Normalized *A* broken link: path.htm#default_name_check *A* broken link: path.htm#name_check_mechanism *A* broken link: path.htm#normalize *A* broken link: path.htm#operator_eq *A* broken link: path.htm#synopsis libs/filesystem/doc/portability_guide.htm: *A* broken link: path.htm#name_check_typedef libs/filesystem/doc/tr2_proposal.html: *A* invalid URL (hardwired file): file:///C|/boost/site/libs/filesystem/doc/operations.htm#complete_note |graph| boost/graph/maximum_cardinality_matching.hpp: *N* name exceeds 31 characters libs/graph/doc/lengauer_tarjan_dominator_tree.htm: *N* name exceeds 31 characters libs/graph/doc/sorted_erdos_renyi_generator.html: *N* name exceeds 31 characters |iostreams| libs/iostreams/doc/acknowledgments.html: *A* unlinked file libs/iostreams/doc/concepts/multi-character.html: *A* unlinked file |lambda| boost/lambda/core.hpp: *U* unnamed namespace at line 62 boost/lambda/detail/lambda_functors.hpp: *U* unnamed namespace at line 25 boost/lambda/exceptions.hpp: *U* unnamed namespace at line 24 |mpl| boost/mpl/alias.hpp: *U* unnamed namespace at line 17 |multi_array| boost/multi_array/base.hpp: *U* unnamed namespace at line 69 libs/multi_array/test/generative_tests.hpp: *U* unnamed namespace at line 57 |parameter| libs/parameter/doc/html/python.html: *A* broken link: tag::x(int *A* broken link: tag::y*(int |ptr_container| libs/ptr_container/doc/tutorial_example.html: *A* unlinked file |regex| libs/regex/performance/input.html: *A* unlinked file |regression| regression/.htaccess: *N* leading character of ".htaccess" is not alphabetic tools/regression/xsl_reports/xsl/html/issues_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/html/library_developer_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/html/library_user_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/html/make_tinyurl.html: *A* unlinked file tools/regression/xsl_reports/xsl/html/summary_developer_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/html/summary_user_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/issues_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/library_developer_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/library_user_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/make_tinyurl.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/summary_developer_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/summary_user_legend.html: *A* unlinked file |serialization| libs/serialization/src/basic_xml_grammar.ipp: *U* unnamed namespace at line 43 |signals| boost/signals/detail/named_slot_map.hpp: *T* |test| boost/test/floating_point_comparison.hpp: *U* unnamed namespace at line 206 *U* unnamed namespace at line 228 boost/test/impl/cpp_main.ipp: *U* unnamed namespace at line 42 boost/test/impl/exception_safety.ipp: *U* unnamed namespace at line 400 boost/test/impl/framework.ipp: *U* unnamed namespace at line 199 boost/test/impl/plain_report_formatter.ipp: *U* unnamed namespace at line 45 boost/test/impl/progress_monitor.ipp: *U* unnamed namespace at line 38 boost/test/impl/results_collector.ipp: *U* unnamed namespace at line 106 boost/test/impl/results_reporter.ipp: *U* unnamed namespace at line 48 boost/test/impl/unit_test_log.ipp: *U* unnamed namespace at line 79 boost/test/impl/unit_test_monitor.ipp: *U* unnamed namespace at line 35 boost/test/impl/unit_test_parameters.ipp: *U* unnamed namespace at line 50 boost/test/results_collector.hpp: *U* unnamed namespace at line 40 boost/test/test_tools.hpp: *U* unnamed namespace at line 255 boost/test/utils/iterator/token_iterator.hpp: *U* unnamed namespace at line 166 boost/test/utils/named_params.hpp: *U* unnamed namespace at line 216 boost/test/utils/runtime/cla/dual_name_parameter.ipp: *U* unnamed namespace at line 43 boost/test/utils/runtime/cla/modifier.hpp: *U* unnamed namespace at line 34 boost/test/utils/runtime/env/modifier.hpp: *U* unnamed namespace at line 34 boost/test/utils/runtime/file/config_file.hpp: *U* unnamed namespace at line 169 *U* unnamed namespace at line 64 *U* unnamed namespace at line 74 boost/test/utils/runtime/file/config_file_iterator.hpp: *U* unnamed namespace at line 68 boost/test/utils/trivial_singleton.hpp: *U* unnamed namespace at line 52 *U* unnamed namespace at line 61 libs/test/build/msvc71_proj/config_file_iterator_test.vcproj: *N* name exceeds 31 characters libs/test/doc/components/prg_exec_monitor/index.html: *A* broken link: ../../../../../boost/test/cpp_main.hpp libs/test/doc/components/test_tools/index.html: *A* broken link: ../../tests/boost_check_equal_str.html libs/test/doc/components/test_tools/reference/BOOST_CHECK_CLOSE.html: *A* broken link: BOOST_CHECK_CLOSE_FRACTION.html libs/test/doc/components/test_tools/reference/BOOST_CHECK_MESSAGE.html: *A* broken link: BOOST_MESSAGE.html libs/test/doc/components/test_tools/reference/BOOST_CHECK_SMALL.html: *A* broken link: BOOST_CHECK_CLOSE_FRACTION.html libs/test/doc/components/test_tools/reference/tools_list.html: *A* broken link: ../../btl1.gif *A* broken link: BOOST_CHECK_CLOSE_FRACTION.html libs/test/doc/components/utf/components/index.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/components/test_case/abstract_interface.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/auto_register_facility.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/boost_function_tc.html: *A* broken link: ../../../../../../../boost/test/unit_test_suite_ex.hpp *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/class_tc.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/function_tc.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/index.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/param_boost_function_tc.html: *A* broken link: ../../../../../../../boost/test/unit_test_suite_ex.hpp *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/param_class_tc.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/param_function_tc.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/tc_template.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_log/custom_log_formatter.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_log/index.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_result/index.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_suite/index.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/index.html: *A* broken link: getting_started/index.html libs/test/doc/components/utf/parameters/build_info.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/catch_system_errors.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/detect_memory_leaks.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/index.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/log_format.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/log_level.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/no_result_code.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/output_format.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/random.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/report_format.html: *A* broken link: ../../../../../LICENSE_1_0.txt *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/report_level.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/show_progress.html: *A* broken link: ../../btl1.gif libs/test/doc/examples/unit_test_example1.html: *A* broken link: ../../example/unit_test_example1.cpp libs/test/doc/examples/unit_test_example2.html: *A* broken link: ../../example/unit_test_example2.cpp libs/test/doc/examples/unit_test_example3.html: *A* broken link: ../../example/unit_test_example3.cpp libs/test/doc/examples/unit_test_example4.html: *A* broken link: ../../example/unit_test_example4.cpp libs/test/doc/examples/unit_test_example5.html: *A* broken link: ../../example/unit_test_example5.cpp *A* broken link: ../../example/unit_test_example5.input libs/test/doc/tests/auto_unit_test_test.html: *A* broken link: ../../test/auto_unit_test_test.cpp libs/test/doc/tests/auto_unit_test_test_mult.html: *A* broken link: ../../test/auto_unit_test_test_mult1.cpp *A* broken link: ../../test/auto_unit_test_test_mult2.cpp libs/test/doc/tests/unit_test_suite_ex_test.html: *A* broken link: ../../test/unit_test_suite_ex_test.cpp libs/test/doc/tutorials/hello_the_testing_world.html: *A* broken link: ../../../../../LICENSE_1_0.txt *A* broken link: ../execution_monitor/index.html libs/test/doc/tutorials/new_year_resolution.html: *A* broken link: ../../../../../../LICENSE_1_0.txt |type_traits| libs/type_traits/cxx_type_traits.htm: *A* unlinked file

1 0

[Boost-bugs] [ boost-Bugs-1590010 ] static assert for boost::python::make_constructor
by SourceForge.net 03 Nov '06

03 Nov '06

Bugs item #1590010, was opened at 2006-11-03 17:09 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=1590010&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: Python Group: release 1.34.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joachim Falk (jfalk) Assigned to: David Abrahams (david_abrahams) Summary: static assert for boost::python::make_constructor Initial Comment: You get a static assertion when using boost::python::make_constructor together with the call policy return_value_policy<manage_new_object>() Test case: ===================================================== #include <boost/python.hpp> namespace Test { using namespace boost::python; class Foo { }; Foo *fooCreator() { return new Foo(); } BOOST_PYTHON_MODULE(Test) { class_<Foo>("Foo") .def("__init__", make_constructor(fooCreator, return_value_policy<manage_new_object>())); } } /* namespace Test */ Failure: ===================================================== /usr/include/boost/python/make_constructor.hpp: In instantiation of `boost::python::detail::constructor_policy<boost::python::return_value_policy<boost::python::manage_new_object, boost::python::default_call_policies> >': /usr/include/boost/python/make_constructor.hpp:150: instantiated from `boost::python::api::object boost::python::detail::make_constructor_aux(F, const CallPolicies&, const Sig&) [with F = Test::Foo*(*)(), CallPolicies = boost::python::return_value_policy<boost::python::manage_new_object, boost::python::default_call_policies>, Sig = boost::mpl::vector1<Test::Foo*>]' /usr/include/boost/python/make_constructor.hpp:236: instantiated from `boost::python::api::object boost::python::make_constructor(F, const CallPolicies&) [with F = Test::Foo*(*)(), CallPolicies = boost::python::return_value_policy<boost::python::manage_new_object, boost::python::default_call_policies>]' boost-python-test.cpp:14: instantiated from here /usr/include/boost/python/make_constructor.hpp:106: error: incomplete type ` boost::STATIC_ASSERTION_FAILURE<false>' does not have member `value' Expected Result: ===================================================== Should compile ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1590010&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

[thread] Roadmap for RW locks ?
by Roland Schwarz 03 Nov '06

03 Nov '06

Having tried to catch up with the last RW-lock discussion I am left wondering what is the conclusion of the discussion. In thread_rewrite there is an implementation from Anthony. This however currently is only for windows so far, correct? As I do understand the problem (please correct me if I am wrong) there is not a single reader-writer problem, but three: 1) reader-priority rw-access 2) writer-priority rw-access 3) starvation free rw-access which of these three cases applies is in the application domain and not in the domain of the library implementation. Consequently a generally usable library would need to provide mutices for all three cases. I can see this as a policy that is fed to the ctor of the rwmutex in the original draft of Bill Kempf: writer_priority, reader_priority, alternating_many_reads, alternating_single_read I cannot see however a similar policy parameter in thread_rewrite version. How is this getting controlled in this case? Glancing over Anthonys code I can see that he is making use of some atomic primitives and semaphore calls. So I think this should be portable fairly easy. However, since rw-mutices can be made of a mutex and some condition variables, shouldn't we follow the old principle of getting it correct first and optimize later? I'd very much like to see this happen. Not only is the generic version valuable as a fallback, but also as a reference to measure performance and correctness against. I propose the following roadmap: 0) Decide if we want the current (broken) version in 1.34. Please note that this is URGENT. (A previous poll about this interestingly did not get answered by anyone.) 1) Decide if the current interface proposed by Bill Kempf still is appropriate. 2) Correct the bug that is present in Bill's current (generic) implementation. 3) Optimize for each platform. Please give me your feedback about these issues. Thank you Roland

8 30

[Boost-bugs] [ boost-Bugs-1589911 ] Threads not working in parallel
by SourceForge.net 03 Nov '06

03 Nov '06

Bugs item #1589911, was opened at 2006-11-03 05:37 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=1589911&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: threads Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Mike Glassford (glassfordm) Summary: Threads not working in parallel Initial Comment: We have created an application that uses boost::thread to create threads - a simple producer-consumer. The problem is that on an windows XP/intel processor, the threads do not appear to work in parallel (they work fine on an AMD, also on Windows XP). More specifically, the producer thread simply produces in buffer until it exhausts all resources, and the consumer thread does not 'kick in', even if the producer calls 'yield' after each item "produced". Any hints on how to avoid this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1589911&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-bugs] [ boost-Bugs-1589807 ] Crash on exit VC8.0
by SourceForge.net 03 Nov '06

03 Nov '06

Bugs item #1589807, was opened at 2006-11-03 02:01 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=1589807&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: regex Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: John Maddock (johnmaddock) Summary: Crash on exit VC8.0 Initial Comment: Hi I get a crash on exit of my application: when examining the stack as show below I conclude that the crash heppens in the cleanup of some static objects in the boost::regex i.e. the destructor of w32_regex_traits_implementation. This happens in release build on VC8.0 with 1.33.1. Was there a patch for this? Thankx for feedback, Kenny Knecht pietjeleugenaar(a)hotmail.com kernel32.dll!7c812a5b() [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll] kernel32.dll!7c812a5b() msvcp80.dll!std::char_traits<char>::_Copy_s(char * _First1=0x09fd8490, unsigned int _Size_in_bytes=31, const char * _First2=0x7c423995, unsigned int _Count=27) Line 576 C++ msvcp80.dll!std::basic_string<char,std::char_traits<char>,std::allocator<char> >::assign(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & _Right={...}, unsigned int _Roff=1244628, unsigned int _Count=3765269347) Line 1021 + 0x2c bytes C++ 00000001() GeneMathsXT.exe!std::_Tree<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::basic_string<char,std::char_traits<char>,std::allocator<char> > const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,0> >::erase() + 0x73 bytes C++ GeneMathsXT.exe!std::_Tree<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::basic_string<char,std::char_traits<char>,std::allocator<char> > const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,0> >::erase() + 0xa4 bytes C++ GeneMathsXT.exe!boost::re_detail::w32_regex_traits_implementation<char>::~w32_regex_traits_implementation<char>() + 0x52 bytes C++ GeneMathsXT.exe!boost::detail::sp_counted_impl_p<boost::re_detail::w32_regex_traits_implementation<char> >::dispose() + 0xf bytes C++ GeneMathsXT.exe!std::list<std::pair<boost::shared_ptr<boost::re_detail::w32_regex_traits_implementation<char> >,unsigned long const *>,std::allocator<std::pair<boost::shared_ptr<boost::re_detail::w32_regex_traits_implementation<char> >,unsigned long const *> > >::clear() + 0x3e bytes C++ GeneMathsXT.exe!boost::object_cache<unsigned long,boost::re_detail::w32_regex_traits_implementation<char> >::data::~data() + 0x6b bytes C++ > msvcr80.dll!doexit(int code=0, int quick=0, int retcaller=0) Line 553 C msvcr80.dll!exit(int code=0) Line 398 + 0xd bytes C GeneMathsXT.exe!__tmainCRTStartup() Line 549 C kernel32.dll!7c816fd7() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1589807&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-11-02 [RC_1_34_0])
by Douglas Gregor 03 Nov '06

03 Nov '06

Boost Regression test failures Report time: 2006-11-02T12:34:32Z 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… 31 failures in 7 libraries iostreams (10) mpl (4) program_options (7) random (1) serialization (7) spirit (1) utility (1) |iostreams| bzip2_test: msvc-7.1 msvc-8.0 example_test: vc-6_5-stlport file_descriptor_test: cw-9.4 finite_state_filter_test: cw-9.4 gzip_test: msvc-7.1 msvc-8.0 mapped_file_test: cw-9.4 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 |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: cw-9.4 variable_map_test_dll: cw-9.4 winmain_dll: cw-9.4 |random| random_test: intel-linux-9.0 |serialization| test_class_info_load_text_warchive: vc-6_5 test_reset_object_address: vc-7_0 test_reset_object_address_dll: vc-7_0 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 |spirit| scanner_value_type_tests: gcc-4.1.0_linux |utility| operators_test: gcc-3.4.5_linux_x86_64

3 3

GIL Review
by Matt Gruenke 03 Nov '06

03 Nov '06

Apologies for the late review. Aside from the voting, I hope it will still be of some use. I appreciate the efforts of the authors, as well as the opportunity to provide feedback. What is your evaluation of the design? -------------------------------------- Elegant, but it takes a slightly simplistic view of images, in some regards. I'm concerned that GIL's color spaces combine too many distinct concepts: memory layout, channel ordering, channel type & range, and a more pure definition of a color space (e.g. basis vectors, primaries, transfer function, etc.). In practice, this may require some users to define a large number of GIL color spaces. For example, a program or library that handles encoding/decoding of MPEG-4 video (non-studio profiles) has to deal with as many as 6 variants of YUV, 4 transfer functions, and two different scales of sample values (without getting into things like n-bit profile). In addition to that, professional video production systems will also have to deal with a variety of linear, non-linear, and log-scale RGB formats. Add RGBA, and you also have to deal with whether Alpha is premultiplied. Combined with a few different channel orderings and data layouts, I fear the result is such a multiplicity of combinations that the core purpose of GIL's color space construct would be defeated. Perhaps this is simply at odds with GIL's goal of uncompromising performance. Still, I think the library shouldn't simply exclude such cases. There should be ways to trade various amounts of efficiency for various amounts of runtime flexibility. While I generally agree with Lubomir about the numerical aspects of promotion & conversion traits (i.e. the safe default will be overkill, in most cases), I do think they could have both significant runtime and structural advantages. The runtime advantages would be mostly avoidance of extra conversion steps and may require a per-algorithm override, so that the policy can be tweaked on a case-by-case basis. The structural advantages would come from being able to establish a semantic relationship between the values of different channel types. In order to get this right, I think channel types would rarely be POD types, such as int and float. Instead, an example of what you might use is a unique type that represents its value as a float, but which can have distinct traits template specializations like channel_traits<T>::zero_value(), channel_traits<T>::unity_gain_value(), and channel_traits<T>::saturated_value() (i.e. "white" value - often different from the largest value representable by the type!). I should concede that I haven't developed this idea very far, though it may provide a foundation for addressing some of the concerns raised by Dr. Reese. Is there any way to create views of an image that include a subset of the channels (for subsets larger than 1), besides color_converted_view? Or is there some way color_converted_view might come for free, in this case (I didn't get a chance to look into that)? IMO, this is pretty important for processing RGBA images since, as Ullrich Koethe points out, it's often necessary to treat Alpha differently than RGB (or YUV). Same goes for Z-buffers, and a variety of other synthetic and captured channels one might imagine. Finally, GIL seems to lack any explicit notion of non-uniform sample structures. In video, 4:2:2, 4:1:1, and 4:2:0 are ubiquitous. An image representation that can efficiently support uniform presentation of channels with different sample frequencies and phases is important for high-performance video processing applications. I accept that this is beyond GIL's intended scope, though I'm citing it as a problem I had hoped GIL would solve. While I believe a synthetic view could be used to provide 4:4:4 access to images with other sample structures, such a mechanism would likely constitute a severe performance/quality tradeoff - at least for a serious video processing application. What is your evaluation of the implementation? ---------------------------------------------- Elegant. Good focus on performance & generality. I had a few stylistic issues that probably don't bear much discussion, here. Mostly concerning line length (207 columns!?!) and type names (pixel<> vs. color<> - I agree with Fernando; as well as more minor issues). What is your evaluation of the documentation? --------------------------------------------- I found the design guide a bit terse, in places. I'm not sure it's a good stand-alone resource for providing a high-level understanding of the library. I may not be a good judge, given my familiarity with the problem domain, and the fact that I first watched the Breeze presentation. Not to contradict others' criticisms, but I did find the Doxygen docs a helpful aid, when trying to navigate the header files. The Breeze presentation provided a great starting point. Overall, I feel the written documentation isn't quite up to the standard of other Boost library docs. I expect this may be an issue for some first time users of the library, and relatively new users trying to find answers to specific questions. What is your evaluation of the potential usefulness of the library? ------------------------------------------------------------------- It's probably useful enough to warrant acceptance, as is. Again, it's facilities for color conversion are hampered with the heavy overloading of the color space concept. Did you try to use the library? With what compiler? Did you have any problems? -------------------------------------------------------------------------------- No. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? -------------------------------------------------------------------------------------------- Watched the Breeze presentation. Read the Design guide. Read all of the review-related discussions on the mailing list. Looked at many of the header files & Doxygen docs. Are you knowledgeable about the problem domain? ----------------------------------------------- Yes. Seven of my Ten years of professional experience have been focused on development of high performance software for: photorealistic 3D rendering, video compression, film & video post-production, and computer vision. Prior to that, computer graphics was one of my primary interests. Overall strengths ----------------- * Heavy use of templates & focus on matching the performance of non-generic code. * Use of STL idioms and compatibility with STL and Boost. * Good generalization of most concepts. * I like the focus on image containers, access, and conversions. These are applicable to nearly all graphics & imaging libraries and applications, whereas such a universal subset of image algorithms is virtually non-existent Weaknesses ---------- * Conflation of too many distinct concepts in color spaces. * In order to better address the problem of providing a unified interface over different image representations, more attention should be given to the semantics of certain pixel & channel values. This may help make type conversion & promotion more tractable and may result in more intuitive algorithm behavior. Do you think the library should be accepted as a Boost library? --------------------------------------------------------------- Yes. I feel the shortcomings mentioned above and by others neither prevent GIL from being usable nor useful. However, its usefulness (and perhaps usability) could be greatly enhanced, if these issues could be addressed more comprehensively. In particular, I hope the concepts of color space, data layout, and channel type can be better separated, at some point. Matt

8 29

GIL - gil wrapping OpenCV
by N H 03 Nov '06

03 Nov '06

I made wrapping of OpenCV using gil. But now, only gray image is wraped. --------------------------------------------------------------- #ifdef WIN32 #define _CRT_SECURE_NO_DEPRECATE 1 #pragma warning(disable : 4244) // #pragma warning(disable : 4996) // MSFT declared it deprecated #endif #define USE_GIL_CONCEPT_CHECK #include <iostream> #include <ipl.h> #include "cv.h" #include "highgui.h" #include "interleaved_ptr.hpp" #define IPL_DEPTH_SIGN 0x80000000 #define IPL_DEPTH_MASK 0x7FFFFFFF #define IPL_DEPTH_1U 1 #define IPL_DEPTH_8U 8 #define IPL_DEPTH_16U 16 #define IPL_DEPTH_32F 32 #define IPL_DEPTH_8S (IPL_DEPTH_SIGN| 8) #define IPL_DEPTH_16S (IPL_DEPTH_SIGN|16) #define IPL_DEPTH_32S (IPL_DEPTH_SIGN|32) #define IPL_DEPTH_64F 64 template<class PIXELTYPE>class CiplImageDepth {public: int depth;CiplImageDepth(){depth= sizeof(PIXELTYPE);}}; template<>class CiplImageDepth<unsigned char> {public: int depth;CiplImageDepth(){depth= IPL_DEPTH_8U;}}; template<>class CiplImageDepth<char> {public: int depth;CiplImageDepth(){depth= IPL_DEPTH_8S;}}; template<>class CiplImageDepth<unsigned short> {public: int depth;CiplImageDepth(){depth= IPL_DEPTH_16U;}}; template<>class CiplImageDepth<short> {public: int depth;CiplImageDepth(){depth= IPL_DEPTH_16S;}}; template<>class CiplImageDepth<int> {public: int depth;CiplImageDepth(){depth= IPL_DEPTH_32S;}}; template<>class CiplImageDepth<float> {public: int depth;CiplImageDepth(){depth= IPL_DEPTH_32F;}}; template<>class CiplImageDepth<double> {public: int depth;CiplImageDepth(){depth= IPL_DEPTH_64F;}}; using namespace gil; template < typename Iterator, typename IPLIMAGE = IplImage> class iplimage_wrap : public type_from_x_iterator<Iterator>::view_t { Iterator _iterator_; public: IPLIMAGE *pIplImage; int iplDepthDef; IPLIMAGE* initProc(int width,int height) { CiplImageDepth< channel_t > iplImageDepth; iplDepthDef=iplImageDepth.depth; pIplImage= cvCreateImage( cvSize(width, height), iplDepthDef , 1 ); return pIplImage; } iplimage_wrap(int width, int height) : _iterator_( reinterpret_cast< channel_t * > ( (pIplImage=initProc(width,height) )->imageData ) ) { (type_from_x_iterator<Iterator>::view_t )(*this) = interleaved_view( pIplImage->widthStep/sizeof(channel_t), height , _iterator_ , sizeof(channel_t) ); } ~iplimage_wrap() { cvReleaseImage( &pIplImage ); } }; int main(int argc, unsigned char* argv[]) { char winName[]="srcImg"; cvNamedWindow( winName, 1 ); IplImage *piplimg; piplimg=cvLoadImage( "test.jpg", 0 ); cvShowImage( winName, piplimg ); { std::cout << "Wait Key Input" << std::endl; cvWaitKey(0); } typedef interleaved_ptr<unsigned char*, gray_t> gray8_interleaved_ptr; typedef type_from_x_iterator<gray8_interleaved_ptr >::view_t gray8_interleaved_view_t; gray8_interleaved_view_t maped_view=interleaved_view(piplimg->widthStep ,piplimg->height, gray8_interleaved_ptr( reinterpret_cast<unsigned char *const >(piplimg->imageData) ), sizeof(unsigned char)); gray8_interleaved_view_t step2 = subimage_view(maped_view, 20,30, 40,40); iplimage_wrap<gray8_interleaved_ptr> iplim(40,40); (gray8_interleaved_view_t) iplim = step2; cvShowImage( winName, iplim.pIplImage ); { std::cout << "Wait Key Input" << std::endl; cvWaitKey(0); } cvReleaseImage( &piplimg ); return 0; }

1 0