- Boost - lists.boost.org

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

serialization: registration of class types via header, or explicitly
by John.Clayton＠ubs.com 22 Nov '05

22 Nov '05

Hi All, I am trying to understand better how I can create a library of objects that can be streamed using boost::serialization (cool work btw). I have written a program that works OK, but there's a catch - I have to explicitly register the class types on the archiver instances before serialization. I had initially thought that the way around this was to use the following macro in the header file, just after declaring the class that will be stream-capable, e.g.: BOOST_CLASS_EXPORT( WatchdogPrimaryVote ) But if this is all I do (see below for what I really really have inside the header), then the write to a stream works OK, but reading back - in the same process space - throws an exception, telling me the class type is unregistered. When I register all known message types with the archiver explicitly, things work ok. e.g.: template < typename Archive > void registerClassTypes( Archive & ar ) { ar.template register_type < WatchdogMsgBase > ( static_cast < WatchdogMsgBase * > ( 0 ) ); ar.template register_type < WatchdogState > ( static_cast < WatchdogState * > ( 0 ) ); ar.template register_type < WatchdogPrimaryVote > ( static_cast < WatchdogPrimaryVote * > ( 0 ) ); } I am using boost_1_33_0 on Win32 with XP and Dev Env 2003 VC 7.1 - my project is a console application that links in the message as a dynamic library. So yes, I'm using __declspec(import/export). I had thought that when one uses the BOOST_CLASS_EXPORT() macro, that the types we're auto-magically added/known to the archivers, because of some definitions that get created the macro itself. Questions: ========== - Any ideas why I would have to do this (is it a problem with __declspec(imp/exp))? - Should I just throw away the idea of a dynamic library ang go static (it's all the same to me)? - With .so's on *nix would I have this same issue? (or maybe that's a little too broad cos it's compiler dependant - I don't know, looking at the details of the templates makes my eyes water sometimes). Thanks for any time that anyone has to read through all of this - sorry to include lots, I did that based on the 'more info is better' idea - although there's probably more detail I should give anyway. John Clayton PS: Here's a little more detailed background, I have : ================================================== - created a series of objects that are streamable, each derived from a common base class, using intrusive serialization - written a series of these objects, to a std::ostream, via ar & obj; - never written an instance of the base object to the stream explicitly - closed the std::ostream and re-opened it again (obviously as a std::istream type object) I am reading objects from the stream like this: WatchdogMsgBase *ptr = 0; archiver & ptr; in WatchdogPrimaryVote (derived from WatchdogMsgBase), I serialize like this: . . . template < class Archive > void serialize( Archive & ar, const unsigned int version ) { REGISTER_DERIVED_AND_BASE( WatchdogPrimaryVote, WatchdogMsgBase ); ar & BOOST_SERIALIZATION_NVP( _voteType ); ar & BOOST_SERIALIZATION_NVP( _responseType ); ar & BOOST_SERIALIZATION_NVP( _isConnected ); ar & BOOST_SERIALIZATION_NVP( _uniqueId ); } . . . BOOST_CLASS_VERSION( WatchdogPrimaryVote, 1 ) BOOST_CLASS_EXPORT( WatchdogPrimaryVote ) BOOST_CLASS_TRACKING( WatchdogPrimaryVote, boost::serialization::track_never ) // end of file and the macro expands to: #define REGISTER_DERIVED_AND_BASE(derived, base)\ boost::serialization::void_cast_register<derived,base>((derived *)0, (base *)0) Thanks John Clayton Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.

2 1