October 2004 - Boost - lists.preview.boost.org

uBLAS results for vc7.1 too good to be true?
by Bronek Kozicki 11 Oct '04

11 Oct '04

http://www.meta-comm.com/engineering/boost-regression/developer/numeric-ubl… (http://tinyurl.com/3vmlv ) Almost all results for vc7.1 are marked "unexpected success". I think this compiler is around for enough long time to mark these results as "just expected" success? B.

3 2

[ross@biostat.ucsf.edu: Re: Formal Review of the Smart Containers library]
by Pavol Droba 11 Oct '04

11 Oct '04

Hi, this is the review from Ross Boylan. He is not subscribed to the list, but his review is very insightful, so I'm forwarding it here. Regards, Pavol ----- Forwarded message from Ross Boylan <ross(a)biostat.ucsf.edu> ----- Date: Tue, 05 Oct 2004 17:19:03 -0700 From: Ross Boylan <ross(a)biostat.ucsf.edu> Subject: Re: Formal Review of the Smart Containers library To: Pavol Droba <droba(a)topmail.sk>, boost(a)lists.boost.org Cc: ross(a)biostat.ucsf.edu X-Mailer: Ximian Evolution 1.4.6 [I am not subscribed to the boost developers' list, so I'm not sure if this message will appear there.] My review is from a non-expert user perspective. Overall, I think the library should be accepted, though I have some suggested tweaks and improvements. I am also unable to get a program using the library to compile, and that definitely should be fixed if I haven't made a silly mistake. There is one substantive area (incompatibility with some standard algorithms) that is a bit worrisome to me, and merits thought by someone wiser. I used the library (ptr_vector, ptr_set, ptr_map, including nested ptr_maps) in a pre-release form in my application. There were some minor compilation issues with that version, which I worked around, and which I assume Thorsten has fixed. My main motivations for using the library were that I was looking for a way to hide the implementation decision of whether I had containers of objects or pointers, and I had objects that were not copyable (and would have been expensive to copy). Even at that early stage, I found the documentation quite complete and extensive. The library was easy to use, and it worked. COMPILATION TROUBLES I got the version of the code in the review notice, and adjusted my code to use it (some directory names changed). I got a raft of errors, attached. I spent about 15 minutes looking into the first one, and have no immediate explanation for it. I verified that my boost 1.31 libraries have a remove_pointer.hpp file under type_traits. g++ (GCC) 3.3.4 (Debian 1:3.3.4-7) boost 1.31.0-7 Under Debian GNU/Linux. The packages on the system are mostly at the "testing" level, which is slated to become the next release when it's fully cooked. STANDARD REVIEW QUESTIONS I have not studied the design and implementation in any detail, and so have no comments on them. Actually, some of my comments on the documentation really bear on the design. My major concern is that some algorithms are not safe to use on these containers. It is not clear to me that the average user can tell exactly which algorithms there are. If the latter is true, and there is any way to remedy it, it would be very good to do so. I think if this risky area is properly documented, it will be an acceptable risk. I favor a design with maximum compatibility with existing standard containers; it seems to me that has been achieved. The documentation is extensive and quite good. I have many comments, which I will give below. The only point I consider really significant is that some of the reference material is a bit hard to navigate (I actually found the earlier version I looked at a bit clearer in this regard). The library seems quite useful to me, though I'm biased since I needed it :) But it seems to me the features of the library are of pretty broad interest, and they address issues likely to be handled with ad-hoc, partial hacks without the library. I think the current introduction could give more emphasis two significant advantages of the library. First, it can do things that aren't easily done at all with other methods, such as smart pointers. Second, it is conceptually very simple, and provides a very nice abstraction. (Both of these things are discussed early on; this is just a question of emphasis). I did try to use the library, both an earlier version and the current review version. See results discussed at the top of this note. I've spent around a day, maybe more, using the library, studying the docs, and writing this review. As noted at the outset, I only went into the implementation details when I needed to figure out how something worked or debug a problem. Offsetting this signficant amout of time is my non-expertise in these matters! I am fairly knowledgeable as a consumer of standard library containers. I am not so knowledgeable about writing template libraries. I usually proceed in blissful ignorance of the exception safety issues that concerned the author. As noted at the start, I think overall the library should be accepted, after assuring the compilation issues are worked out. You might consider some of the documentation issues. I would also recommend those with greater expertise consider the implications and possible solutions to the breakage of some standard algorithms. DETAILED DOCUMENTATION COMMENTS Here are my comments while reading through the documentation, including answers to some of the issues raised for reviewers in the documentation. I have prefaced individual points with *, and ** for more important ones. file:/usr/local/src/boost/boost/libs/smart_container/doc/smart_container.html *The date at the top lacks a year. * Might be useful to break this page into several distinct pages. * At the very beginning, it might be worth saying that the containers of smart pointers don't work at all if the objects are not Assignable or Copy Constructible. This is mentioned a few paragraphs down, but someone reading the description quickly might think the only benefit of the library is that it offers a more optimal solution to some problems. In fact, it lets you do things you couldn't otherwise do (easily). In case you can't tell, this was a major reason I used the library. * Reference to polymorphic class problem is puzzling in two ways. First, the section on the problem does not seem to state the problem directly (apparently it is how to ensure proper clean up of objects when we refer to them with pointers to a base class; perhaps it is also the fact that one can't have a list of such types directly, but need to use pointers). I had not heard of the problem and it doesn't seem like such a problem. Second, it's not clear to me what smart containers add to this particular problem, given that smart pointers are available. It is true that this library does offer one solution to the problem (if I have understood it correctly). Perhaps if the introduction that now says "In this respect the library is intended to solve the so-called polymorphic class problem." said "The library also offers a solution to the so-called polymorphic class problem." It would be clearer. * Calling this the "smart container" library and then using names like "ptr_xxx" seems an invitation to confusion. "smart_xxx" would be more natural. At this point, it may be too much trouble and possibility for error to change the names, even if you agree with this point. * In the first example, in English the sound of a cow is usually rendered as "Moooh!". * Still in that example, the use of "stable" got me thinking about stable vs unstable. In particular a "stable_type" is not a polymorphic type. I wasn't actually confused, and probably no one else will be, but it did generate a little cognitive interference. You might use "barn" instead of "stable". * do we want the tricky algorithms implemented as members? Not clear to me if to_remove in example 8 is supposed to be something in the container, or if it just needs to be equivalent (I assume the latter, by analogy with existing stuff in the standard library). Will incorrect semantics or errors result from naive use of the corresponding non-member operators? Apparently so, according to later discussion. ** I found it a bit difficult to find reference information. First, the material requires a fair number of clicks to reach. Second, it was not clear to me where to look for information that was not in a given entry. There are several reasons for this. The "see also" heading mixes material you must look at (base classes and pseudo-base classes such as reversible_smart_container) and classes that are simply related (e.g. ptr_vector and ptr_array). So it took me awhile to find the definition for auto_type used in, e.g., ptr_array. If you could distinguish inheritance relations from others, that would be good. I'm sure part of the problem is that some of the material is only a conceptual inheritance, but still it would be useful to know that, for example, ptr_vector has the protocols of ptr_sequence_adapter, which in turn has the protocols of reversible_smart_container. Also, there are notations like "Exception safety: strong guarantee". A link or further explanation would be useful for those who aren't familiar with these terms. * The first FAQ item probably saved me a lot of grief. ** The unsafe mutating algorithms, in the FAQ now, probably deserves more prominence, in a discussion (in the main documentation) of what algorithms are appropriate to use with these containers. This item makes me nervous. First, it sounds as if only an implementor of a library would know which algorithms actually moved things around by swapping. This leaves the average user unsure of which algorithms are safe. Second, it seems like asking for trouble for it to be so easy to cause problems. * FAQ on inserting member function overloading for pointer and reference. Reviewer Q: do we want this behavior? I would say definitely, as it reduces the chances for user error. * Acknowledgements: perhaps "crappy" lacks the elevated tone we seek? And, though I assume it's a good-natured jest, some might take it the wrong way. Review Issues: 4. Is the indirected predicates the right solution? It was exactly what I was looking for, so I'm inclined to say yes :) 5. Should SmartContainer::auto_type expose itself as a move_ptr? Probably; the current name seems derived from the way it's implemented (auto_ptr, I assume). But if it has auto_ptr semantics, and it's important for the user to be aware of those, it's probably best to leave it as is. 6. Should iterator range versions of assign() and insert be replaced by an Boost.Range version? Ie, should we have template< class SinglePassRange > void insert( const Range& r ); instead of template< class InputIterator > void insert( InputIterator f, InputIterator l ); ?? The more this class can behave like any std::container, the better. So I'd lean toward leaving it as is. However, if the Boost.Range thing is compatible (I'm not familar with it), this argument loses force. 7. Should we remove rbegin()/rend()? Boost.Range makes these unnecessary. Same as 6. 8. Should we add const_begin()/const_end() etc to the classes. Again, Boost.Range means we don't need to define them. As these are not in the standard, I don't think adding them is important. In fact, one could argue that adding things not in other containers may confuse users, if they think that learning the interface for one container class gives them protocols they can transfer to others. In plainer language, if this library provided const_begin, people might assume std::vector did as well. 9. Should we add iterators for traversing the keys of a map? This would mean we could say map::key_iterator b = m.begin(), e = m.end(); copy( b, e, some_where ); That would be useful. 10. should transfer() return iterator or iterator/bool pair like erase()/insert() do. I vote for returning an iterator to the start of the inserted sequence, and throwing exceptions if things go wrong. 11. should a templated map::insert() be defined: template< class Convertible2Key > void insert( Convertible2Key&, T* r ); ? This would allow usage like m.insert( "foo", new Foo ); Probably not. It might create unintended conversions, and it's probably better to leave it the client if they want this kind of behavior. 12. should we provide member algorithms for unsafe standard algorithms like unique() and remove? Yes. 13. Is the shared_ptr idea described in future directions a good idea? I'm not sure I grasp the concept well enough to comment, but it seems to me it kind of muddies the waters. That is, shared pointers are a different kind of ownership concept than this library, and I suspect it will be cleaner to keep them separate. I mean, mostly, cleaner for users. -- Ross Boylan wk: (415) 502-4031 530 Parnassus Avenue (Library) rm 115-4 ross(a)biostat.ucsf.edu Dept of Epidemiology and Biostatistics fax: (415) 476-9856 University of California, San Francisco San Francisco, CA 94143-0840 hm: (415) 550-1062 make[1]: Entering directory `/home/ross/peter/R/mspath/src/debugTest' g++ -I /home/ross/peter/R/mspath/src -I/usr/lib/R/include -MMD -MF /home/ross/peter/R/mspath/src/depends/Path.d -MP -g -O0 -c -o Path.o /home/ross/peter/R/mspath/src/trueSrc/Path.cc g++ -I /home/ross/peter/R/mspath/src -I/usr/lib/R/include -MMD -MF /home/ross/peter/R/mspath/src/depends/PathGenerator.d -MP -g -O0 -c -o PathGenerator.o /home/ross/peter/R/mspath/src/trueSrc/PathGenerator.cc g++ -I /home/ross/peter/R/mspath/src -I/usr/lib/R/include -MMD -MF /home/ross/peter/R/mspath/src/depends/SimpleRecorder.d -MP -g -O0 -c -o SimpleRecorder.o /home/ross/peter/R/mspath/src/trueSrc/SimpleRecorder.cc g++ -I /home/ross/peter/R/mspath/src -I/usr/lib/R/include -MMD -MF /home/ross/peter/R/mspath/src/depends/SuccessorGenerator.d -MP -g -O0 -c -o SuccessorGenerator.o /home/ross/peter/R/mspath/src/trueSrc/SuccessorGenerator.cc g++ -I /home/ross/peter/R/mspath/src -I/usr/lib/R/include -MMD -MF /home/ross/peter/R/mspath/src/depends/StateTimeClassifier.d -MP -g -O0 -c -o StateTimeClassifier.o /home/ross/peter/R/mspath/src/trueSrc/StateTimeClassifier.cc g++ -I /home/ross/peter/R/mspath/src -I/usr/lib/R/include -MMD -MF /home/ross/peter/R/mspath/src/depends/TestRecorder.d -MP -g -O0 -c -o TestRecorder.o /home/ross/peter/R/mspath/src/trueSrc/TestRecorder.cc In file included from /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set.hpp:23, from /home/ross/peter/R/mspath/src/trueSrc/TestRecorder.h:11, from /home/ross/peter/R/mspath/src/trueSrc/TestRecorder.cc:6: /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:22: error: parse error before `<' token /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:25: error: ISO C++ forbids declaration of `value_type' with no type /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:25: error: parse error before `;' token /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp: In member function `void boost::ptr_set_adapter<Set, CloneManager>::transfer(typename PtrContainer::iterator, PtrContainer&)': /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:252: error: parse error before `;' token In file included from /home/ross/peter/R/mspath/src/trueSrc/TestRecorder.cc:6: /home/ross/peter/R/mspath/src/boost/smart_container/detail/associative_smart_container.hpp: At global scope: /home/ross/peter/R/mspath/src/boost/smart_container/detail/associative_smart_container.hpp: In instantiation of `boost::detail::associative_smart_container<boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, boost::heap_clone_manager>': mspath.web:4864: instantiated from `boost::ptr_set_adapter_base<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> >, boost::heap_clone_manager>' mspath.web:4864: instantiated from `boost::ptr_set_adapter<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> >, boost::heap_clone_manager>' mspath.web:4864: instantiated from `boost::ptr_set<mspath::Path, boost::ptr_less<mspath::Path>, boost::heap_clone_manager>' mspath.web:4864: instantiated from here /home/ross/peter/R/mspath/src/boost/smart_container/detail/associative_smart_container.hpp:39: error: no type named `key_type' in `struct boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >' /home/ross/peter/R/mspath/src/boost/smart_container/detail/associative_smart_container.hpp:102: error: no type named `key_type' in `struct boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp: In instantiation of `boost::ptr_set_adapter_base<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> >, boost::heap_clone_manager>': mspath.web:4864: instantiated from `boost::ptr_set_adapter<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> >, boost::heap_clone_manager>' mspath.web:4864: instantiated from `boost::ptr_set<mspath::Path, boost::ptr_less<mspath::Path>, boost::heap_clone_manager>' mspath.web:4864: instantiated from here /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:61: error: no type named `key_type' in `class boost::detail::associative_smart_container<boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:84: error: no type named `key_type' in `class boost::detail::associative_smart_container<boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:90: error: no type named `key_type' in `class boost::detail::associative_smart_container<boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:96: error: no type named `key_type' in `class boost::detail::associative_smart_container<boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:101: error: no type named `key_type' in `class boost::detail::associative_smart_container<boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:107: error: no type named `key_type' in `class boost::detail::associative_smart_container<boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:113: error: no type named `key_type' in `class boost::detail::associative_smart_container<boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:119: error: no type named `key_type' in `class boost::detail::associative_smart_container<boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:125: error: no type named `key_type' in `class boost::detail::associative_smart_container<boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:133: error: no type named `key_type' in `class boost::detail::associative_smart_container<boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:141: error: no type named `key_type' in `class boost::detail::associative_smart_container<boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:150: error: no type named `key_type' in `class boost::detail::associative_smart_container<boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp: In instantiation of `boost::ptr_set_adapter<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> >, boost::heap_clone_manager>': mspath.web:4864: instantiated from `boost::ptr_set<mspath::Path, boost::ptr_less<mspath::Path>, boost::heap_clone_manager>' mspath.web:4864: instantiated from here /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:180: error: no type named `key_type' in `class boost::ptr_set_adapter_base<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:223: error: no type named `key_type' in `class boost::ptr_set_adapter_base<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:228: error: no type named `key_type' in `class boost::ptr_set_adapter_base<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> >, boost::heap_clone_manager>' mspath.web: In member function `virtual boost::indirect_iterator<std::_Rb_tree_iterator<mspath::Path*, mspath::Path* const&, mspath::Path* const*>, boost::use_default, boost::use_default, boost::use_default, boost::use_default> mspath::TestRecorder::PathSet::insertUnique(mspath::Path*)': mspath.web:5319: error: no matching function for call to ` mspath::TestRecorder::PathSet::insert(mspath::Path* const&)' /home/ross/peter/R/mspath/src/boost/smart_container/detail/reversible_smart_container.hpp:449: error: candidates are: void boost::detail::reversible_smart_container<Config, CloneManager>::insert(typename Config::iterator, typename Config::container_type::size_type, typename Config::value_type&) [with Config = boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, CloneManager = boost::heap_clone_manager] /home/ross/peter/R/mspath/src/boost/smart_container/detail/reversible_smart_container.hpp:444: error: typename Config::iterator boost::detail::reversible_smart_container<Config, CloneManager>::insert(typename Config::iterator, typename Config::value_type&) [with Config = boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, CloneManager = boost::heap_clone_manager] /home/ross/peter/R/mspath/src/boost/smart_container/detail/reversible_smart_container.hpp:432: error: typename Config::iterator boost::detail::reversible_smart_container<Config, CloneManager>::insert(typename Config::iterator, typename Config::value_type*) [with Config = boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, CloneManager = boost::heap_clone_manager] mspath.web: In member function `virtual void mspath::TestRecorder::PathSet::transferUnique(boost::indirect_iterator<std::_Rb_tree_iterator<mspath::Path*, mspath::Path* const&, mspath::Path* const*>, boost::use_default, boost::use_default, boost::use_default, boost::use_default>, mspath::TestRecorder::PathSet&)': mspath.web:5332: error: no matching function for call to `find(mspath::Path&)' mspath.web: In member function `virtual void mspath::TestRecorder::goodPath(const mspath::Path&)': mspath.web:5287: error: `find' undeclared (first use this function) mspath.web:5287: error: (Each undeclared identifier is reported only once for each function it appears in.) /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp: In member function `void boost::ptr_set_adapter<Set, CloneManager>::transfer(typename PtrContainer::iterator, PtrContainer&) [with PtrContainer = mspath::TestRecorder::PathSet, Set = std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> >, CloneManager = boost::heap_clone_manager]': mspath.web:5335: instantiated from here /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:254: error: ` p' undeclared (first use this function) dî@: In function `_InputIter std::find(_InputIter, _InputIter, const _Tp&) [with _InputIter = __gnu_cxx::__normal_iterator<const mspath::TestRecorder::GeneratorState*, std::vector<mspath::TestRecorder::GeneratorState, std::allocator<mspath::TestRecorder::GeneratorState> > >, _Tp = mspath::TestRecorder::GeneratorState]': mspath.web:5414: instantiated from here dî@:256: error: `<declaration error>' is not a function, /usr/include/c++/3.3/bits/stl_algo.h:293: error: conflict with ` template<class _InputIter, class _Tp> _InputIter std::find(_InputIter, _InputIter, const _Tp&)' /usr/include/c++/3.3/bits/stl_algo.h:298: error: in call to `find' make[1]: *** [TestRecorder.o] Error 1 make[1]: Leaving directory `/home/ross/peter/R/mspath/src/debugTest' make: *** [test] Error 2 ----- End forwarded message -----

8 12

Boost.Python tutorial files (Was: *Attention*: ISO 9660/names with multiple dots)
by Aleksey Gurtovoy 11 Oct '04

11 Oct '04

Joel writes: > David Abrahams wrote: > > The Boost.Python tutorial files you cite are generated with > > QuickBook. Joel, these babies are yours. > > Actually, these are BoostBook babies. I already noted the long > filename problems in the boost-docs list a few weks ago. Rene > Rivera added on top of my post the multiple dot issue. I > don't know BoostBook enough to fix it. No solutions were > suggested, yet. Doug? Anyone? The BoostBook part is taken care of now, see http://article.gmane.org/gmane.comp.lib.boost.documentation/661. Let me know if there is anything that still keeps us from fixing this. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Re: [boost] Re: Re: [review] Formal review of
by brangdon＠cix.compulink.co.uk 11 Oct '04

11 Oct '04

In-Reply-To: <ck8s5t$p2p$1(a)sea.gmane.org> nesotto(a)cs.auc.dk (Thorsten Ottosen) wrote (abridged): > could you post your real code along with reasons for putting a null > into the tree and maybe some comments about the density of null's in > the tree. There is no reason to put a null in the tree. The density of nulls in the tree should be zero. The code needs to be surrounded by a test, equivalent to: if (pDog != 0) { pDog->walk_to( pTree ); assert( pDog->location() == pTree ); // ... more code assuming the dog's location. } My point is that using null_object does not enable you to avoid the "if" statement. And further, having a walk_to() member which is valid for some Dog subclasses and not others, is not really an improvement. -- Dave Harris, Nottingham, UK

2 1

ATTN: Regression runners: Versioned toolsets renaming
by Aleksey Gurtovoy 11 Oct '04

11 Oct '04

The following renaming just took place in the CVS: como-win32-4.3.3-vc7.1-tools.jam -> como-4_3_3-vc7-tools.jam como-win32-4.3.3-vc7-tools.jam -> como-4_3_3-vc7_1-tools.jam borland-5.5.1-tools.jam -> borland-5_5_1-tools.jam borland-5.6.4-tools.jam -> borland-5_6_4-tools.jam cw-8.3-tools.jam -> cw-8_3-tools.jam cw-9.2-tools.jam -> cw-9_2-tools.jam cw-9.3-tools.jam -> cw-9_3-tools.jam intel-win32-7.1-vc6-stlport-4.5.3-tools.jam -> iw-7_1-vc6-stlp-4_5_3-tools.jam intel-win32-7.1-vc6-tools.jam -> iw-7_1-vc6-tools.jam intel-win32-8.0-tools.jam -> intel-win32-8_0-tools.jam intel-win32-8.1-tools.jam -> intel-win32-8_1-tools.jam mingw-3.3.1-tools.jam -> mingw-3_3_1-tools.jam mingw-3.4.1-tools.jam -> mingw-3_4_1-tools.jam mingw-3.4.2-tools.jam -> mingw-3_4_2-tools.jam vc7.1-stlport-tools.jam -> vc-7_1-stlport-tools.jam vc7.1-tools.jam -> vc-7_1-tools.jam vc8.0-tools.jam -> vc-8_0-tools.jam vc8.0-x86_amd64-tools.jam -> vc-8_0-x86_amd64-tools.jam If you are running regressions with any of these toolsets, please adjust your scripts to use the new names. "boost-base.jam", docs, and failures markup files has been updated accordingly. Note that the latter will cause a temporary disturbance in the regression reports; things should return back to normal as soon as all runners upload updated results. -- Aleksey Gurtovoy MetaCommunications Engineering

7 10

Re: [boost] [review] Formal review of the Smart Container library
by brangdon＠cix.compulink.co.uk 11 Oct '04

11 Oct '04

In-Reply-To: <97E47D90-1A3F-11D9-BF1C-003065D18932(a)twcny.rr.com> hinnant(a)twcny.rr.com (Howard Hinnant) wrote (abridged): > > The second is a container of values which may be polymorphic. It > > would be a more-or-less drop-in replacement for vector<T>. It > > would not allow nulls, and the syntax would be like > > v.begin()->method(). Although it would probably use pointers > > behind the scenes, that would be an implementation > > detail not revealed by its interface. > > I.e. a vector<T&> ? That might be a reasonable syntax, yes. -- Dave Harris, Nottingham, UK

1 0

boost-Testing mailing list
by David Abrahams 11 Oct '04

11 Oct '04

I've lost track of who wanted this mailing list, but I now have the admin password. Someone else should volunteer to administrate the list, so contact me privately and we can go from there. Regards, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

3 4

Re: [boost] [review] Formal review of the Smart Container library
by brangdon＠cix.compulink.co.uk 11 Oct '04

11 Oct '04

In-Reply-To: <797960166.20041007113153(a)topmail.sk> droba(a)topmail.sk (Pavol Droba) wrote (abridged): > Formal review of the Smart Containers library from Thorsten Ottosen > has been extended until Saturday, October 7th 2004). Goody. Here are my comments. > * What is your evaluation of the design? I felt it was a bit muddled in its objectives. For example, it presents itself as a "container of pointers to heap-allocated objects", but then does not use pointer-like syntax or support NULL pointers. It offers both begin() and ptr_begin(). I feel there are really two kinds of container here. The first is a container of pointers which takes ownership of the objects it points to. This would be a more-or-less drop-in replacement for vector<T*>. It would allow nulls, and syntax like (*v.begin())->method(). The second is a container of values which may be polymorphic. It would be a more-or-less drop-in replacement for vector<T>. It would not allow nulls, and the syntax would be like v.begin()->method(). Although it would probably use pointers behind the scenes, that would be an implementation detail not revealed by its interface. The present submission has tried to combine these two kinds of container. I believe they would be better kept separate and given different names. I'd suggest "owning_vector" and "poly_vector", or similar, since the one is about ownership of pointers and the other is about solving the polymorphic value problem. Incidently, I also dislike the library calling itself "smart" because that word is too vague. Smart in what way? I am bothered by the libraries interaction with std algorithms. For example, std::remove_if<> doesn't work with the container's iterators. That makes it, at best, a low-level library that needs to be managed carefully. > * What is your evaluation of the potential usefulness of the > library? Why not use vector<shared_ptr<T> > instead? That provides a simple out-of-the-box solution without the problems with std algorithms. The present library claims performance benefits, but if I need those I'd write my own wrapper for vector<T *> which did exactly what I needed and no more. A library which made that easier might be useful to me, but I don't think the present submission is that library. The library also claims better syntax, but for me that benefit is negligible. So I don't believe I will ever use this library. > * What is your evaluation of the implementation? > * What is your evaluation of the documentation? > * Did you try to use the library? With what compiler? Did you > have any problems? > * How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? > * Are you knowledgeable about the problem domain? I have not looked at the implementation or attempted to use the library. I read the documentation, got confused, got unconfused via this list, and then decided it was not for me. Maybe half an hour of effort. I don't expect my opinion to carry much weight. I use std containers, and have often written wrappers for containers of raw pointers. > * Do you think the library should be accepted as a Boost library? No. I strongly object to the library with its present naming. If it were renamed along the "poly_vector" lines, I would probably be neutral. -- Dave Harris, Nottingham, UK

4 3

[BGL] dag_shortest_paths broken?
by Vladimir Prus 11 Oct '04

11 Oct '04

Hello, it appears that the dag_shortest_paths algorithm is broken. The attached program tries to find the longest path by changing inf/comparison operators. The graph is 0 -----> 1 ------> 2 ^ | 3 ----------/ The edge weights are 1 for 0->1 and 1->2 and 2 for 3->1 and I'm searching for the longest path starting from '0'. The final result for '2' is 0x7FFFFFFF, while I'd expect to get '2'. The problem is two-fold. First, the algorithm runs topological sort on the graph, and process the vertices in topological order -- which include the '3' vertex. That vertex is not reachable from '0', so it should not be included in the search at all. The second problem is that the distance to that vertex is set to -inf. When combining that distance with edge weight, due to a bug we get +inf. Here's the code: template <class T> struct closed_plus { // std::abs just isn't portable :( template <class X> inline X my_abs(const X& x) const { return x < 0 ? -x : x; } T operator()(const T& a, const T& b) const { using namespace std; T inf = (numeric_limits<T>::max)(); if (b > 0 && my_abs(inf - a) < b) return inf; return a + b; } }; When 'a' is -inf (as is for '3') inf - a overflows and gives -1, and when b is greater than 1, "inf" is returned. I think that the right solution is to change the algorithm so that it does not traverse the vertices not reachable from the start one. Besides fixing my problem, this will also speed up the algorithm. For example, if you have a forest and call dag_shortest_path on the root of just one tree, the algorithm will travese all trees, setting pretty useless values for all of them. I would like to commit the attached patch. All tests still pass on gcc when it's applied. Comments? - Volodya

2 1

[spirit] documentation typo correction
by Jurko Gospodneti� 11 Oct '04

11 Oct '04

Hi In 'http://www.boost.org/libs/spirit/doc/functional.html' 'It is obvious that the authors of STL knows and practices FP.' should read 'It is obvious that the authors of STL know and practice FP'. HTH, Jurko

2 1

Re: [boost] Re: [review] Formal review of the Smart Container library
by brangdon＠cix.compulink.co.uk 10 Oct '04

10 Oct '04

In-Reply-To: <ck8rf2$njl$1(a)sea.gmane.org> nesotto(a)cs.auc.dk (Thorsten Ottosen) wrote (abridged): > At some point it was discussed to have a new policy that decided the > indirection of the reference type. I feel the kinds of container are so different that it isn't appropriate to have a user-level policy which turns one into the other. It might make sense for them to share some common implementation, though. > It create much attention. Indeed. My biggest problem was understanding what the library was, other than a grab-bag of features. The access syntax, for example - I sometimes felt it was a stand alone feature - that it would make just as much sense to have a vector<shared_ptr<T> > or vector<T*> that used the v.begin()->method() syntax, rather than something which flowed out of the specific intent of ptr_vector<T>. I suppose a policy approach might be appropriate if the same policy could be applied to all 3 kinds of vector. However, I am not keen on having 2 syntaxes for doing the same thing in the first place. I'm happy to use pointer syntax for things which are pointers. > smart in the same way smart pointers are smart. It should give the > impression of exception-safety and resource ownership. "Smart" suggests neither of those things to me. > | I am bothered by the libraries interaction with std algorithms. For > | example, std::remove_if<> doesn't work with the container's iterators. > | That makes it, at best, a low-level library that needs to be managed > | carefully. > > Ok, what do you suggest we do instead? I don't know. > | The present library claims performance benefits, but if I need those > | I'd write my own wrapper for vector<T *> which did exactly what I > | needed and no more. > > Could you enumerate what exactly you need and maybe tell why > if a library suported more than you needed, but you didn't use that > extra stuff, it would still be a bad thing? Exactly what I need depends on circumstances. For example, I don't always need to let client code enumerate the container's contents. A container which allow that would need to be wrapped by a class which hid those members, because I don't like my classes to publish more interface than they need to. > Would an unindirected interface be enough? > (eg, you can determine to disable cloning etc). I'm not sure what you mean. > Did you ever forget to implement a wrapper function > with the right exception-safety? I don't believe I've ever had a problem in that area. -- Dave Harris, Nottingham, UK

1 0

Nonconforming filenames in "libs/serialization"
by Aleksey Gurtovoy 10 Oct '04

10 Oct '04

Robert, According to http://tinyurl.com/5abnh, there are still a few nonconforming filenames in the serialization library that need to be fixed: libs/serialization/test/test_polymorphic_archive_data.hpp: filename > 31 chars libs/serialization/vc6ide/demo_portable_binary_archive.dsp: filename > 31 chars libs/serialization/vc7ide/test_derived_class_ptr..vcproj: filename contains more than one dot character ('.') libs/serialization/vc7ide/test_level_class_info_load.vcproj: filename > 31 chars libs/serialization/vc7ide/test_multiplel_ptrs..vcproj: filename contains more than one dot character ('.') Could you please take care of these? TIA, -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Boost 1_31 - Problem with Lambda, UnNamed namespaces VC7.1
by Brian Braatz 10 Oct '04

10 Oct '04

I have searched the list archive and have not found anything on this subject. I have what looks like to be an issue with MSVC7.1 and unnamed namespaces (the _1 _2 and _3 are in unnamed namespaces in boost::lambda) See below: #include <boost/bind.hpp> #include <boost/Lambda/lambda.hpp> // adding my code to the boost::lambda namespace // below works fine namespace boost { namespace lambda { void MyFunction() { using namespace std; list<int> v; v.push_back(1); v.push_back(2); v.push_back(3); v.push_back(4); v.push_back(5); // Line below works for_each(v.begin(), v.end(), std::cout << _1 << ' '); } } } // Now global namespace void MyFunction() { using namespace std; using namespace boost; using namespace boost::lambda; list<int> v; v.push_back(1); v.push_back(2); v.push_back(3); v.push_back(4); v.push_back(5); // Line below fails with a "error C2872: '_1' : ambiguous symbol" for_each(v.begin(), v.end(), std::cout << _1 << ' '); // This line DOES work for_each(v.begin(), v.end(), std::cout << boost::lambda::_1 << ' '); } Has anyone else run into this? Also- I do not have the current CVS tree handy (I am using 1.31), is this a problem on 1.32? If it is workedaround in some fashion, I can just qualify every _1 and _2 until 1.32 comes out. Thanks for any help or suggestions Brian Braatz

4 5

Re: MPL - mpl::sequence to std::sequence
by Jaap Suter 10 Oct '04

10 Oct '04

>Yeah, I guess Aleksey and Dave have been busy with >the forthcoming MPL book, but as I understand >from list postings, the MPL docs will be updated in >Boost 1.32, and mpl::for_each is one of the more useful >components. Since it's not documented, I learned how it >works from Aleksey. The following works with your code: Thanks! A lot better than my code :).

1 0

RE: [boost] Re: Boost 1_31 - Problem with Lambda, UnNamed namespaces VC7.1
by Brian Braatz 10 Oct '04

10 Oct '04

> "Brian Braatz" <brianb(a)rmtg.com> writes: > > > I have searched the list archive and have not found anything on this > > subject. > > > > I have what looks like to be an issue with MSVC7.1 and unnamed > > namespaces > > (the _1 _2 and _3 are in unnamed namespaces in boost::lambda) > David Abrahams Writes: > Don't you mean in Boost.Bind? [Brian Braatz] Yes, sorry, my mistake.

1 0

[Boost-bugs] [ boost-Bugs-1043616 ] boost::rational documentation typos(?)
by SourceForge.net 10 Oct '04

10 Oct '04

Bugs item #1043616, was opened at 2004-10-09 08:53 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=1043616&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: boost::rational documentation typos(?) Initial Comment: <http://www.boost.org/libs/rational/ rational.html#Integer%20Type%20Requirements> states: "I must be an integer-like type, that is the following expressions must be valid for any two values n and m of type I, with the "expected" semantics. [...] n / m (must truncate, and n/m must be positive if n and m are positive)" I doubt that that is what boost::rational requires. int n = 1; int m = 3; int n_over_m = n/m; if( n_over_m > 0) { std::cout << "all OK\n"; } else { std::cout << "Can't use 'int' as base type for boost::rational\n"; } <http://www.boost.org/libs/rational/rational.html#Constructors> states: "Rationals can be constructed from a pair (numerator, denominator) of integers, or a single integer" I think that the documentation should read: "Rationals can be constructed from a pair (numerator, denominator) of I's, or a single I" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1043616&group_… ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

3 5

[Boost-bugs] [ boost-Bugs-1043942 ] boost::serialization - strings with '&' character included
by SourceForge.net 10 Oct '04

10 Oct '04

Bugs item #1043942, was opened at 2004-10-10 04:06 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=1043942&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: boost::serialization - strings with '&' character included Initial Comment: The issue is related to xml serialization only. I am trying to serialize strings with & character included. When I am trying to deserialize such a string, everything after '&' just disappeared. Also I noticed that serializer doesn't convert '&' to xml entity '&'. I guess it should. However it converts from amp entity when deserializing. Even if I convert '&' to xml entity manually, the problem still occur. As I found debugging the source code, the problem happens because of wrong spirit rule in basic_xml_grammar.ipp file: CharData = (*(anychar_p - chset_p(L"&<"))) [ append_string< StringType, BOOST_DEDUCED_TYPENAME std::basic_string<CharType>::const_iterator >(rv.contents) ] ; when I deleted '&' I was able to deserialize strings with '&' at least. I do not know how it can affect other aspects of deserialization. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1043942&group_… ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

true64cxx regresion reports
by Fernando Cacciola 10 Oct '04

10 Oct '04

Hi, While adding failure markups, I noticed that the Optional library is shown as failing with true64cxx. However, looking at the error I can see that it is using an older version of the library (one which indeed is defective) I'm also seeing similar results for this toolset and the Numeric Conversion Library Can anyone fix this? TIA Fernando Cacciola SciSoft

4 7

The Concept Traits Library: naming - opinions sought
by Terje Slettebø 09 Oct '04

09 Oct '04

Hi all. In the operator/concept traits library (now renamed Concept Traits Library) that I posted about a while ago, there were, as Tobias Schwinger pointed out in a mail, several filenames that were longer than then Boost 31 character maximum. I was aware of this, but didn't know how stringent this requirement was (7 of 37 standard concept traits have more than 31 characters, the maximum being 37 characters). However, as I understand, it's not just platforms, but also things like media (such as CDs) that may impose this limit, making it more serious. The library will be put in a CVS at the http://www.neoscientists.org/ server, and we're not sure how to deal with the maximum filename length. The current directory structure is, e.g.: #include <boost/concept_traits/std/is_default_constructible.hpp> #include <boost/concept_traits/std/is_random_access_container.hpp> #include <boost/concept_traits/std/is_random_access_iterator.hpp> #include <boost/concept_traits/std/is_generator.hpp> Tobias suggested the following (the "model" part is still not decided, and may be considered separately): #include <boost/concept_traits/model/std/constructbility/default.hpp> #include <boost/concept_traits/model/std/container/random_access.hpp> #include <boost/concept_traits/model/std/iterator/random_access.hpp> #include <boost/concept_traits/model/std/function/generator.hpp> The traits would still retain their names, so <boost/concept_traits/model/std/iterator/random_access.hpp> would have is_random_access_iterator<T>. To consider the issue, we looked at Boost's type_traits, where all the traits are in the same directory, as well as libraries like MPL, where it appears to move to <boost/mpl/arithmetic/plus.hpp> (from <boost/mpl/plus.hpp>) - at least, the "arithmetic" directory is there. The same goes for PP-lib. However, in the case of CTL, the components would then have a different name than the source file, so I felt like getting some more opinions on the subject. What do you think? Opinions on whether or not "model" should be included in the path is also welcome. Bear in mind in that case that the "concept_traits" directory will also contain the "operator" (for the operator traits) and "utility" (for components to define new traits), so "model" might more clearly separate out that these are the concept traits, themselves. Also, what is the opinion on singular/plural? Boost's type_traits is plural (and this is quite similar to them), but there are otherwise mostly singular names in Boost (and the library requirements states that libraries should usually be singular). Regards, Terje

6 11

Re: [boost] Re: [review] Formal review of
by brangdon＠cix.compulink.co.uk 09 Oct '04

09 Oct '04

In-Reply-To: <ck6la2$kki$1(a)sea.gmane.org> nesotto(a)cs.auc.dk (Thorsten Ottosen) wrote (abridged): > Conclusion: disallowing 0 will not only lead to simpler, safer > programs, but it will probably also boost performance. The null object pattern can only be used if all the object's member functions have trivial post-conditions. If instead I have code like: dog.walk_to( pTree ); assert( dog.location() == pTree ); // ... more code assuming the dog's location. then it is not going to work with a null_dog. If people use it anyway there will be tears before bedtime. Of course, this is no more an argument against ptr_vector<Dog> than it is against std::vector<Dog>. I think the problem here is the name. "ptr_vector" sounds so much like a vector of pointers that people expect null pointers to be supported. There is a gap between what those people want and what ptr_vector supplies. The null object pattern is not a solution here. It just papers over the crack. -- Dave Harris, Nottingham, UK

2 1

shared_object
by Andy Little 09 Oct '04

09 Oct '04

Hi, Any interest in a shared_object? In this case its the object that is shared, not the pointer.... Nah... too obvious ;-) regards Andy Little

3 5

Trial history file; error in Boost CSS file
by Daryle Walker 09 Oct '04

09 Oct '04

I'm surprised that a full-blown version history file wasn't added a long time ago. I raided the CVS history of the main "index.htm" file for the details. Any ancient-timers know the history of 1.11.0 and earlier? Pretend that the file is at 'BOOST_ROOT/more/version_history.html'. The header looks funny; I was wondering how to replicate the current look by mutating what's given with CSS. (I was thinking of the headers seen at <http://www.mozilla.org>.) I processed what I wrote through HTML-Tidy, adding indentation and line wrap. I kept getting weird spacing with the function descriptions at the Spirit section of 1.30.1 and the Lambda block-quote at 1.28.0. I worked-around the problem by undoing the line-breaks Tidy added at those points. The problem is in the CSS file: CODE { FONT-FAMILY: Courier; white-space: pre; } This last (non-brace) line says that multiple white-space characters are _not_ collapsed into a single space. This lets CODE acts as an in-line variant of PRE, but it violates what CODE usually does! I need the default space-collapsing behavior of CODE. If no one can give me a justification for that attribute, I'm going to erase it. Even if you can justify it, do this instead: CODE.my_special { FONT-FAMILY: Courier; white-space: pre; } Then call it like so: <p>Blah blah, please <code class="my_special">keep all of my spaces</code> blah blah.</p> That way people who need the default space-collapsing attribute of CODE (like me) don't get screwed. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

[review] Formal review of the Smart Container library starts today
by Pavol Droba 08 Oct '04

08 Oct '04

Hi all, The review of the Smart Container library, written by Thorsten Ottosen starts today (September 26th, 2004) and runs for 10 days (until October 5th, 2004). The latest version of the library can be found at http://boost-sandbox.sourceforge.net/smart_container.zip or http://groups.yahoo.com/group/boost/files/pointer%20container/smart_contain… The package contains all you need to sucessfuly use the library with the Boost version 1.31 or later, however library tests require the latest Boost.Test, that is available from the main Boost CVS. What does the library provide? The library documentation states: >>>>>>>>>>>>>>>> Whenever a programmer wants to have a container of pointers to heap-allocated objects, there is usually only one exception-safe way: to make a container of smart pointers like boost::shared_ptr. This approach is suboptimal if 1. the stored objects are not shared, but owned exclusively, or 2. the overhead implied by smart pointers is inappropriate This library therefore provides standard-like containers that are for storing heap-allocated or cloned objects (or in case of a map, the mapped object must be a heap-allocated or cloned object). For each of the standard containers there is a smart container equivalent that takes ownership of the objects in an exception safe manner. In this respect the library is intended to solve the so-called polymorphic class problem. The advantages of smart containers are 1. Exception-safe and fool proof pointer storage and manipulation. 2. Notational convenience compared to the use of containers of pointers. 3. Can be used for types that are neither Assignable nor Copy Constructible. 4. No memory-overhead as containers of smart pointers can have (see 11 and 12). 5. Usually faster than using containers of smart pointers (see 11 and 12). 6. The interface is slightly changed towards the domain of pointers instead of relying on the normal value-based interface. For example, now it is possible for pop_back() to return the removed element. The disadvantages are 1. Less flexible than containers of smart pointers <<<<<<<<<<<<<<< As an example of how the new containers look like, consider that <code> typedef boost::shared_ptr<Foo> foo_ptr; std::vector<foo_ptr> vec; vec.push_back( foo_ptr( new Foo ) ); (*vec.begin())->bar(); </code> now becomes <code> boost::ptr_vector<Foo> vec; vec.push_back( new Foo ); vec.begin()->bar(); </code> In your reviews, please include the answers for the following questions: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Also, in the documentation you will find questions from the submitter to the reviewer; whenever you feel you have something to contribute on these issues, please don't hessitate to include that in your review. Thank you, Pavol Droba, review manager for the Smart Containers library.

13 57

people page
by Fernando Cacciola 08 Oct '04

08 Oct '04

Hi, Should mantainers of released libraries (like me) add themselves to the people page, or we need to be explicitely invited for this? And in that case, should we upload ourselves the photos or should we send them to one of the moderators instead? TIA Fernando Cacciola SciSoft

4 7

Re: Removing dots from toolset names
by Aleksey Gurtovoy 08 Oct '04

08 Oct '04

Jürgen Hunold writes: > Hi ! Hi Jürgen, > > On Tuesday 05 October 2004 15:10, Aleksey Gurtovoy wrote: > > Hi All, > > > > As you probably already know, we also need to take care of these: > > Why ? Can someone point me to the rationale for this ? The original rationale was "to ensure file and directory names are relatively portable": http://www.boost.org/more/lib_guide.htm#Directory_structure. Beman might be able to clarify whether ISO 9660/Level 2 requirements in particular were one of the motivating factors back then or not, but currently those are the primary driving force for getting Boost codebase to conform to these rules: We want to be able to put a Boost distribution on a CD in the unpacked form, and for that CD to be readable on the maximum number of platforms. > Where can I find out which platforms have which limits ? WWW :). Here, for instance -- http://www.zplace.com/crashtips/filename.html. > > > intel-win32-7.1-vc6-stlport-4.5.3-tools.jam: filename > 31 chars, filename > > contains more than one dot character ('.') intel-win32-7.1-vc6-tools.jam: > > Some of these toolsets exist in current 1.31.0 with _more_ than one dot. > Take vc7.1-stlport-tools.jam for example. Sure. The requirements weren't strictly inforced until now. > > > I suggest we either replace the dots with underscores, or get rid of them > > completely (besides the last one, of course), i.e. either: > > > > borland-5_5_1-tools.jam > > borland-5_6_4-tools.jam > > como-win32-4_3_3-vc7-tools.jam > > -1 > > > borland-551-tools.jam > > borland-564-tools.jam > > como-win32-433-vc7-tools.jam > > ... > > Preferences? > > +1 Thanks! > > > [I also know that there is more to this than just renaming of the files; > > any help with the whole matter would be greatly appreciated.] > > Just one curious question: > AFAIK, all of the platforms these toolsets are _for_ support both filenames > with more than 31 characters and more than one dot. > I just wonder if we should break and repair the whole V1 build system when > the offending toolsets are for platforms which don't _have_ these limits. The changes are not that drastic, but it's a reasonable question to ask. Ignoring the fact that we already have nonconforming names fixing which requires some work, IMO all the current requirements except 31-character limit are not hindering us in any significant way, are easy to satisfy, and in general have a good cost/benefit ratio. I don't feel strongly about maximum length of 31, in particular since MacOS 9 is pretty much dead, and we _are_ somewhat restrained by the limit. Being able to read a Boost CD on, let's say, Linux versions released before 1999 is definitely going to be appreciated by _somebody_, but there is a certain cost to that, and personally I'm starting to feel that may be it's not worth it. But then, as a release manager who has to take care of this issue, I'm biased. > > Just my .02€, developing on linux and win32. Thanks, they are appreciated. -- Aleksey Gurtovoy MetaCommunications Engineering

3 3