- Boost - lists.boost.org

[serialization] CVS doesn't build with gcc 3.4.2
by Christoph Ludwig 07 Oct '04

07 Oct '04

Since the last CVS update I cannot build libboost_wserialization anymore (gcc 3.4.2 on i686-pc-linux-gnu). I get errors like the following: gcc-C++-action bin/boost/libs/serialization/build/libboost_wserialization.a/gcc/debug/text_wiarchive.o /home/cludwig/C++/boost_CVS_SF/boost/archive/text_wiarchive.hpp: In member function `Archive& boost::archive::detail::interface_iarchive<Archive>::operator>>(T&) [with T = std::basic_string<char, std::char_traits<char>, std::allocator<char> >, Archive = boost::archive::text_wiarchive]': [...] /home/cludwig/C++/boost_CVS_SF/boost/archive/text_wiarchive.hpp:61: error: `template<class T> void boost::archive::text_wiarchive_impl::load_override(T&, int) [with T = T, Archive = boost::archive::text_wiarchive]' is protected /home/cludwig/C++/boost_CVS_SF/boost/archive/detail/interface_iarchive.hpp:83: error: within this context The complete build log (presumably easier to read since not crumbled by the mail client) is available at <URL:http://tinyurl.com/6bsgv>. Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

2 2

Re:[boost] Fixing broken links
by Robert Ramey 07 Oct '04

07 Oct '04

Aleksey Gurtovoy wrote: >It would be appreciated if the maintainers of the following libraries took >care of the corresponding issues listed in >http://www.meta-comm.com/engineering/boost/links.html: ... > serialization ... The links in question are both commented out with  . Perhaps the link checker might be persuaded to skip html comments? Robert Ramey

1 0

uBLAS broken on MSVC 6.5
by Aleksey Gurtovoy 07 Oct '04

07 Oct '04

Seems like some recent changes brought MSVC to its knees -- http://tinyurl.com/3vmlv. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Re: [ross@biostat.ucsf.edu: Re: Formal Review of the SmartContainers library]
by Ross Boylan 06 Oct '04

06 Oct '04

I've snipped parts I'm not commenting on further. On Wed, Oct 06, 2004 at 01:39:55PM +0200, Thorsten Ottosen wrote: > > | 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. > > ok, did you use the review version or the older? If you send me the code, I > can take a look at it. Review version. I just sent my code in a separate (off-list) email. > > | 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. > > well, it's not quite finish yet, but I'm glad I'm on the right track. I realize now I might have been able to get away with smart pointers, as I don't think they usually copy the objects they point to. But perhaps they would have gagged on the lack of copy c'tors? At any rate, the library under review was more straight-forward. And I did want to hide whether I was using objects or pointers to them; again, this library uniquely meets that need. > > | The library was easy to use, and it worked. > > ok, good to hear. > > |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. > > this is of course unfortunate. I would like to know if you can actually > compile > the test files that comes with the library. > . I assume that I can't, as the notice said they didn't work with the release version of boost. I'm using 1.31. > > |STANDARD REVIEW QUESTIONS > | > |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. > > yeah, one thing that I have discussed with Pavol is to check for these errors > in > a debug mode. I will be able to check such violations at the next member > function access. For example: > > ptr_vector<T> vec; > std::remove_if( vec.ptr_begin(), vec.ptr_end(), something() ); > ... > vec.foo(); // this one triggers a debug check for all foo() That's a neat solution. Of course, it still requires the user to run a build in debug mode. > > | I favor a design with maximum > |compatibility with existing standard containers; it seems to me that has > |been achieved. > > ok, I guess you value that we can say eg push_back( T() ). I agree that we > should be > able to so for container<T> compatibility. > > | 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). > > yes, that will be fixed (one problem is of course there is so much > documentation). > I will probably use Jonathan T.'s java script tree-view, so users see a list > of sections of the docs in a left frame It would be nice to have a non-java version as well, as that is slightly problematic on some systems. For example, I could make java work with my current browser, but I haven't gone to the trouble. In terms of the documentation design, there are at least 3 use cases: 1) someone seeking initial familiarity with the library 2) someone who wants to know about a particular container 3) someone trying to decide which exact container to use, when they are already familiar with the library in general terms. I was mostly thinking of 2) in my comments. If you're very smart, you can think of all 3! For 2), one needs an easy way to get to the container in question, and then an easy way to see what it inherits. > |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! > > wow, that is quite a long time :-) Thanks for your effort.! You're welcome. I figured it was the least I could do in return for your effort. > > |DETAILED DOCUMENTATION COMMENTS > > [When I snip, it doesn't mean I will ignore your comments, but take it into > serious consideration when > working further on the docs and documentation] > > |* 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. > > I think I experienced the problem before I heard about it. > > http://pages.cpsc.ucalgary.ca/~kremer/STL/1024x768/ref2.html > http://www.oonumerics.org/tmpw00/kuehl.html Thanks; those are good references. > I should provide these references and improve the discription. > > | Second, it's not clear to me what smart > |containers add to this particular problem, given that smart pointers > |are available. > > I have used container< shared_ptr<T> > extensively and I still felt that > it didn't feel good. All the syntax is different with indirection all over the > place Good point. > and something as simple as vec.push_back( new Foo ) expanding into > vec.push_back( shared_ptr<Foo>( new Foo ) ) > and different cast styles etc. > > I usually can take such syntax, but I worked and do work with people that are > just plain confused by all that syntactic > overhead. For them, I think the smart pinter interface is part of the problem. > > |* 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. > > Nothing is too late, but I don't agree on these names. Do you agree that having the containers in the "smart container" library called "ptr_xxx" is a bit confusing? > > |** 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. > > ok, I guess I should seperate "see also" and "alternatives". How about "inherits from" or "protocol from" instead of "see also"? > |** 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. > > yeah, if there is one rule in C++, then it must be "if you don't know what you > are doing, don't do it" :-) > > I promise you that I will expand this discussion to include a list of safe and > unsafe standard algorithms > and that debug builds will catch other errors. Can the safe and unsafe algorithms be know a priori, without knowing the implementation of the library? > > |4. Is the indirected predicates the right solution? > |It was exactly what I was looking for, so I'm inclined to say yes :) > > ok, I'm very close to saying that we only need one class, say > indirected_fun<Fun>, > which could replace all of these functions. Would you consider such a class > harder to use? Eg, > > instead of > > ptr_set< T, ptr_greater<T> > > > you had to write > > ptr_set< T, indirected_fun< std::greater<T> > > That's fine. I thought if I set ptr_set<T> I automatically got the indirected comparison. Would that be the case under either approach? Or have I forgotten how it works? > |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. > > I asked John Torjo to provide > > copy( map_keys( m ), some_where ) > > in his range library. I think that would be a more generic solution. It would be good to mention that in the docs of this library. > > |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. > > ok, noted. > > Let me explain what kind of flexibility we might achieve if this was possible. > > 1. once you discover that you want to observe pointers in the container, you > currently > would use a bald pointer hoping all goes well and the element is not > removed; if ptr_container<shared_ptr<T>> was > posible, you could just change a typedef to switch between safe/unsafe Ah, I think I get it. You share the pointer, but you still get the benefits of automatic indirection. > > 2. you get the indirected interface instead of the normal interface > > 3. you might switch between deep clone and shallow clone semantics of > shared_ptr's just by changing a typedef > to use a different clone_manager. > Yes, that probably would be worthwhile. One other point: in material you snipped, I advocated returning an iterator and throwing an exception if something goes wrong. As you pointed out in earlier correspondence, this actually goes against the standard library model, which doesn't throw exceptions in similar circumstances. Since, in general, compatibility is good, that's a mark against that approach. In this situation, my personal urge for convenience outweighs it, but you certainly shouldn't break compatibility without a conscious judgement.

2 1

[iostreams] Review Results -- Iostreams Accepted
by Jeff Garland 06 Oct '04

06 Oct '04

Jonathan Turkanis's Iostreams library has been accepted into boost. Final vote tally from reviewers was: 14 accepts 1 reject 1 abstain There were many issues brought up and resolved during the review. I won't even attempt to repeat all those here. There were also many interesting suggestions about enhanced approaches. Most reviewers recommended acceptance regardless of the resolution of these, so I leave it to Jonathan's capable hands to deal with those. Some issues that need to be resolved: 1) Overlap with current io and more io library Recommendation: Move the library to a new directory (iostreams) and document any overlap with other io libraries. Rationale: While there is overlap, iostreams is taking a somewhat new approach that departs a bit the approach of the I/O library. Both approaches have merit and rather than trying to combine them prematurely it would be better to have both available and see which approach is better in practice. Since there was some discussion about the library name during the review, but no conclusive conclusion I'm going to leave the directory name as an issue for open discussion on the list. 2) Memory-Mapped Library At the moment the portable memory-mapped library is an implementation detail of Iostreams. It would be best if this library could be brought out of detail and made a standalone library that could be used independently of Iostreams. We need a volunteer to take this on (sounds like Jonathan will help with this). 3) zip/bzip2 library components The library source currently contains headers for zlib and bzip2. These headers should be removed from the source tree since they will complicate boost licensing. They should be replaced with instructions on how to obtain these libraries and how to configure bjam to find the headers and libraries. Since these libraries are already widely distributed they are often already installed on a platform. 4) 'piping' interface There was some support for adopting a 'pipe like' interface as originally implemented by JC van Winkel in another library, eg: filter_stream out(tee(std::cout) | encode | gzip | file("some file")); While this interface is not required for adoption, Jonathan has already implemented and will provide this interface. 5) Resource concept naming There was a long discussion of the naming of the concept Resource -- should it be Device, etc. Final resolution of this issue needs to be discussed and adopted. 6) Presidential filter example While many of us see the humor in this, there was at least one objection to introducing 'political comedy' into boost. Overall, the example should be renamed and reformulated since in a few years no one will get the joke anyway. Sorry to go politically correct here, but boost needs to be above the fray. I'd like to thank the reviewers for their time and many thoughtful reviews. And finally thanks to Jonathan for an excellent library! Jeff

10 31

threads documentation caught in infinite loop
by Eric Niebler 06 Oct '04

06 Oct '04

From the threads release_notes page (http://tinyurl.com/6rrck) clicking next takes you to the threads glossary (http://tinyurl.com/66kq2) and clicking next from that page takes you to the threads design page (http://tinyurl.com/4huct) way back at the beginning of the threads doc. An infinite loop! -- Eric Niebler Boost Consulting www.boost-consulting.com

1 0

Renaming "c++boost.gif"
by Aleksey Gurtovoy 06 Oct '04

06 Oct '04

I'm planning on doing a massive search & replace throught the docs concerned with renaming "c++boost.gif" to "boost_logo.gif" (the former is not a valid ISO 9660/Level 2 name). Please speak up soon if you have any objections/concerns! -- Aleksey Gurtovoy MetaCommunications Engineering

15 34

Typo in time duration documentation
by Robert Zeh 06 Oct '04

06 Oct '04

The example for the duration_from_string has a small typo. It reads: time_duration duration_from_string(const std::string&) From delimited string. std::string ts("23:59:59.000"); time_duraton td(duration_from_string(ts)) The type time_duraton should be time_duration. In the current CVS, it looks like the typo is in boost/libs/date_time/xmldoc/time_duration.xml around line 160. Robert Zeh http://home.earthlink.net/~rzeh

2 1

Minimal test - unnecessarily hard to compile
by Alan Stokes 06 Oct '04

06 Oct '04

I've just tried to start using the minimal test facility. Unfortunately it fails to compile, and there's no way I can fix that without radically changing my build configuration. My code has #include "boost/test/minimal.hpp" in it; my include path includes a directory which has a boost directory within it containing all the boost headers, so this works fine. But minimal.hpp includes the line #include <libs/test/src/execution_monitor.cpp> which fails to compile - because my include path doesn't have a directory with the boost libs directory in it. And nor should it. This is unfortunate, and arguably a violation of the header policy (libs as a sub-directory name is highly likely to clash with other libraries, unlike boost). Header files should not be including implementation files. This is especially the case with the minimal test facility, whose whole point is to be usable without requiring linking with implementation files. Changing to textual inclusion of implementation files is not a great improvement. Could the necessary implementation detail not be moved into some header files, which can then be included as necessary by both the cpp files and minimal.hpp? (Note that this is not a new issue - see also http://lists.boost.org/MailArchives/boost/msg05435.php) - Alan

5 5

RFC: Extending boost::escaped_list_separator<> with an empty_token_policy.
by Eddy L O Jansson 06 Oct '04

06 Oct '04

Boost / Tokenizer / Escaped List Separator - empty_token_policy patch What? This url[0]/archive[1] contains a trivial patch to Boost 1.31.0 which extends the default escaped_list_separator<> tokenizer function with an optional empty_token_policy. In addition, a patch to update the documentation to reflect this change as well as a new example program demonstrating its use, is included also. The patch implements the safe default of boost::keep_empty_tokens such that a patched version of this library behaves exactly as the old one, unless specifically instructed not to. This is done by setting empty_tokens to boost::drop_empty_tokens in the constructor. Why? This gives you the usual benefits of "Escaped List Separator" -- the ability to specify and use escape and quote characters -- but without the downside of always having to deal with empty tokens by hand. This simplifies client code. The "empty tokens" policy is already available in the less sexy char_separator<> implementation, I simply brought it forward to escaped_list_separator<> too. Why not? It might be redundant. I might have fubared the implementation. Where? [0] http://klopper.net/~eddy/src/boost-tokenizer/ [1] http://gazonk.org/~eloj/files/temp/eloj-boost-tokenizer-policy-patch.rar -- "IBM clearly did contribute a lot of the Unix-related information into Linux. We just don't know what it is." -- Kevin McBride, legal mastermind. Eddy L O Jansson | http://gazonk.org/~eloj

1 0