November 2005 - Boost - lists.preview.boost.org

[Boost-bugs] [ boost-Bugs-1364416 ] mistake in documentation of condition
by SourceForge.net 23 Nov '05

23 Nov '05

Bugs item #1364416, was opened at 2005-11-22 22:57 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=1364416&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 Submitted By: Nobody/Anonymous (nobody) Assigned to: Mike Glassford (glassfordm) Summary: mistake in documentation of condition Initial Comment: Hello, the documentation (http://www.boost.org/doc/html/condition.html) of class condition contains a mistake: instead of template<typename ScopedLock, typename Pred> bool timed_wait <http://www.boost.org/doc/html/condition.html> (ScopedLock&, Pred); it should be template<typename ScopedLock, typename Pred> bool timed_wait <http://www.boost.org/doc/html/condition.html> (ScopedLock&, const boost::xtime <http://www.boost.org/doc/html/xtime.html> & , Pred); so long, Oliver ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1364416&group_… ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Boost pointer containers compile errors, runtime errors, and compiler warnings
by Axter 22 Nov '05

22 Nov '05

http://www.boost.org/libs/ptr_container/doc/ptr_container.html I'm currently in the middle of writing an article making the comparison between the above boost pointer containers and the following clone smart pointers: http://code.axter.com/copy_ptr.h http://code.axter.com/cow_ptr.h I'm performing my test using boost_1_33_0, and VC++ 7.1 compiler. I'm comparring vector<copy_ptr<T> > to boost::ptr_vector<T> I want to make sure that my article is accurate and complete, so I'm posting this question. When trying to compile using copy constructor for ptr_vector, I get a compile error. boost::ptr_vector<Shape> CopyViaContainerCopyConstructor(ContainerOfOriginalShapes); //Will not compileContainerType boost::ptr_vector<Shape> CopyViaContainerCopyConstructor = ContainerOfOriginalShapes; //Will not compile Is this by design, and if so, why doesn't the boost pointer container have a copy constructor like the STL containers have? Another standard STL container interface that fails to compile using ptr_container is push_back via dereferenced iterator. Example: for(it = ContainerOfOriginalShapes.begin();it != ContainerOfOriginalShapes.end();++it) CopyViaContainerForLoopIterator.push_back(*it); Is this also by designed, and if so, why? I also notice that the follow code fails at runtime. boost::ptr_vector<Shape> CopyViaContainerForLoopOp(ContainerOfOriginalShapes.size()); for(i = 0;i < ContainerOfOriginalShapes.size();++i) CopyViaContainerForLoopOp[i] = ContainerOfOriginalShapes[i]; However, if I do the following, then it works: //Try creating the right size for the container via push_back for(i = 0;i < ContainerOfOriginalShapes.size();++i) CopyViaContainerForLoopOp.push_back(Shape::AbstractFactory(SourceData[i][0], SourceData[i][1])); //Again test copy via for loop using operator[] for(i = 0;i < ContainerOfOriginalShapes.size();++i) CopyViaContainerForLoopOp[i] = ContainerOfOriginalShapes[i]; Is there a problem with the way ptr_vector gets constructed when size argument is used for constructor with out a default value? When using the VC++ 7.1 compiler, I notice I get a compile warning "resolved overload was found by argument-dependent lookup" See full warning in following link: http://code.axter.com/boost_ptr_containers/compilerwarnings.txt Warning for following code: http://code.axter.com/boost_ptr_containers/BoostPolymorphicContainerTest.cpp http://code.axter.com/boost_ptr_containers/shape.h Is this a problem with VC++ 7.1 giving a false warning, or with the ptr_vector code design? I also welcome any additional input that may be useful for the article. Thank you

2 1

[test] please ignore
by Thorsten Ottosen 22 Nov '05

22 Nov '05

-Thorsten

1 0

Possibility of GLR parser combinators? Spirit-2?
by Korcan Hussein 22 Nov '05

22 Nov '05

I was briefly reading GLR Parsing in Haskell and found the library based off the paper HaGLR a GLR parser combinator framework and it got me thinking. With the advent of Phoenix-2 (very nice work guys) and FC++ being worked on (to be re-reviewed for boost in the not to distant future?) there could be a possibility of direct & easy port of the haskell code to C++ using either of these libraries as it's foundation and built & used in a simillar fashion to Spirit ala expression templates (maybe an idea for Spirit 2 even). There might be an issue with Phoenix-2 (i don't know enough about the subject to know for sure) since HaGLR is based on the idea of parser combinators i'd assume it takes a simillar approach to the Parsec library using monads, from what i gather from Phoenix-2 docs there currently is no plains to support monads. So what do you guys think? :-)

5 6

[Boost-bugs] [ boost-Bugs-1364007 ] [Regex] Splitting string: last empty token is "compressed"
by SourceForge.net 22 Nov '05

22 Nov '05

Bugs item #1364007, was opened at 2005-11-22 09:41 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=1364007&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 Submitted By: Nobody/Anonymous (nobody) Assigned to: John Maddock (johnmaddock) Summary: [Regex] Splitting string: last empty token is "compressed" Initial Comment: toto_lists(a)hotbox.ru Last empty token is "compressed" when using regex_token_iterator for splitting strings. BCB 5.64, boost 1.33.0 See the example, compare it with string_algo splitting: #include <boost\regex.hpp> #include <string> #include <vector> #include <iostream> #include <boost/algorithm/string/finder.hpp> #include <boost/algorithm/string/find_iterator.hpp> void with_stringAlgo() { using namespace std; vector<string> result; string to_split("&|&_field2_&|&_field3_&|&"); boost::split_iterator<string::iterator> i(to_split.begin(),to_split.end(),boost::first_finder("&|&")),j; for(;i!=j;++i) { result.push_back(boost::copy_range<std::string>(*i)); } cout<<"size is "<<result.size()<<endl; for(int i=0;i<result.size();++i) cout<<result[i]<<endl; } void with_regex() { using namespace std; using namespace boost; using namespace boost::regex_constants; string s("&|&_field2_&|&_field3_&|&"); boost::regex r("&\|&");//use &|& as delimiter boost::sregex_token_iterator i(s.begin(),s.end(),r,-1, match_default),j; // vector<string> v; copy(i,j,back_inserter(v)); // cout<<"size is "<<v.end()-v.begin()<<endl; copy(v.begin(),v.end(),ostream_iterator<string>(cout,"\n")); } int main() { with_stringAlgo(); with_regex(); } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1364007&group_… ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[iterator] indirect_iterator->
by Orjan Westin 22 Nov '05

22 Nov '05

I have a question on the indirect_iterator, and what related standards say. I assume this class is primarily aimed for use in algorithms, which is fine. An algorithm typically dereference an iterator to do its thing, be it comparing or passing the dereferenced iterator on to a function or functor. This is great. But it doesn't handle direct usage well. If I have an indirect_iterator i for, say, a pointer to std::string, I cannot treat it as any other iterator to string and empty the string with this call: i->clear(); because the pointer operator is not changed. Instead you have to dereference it and use it as a reference: (*i).clear(); It seems strange to me that one way of getting hold of the iterated object is provided, but not the other. I couldn't find anything about this in a brief look through the standard, but I would expect it to want iterators yield the same results for both formats. Does anybody know if it does say anything on this subject, and why operator->() wasn't included in indirect_iterator? Cheers, Orjan

3 5

[smart pointers] Proposal to add some small utilities
by Ion Gaztañaga 22 Nov '05

22 Nov '05

Hi to all, While developing Shmem I wrote a smart pointer to represent relative pointers and now I'm experimenting with a multi-segment shared memory pointer to create growing multi-segment shared memory containers and allocators. Both pointers are based on boost smart pointer's interface (shared_ptr, etc...). In Shmem and possibly other generic libraries the developer wants pointer-independent code, so that the pointer type is a template parameter and the same code is used for relative, reference counted, intrusive, raw, or multisegment pointers. One of such uses, in Shmem, is for example, a memory allocator (a first fit, best fit algorithm) or an intrusive container. While developing pointer-independent code, however, I've seen that some features are present in boost (for example, get_pointer() function) and other features are missing, and I would like to propose them: 1. Overloads of static_pointer_cast, dynamic_pointer_cast, const_pointer_cast overloads for raw pointers, so that we can use pointer_xxx_cast in a generic way. 2. Add reinterpret_pointer_cast to complete cast family. 3. A protocol to obtain a pointer of the same type from any pointer. For example, if you want to generically use a pointer (for example, raw or relative pointer) in a class and you want to declare another pointer to other type (raw or relative, depending on the source): //typedef typename boost::pointer_to_other //<GenericPointer, NewType>::type MyNewPointer; //A new pointer to float values typedef typename boost::pointer_to_other <SmartPtr, float>::type MyFloatPointer; We should define how this protocol is implemented in boost smart pointers (for example, using overloading or a STL-like rebind mechanism) so that every boost smart pointer developer knows how to make its pointer type protocol-aware. Shmem uses rebind-like mechanism now, but the mechanism is not important. This way, a class can receive a void pointer like a template parameter and can be pointer-independent: template <class VoidPtr> class memory_manager { struct memory_block { //... }; typedef typename boost::pointer_to_other <VoidPtr, memory_block>::type BlockPtr; BlockPtr mp_free_list; }; I think these utilities are simple to develop and quite useful. What do smart pointer experts think? Regards, Ion

2 4

Boost regression notification (2005-11-22 [RC_1_33_0])
by Douglas Gregor 22 Nov '05

22 Nov '05

Boost regression test failures ------------------------------ Report time: 2005-11-22T14:05:07Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 4 failures in 2 libraries: multi_array (1) serialization (3) |multi_array| assign: vc-8_0 |serialization| test_list_ptrs_xml_warchive_dll: vc-8_0 test_non_default_ctor2_xml_archive: vc-8_0 test_shared_ptr_text_warchive_dll: vc-8_0

1 0

Boost regression notification (2005-11-22 [HEAD])
by Douglas Gregor 22 Nov '05

22 Nov '05

Boost regression test failures ------------------------------ Report time: 2005-11-22T06:00:11Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. io Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 136 failures in 13 libraries: concept_check (13) foreach (2) graph (3) io (1) math (2) mpl (2) multi_array (1) parameter (12) serialization (30) signals (2) spirit (2) tr1 (48) typeof (18) |concept_check| stl_concept_covering: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 vc-7_1 vc-7_1 |foreach| rvalue_const: intel-win32-9_0 intel-win32-9_0 |graph| graphviz_test: vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |io| ios_state_unit_test: intel-win32-9_0 |math| complex_test: gcc-3_4_3-sunos log1p_expm1_test: gcc-3_4_3-sunos |mpl| size_t: gcc-4_0-darwin zip_view: mingw-3_4_2 |multi_array| concept_checks: mingw-3_4_2 |parameter| basics: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux efficiency: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux macros: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux sfinae: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux tutorial: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux unnamed: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |serialization| test_class_info_load_binary_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin |signals| deletion_test: vc-7_1 ordering_test: vc-7_1 |spirit| traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |tr1| run_complex_overloads: gcc-2.95.3-linux gcc-3_4_3-sunos std_run_complex_overloads: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3_4_3-sunos std_run_random: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_boost: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_complex: gcc-2.95.3-linux std_test_hash: gcc-2.95.3-linux std_test_regex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_result_of: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_tr1_include: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_tuple: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_type_traits: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin test_algorithm: gcc-2.95.3-stlport-4.6.2-linux test_complex: gcc-2.95.3-linux test_exception: gcc-2.95.3-stlport-4.6.2-linux test_hash: gcc-2.95.3-linux test_ios: gcc-2.95.3-linux test_istream: gcc-2.95.3-linux test_iterator: gcc-2.95.3-linux test_limits: gcc-2.95.3-linux test_locale: gcc-2.95.3-linux test_new: gcc-2.95.3-stlport-4.6.2-linux test_ostream: gcc-2.95.3-linux test_regex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_result_of: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_streambuf: gcc-2.95.3-linux test_tr1_include: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_tuple: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_type_traits: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3_3-darwin test_utility: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |typeof| data_member_native: cw-9_4 function_native: cw-9_4 function_ptr_native: cw-9_4 function_ref_native: cw-9_4 lvalue_native: cw-9_4 member_function_native: cw-9_4 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 noncopyable_native: cw-9_4 std_emulation: cw-9_4 std_native: cw-9_4 template_dependent_native: cw-9_4 template_enum_native: cw-9_4 template_int_native: cw-9_4 template_multiword_native: cw-9_4 template_tpl_native: cw-9_4 template_type_native: cw-9_4 type_native: cw-9_4

1 0

[Python] VC++ 7.1 workaround needed in boost/python/class.hpp
by Douglas Gregor 22 Nov '05

22 Nov '05

I'm running into problems with Visual C++ 7.1 and class_<..>::add_property() in Boost.Python. The issue pops up in this bit o' code: class_<Graph> graph(name); graph .add_property("vertex_properties", &py_get_vertex_properties<Graph>, "A Python dictionary mapping from vertex property names to\n" "property maps. These properties are \"attached\" to the graph\n" "and will be pickled or serialized along with the graph.") .add_property("edge_properties", &py_get_edge_properties<Graph>, "A Python dictionary mapping from edge property names to\n" "property maps. These properties are \"attached\" to the graph\n" "and will be pickled or serialized along with the graph.") In particular, the compiler chokes when instantiating add_property(), because it can't tell that the third parameter is a docstring (instead of a setter). At line 304 of boost/python/class.hpp (RC_1_33_0 branch), there is a workaround for all Visual C++ versions prior to 7.1 that avoids this problem: if I switch the "1300" to "1310" to include VC++ 7.1, everything works fine. Unfortunately, I wasn't able to create a small test case that exhibits the problem. If you really, really want to reproduce the problem, you can grab the BGL-Python bindings that triggered it with: svn co https://svn.osl.iu.edu/svn/projects/viz/bgl-python Should we do the version bump in the workaround, or could that cause problems? Doug

2 1