- Boost - lists.boost.org

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