- Boost - lists.preview.boost.org

Re: Re: [boost] [serialization] test_level_class_info_load*...
by Robert Ramey 08 Oct '04

08 Oct '04

>First, you need to "fix" your Jamfile to return the test targets: >... OK >=================================================================== >Having that working, lets you define the tests so that they depend on >each other (indirectly). For example: >=================================================================== >local test-suite-serialization-part-1 = > [ test-bsl-run_files test_array ] > [ test-bsl-run_files test_binary ] >; >local test-suite-serialization-part-2 = > [ test-bsl-run_files test_contained_class ] > [ test-bsl-run_files test_cyclic_ptrs ] >; >test-suite serialization : > $(test-suite-serialization-part-1) > $(test-suite-serialization-part-2) >; >DEPENDS $(gLOCATE($(test-suite-serialization-part-2):G=directory-grist) > : $(test-suite-serialization-part-1) >; Now - out of curiosity, most of the rule are of the form: rule test-bsl-run_polymorphic_archive ( test-name : sources * ) which suggests to me that I could just use: test-suite serialization : [ test-bsl-run_files test_level_class_info_load test_level_class_info_save ] Which would make ...load dependant on ...save. Or this is this answered by the following: >That last DEPENDS makes the directory for the part 2 depend on the >completion of part 1. You may ask why the directory and not the test >itself? Strangely it's because to properly chain the tests you need to >make the earliest step of the second test depend on the latest part of >the next test. And directories are the only sure thing that you can know >a test needs first. Robert Ramey

2 1

using boostbook on Windows
by Wieger Wesselink 07 Oct '04

07 Oct '04

I tried to use boostbook with native Windows, and ran into a few problems. There were two things that took me several hours to figure out. May be this could be added to the installation notes? 1) Apparently the order of the 'using boostbook' and 'using doxygen' declarations in user-config.jam matters; I did it wrong at first, and the resulting errors were incomprehensible to me: warning: Doxygen initialization: Boost.Build stylesheets not found 2) I needed to empty the bin.v2 directory to make it work. This was something I hadn't thought about, and again the error messages were quite incomprehensible. Finally, the generation of PDF doesn't work because of a problem with the jam files. It seems that fop.sh is called instead of fop.bat. Perhaps someone could have a look at this? ...found 20 targets... ...updating 1 target... fop ..\..\..\bin.v2\tools\boostbook\doc\gcc\debug\boostbook.pdf 'JAVA_HOME' is not recognized as an internal or external command, operable program or batch file. JAVA_HOME=D:/java/jdk1.5.0 D:/cpp/boostbook/fop-0.20.5/fop.sh ..\..\..\bin.v2\tools\boostbook\doc\gcc\debug\boostbook.fo ..\..\..\bin.v2\tools\boostbook\doc\gcc\debug\boostbook.pdf ...failed fop ..\..\..\bin.v2\tools\boostbook\doc\gcc\debug\boostbook.pdf... ...failed updating 1 target... If I run this from the command line with fop.bat, the file boostbook.pdf is successfully created. I have used the following settings: --- user-config.jam --- using xsltproc ; using boostbook : d:/cpp/boostbook/docbook-xsl-1.66.1 : d:/cpp/boostbook/docbook-xml-4.2 ; using doxygen ; using fop : D:/cpp/boostbook/fop-0.20.5 : D:/java/jdk1.5.0 ; Regards, Wieger -- _____________________________________________________________ Web-based SMS services available at http://www.operamail.com. >From your mailbox to local or overseas cell phones. Powered by Outblaze

1 0

Fixing broken links
by Aleksey Gurtovoy 07 Oct '04

07 Oct '04

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: algorithm build date_time iterator numeric/conversion optional program_options python range serialization test thread TIA, -- Aleksey Gurtovoy MetaCommunications Engineering

6 5

Latest cvs causes segfault on gcc version 3.4.2 20041003 (Red Hat 3.4.2-4)
by Neal D. Becker 07 Oct '04

07 Oct '04

This is current gcc for Linux/FC3T2. (Fedora core 3 test 2) /usr/local/src/boost.cvs/libs/python/build/../src/tuple.cpp: In constructor `boost::python::detail::tuple_base::tuple_base(const boost::python::api::object&)': /usr/local/src/boost.cvs/libs/python/build/../src/tuple.cpp:21: internal compiler error: Segmentation fault Bug report filed.

4 6

Re: [boost] Re: The Smart Container library
by brangdon＠cix.compulink.co.uk 07 Oct '04

07 Oct '04

In-Reply-To: <cjbuc0$csa$1(a)sea.gmane.org> nesotto(a)cs.auc.dk (Thorsten Ottosen) wrote (abridged): > It has never been the intention to support a path of "upgrade". The > semantics are very different from vector<shared_ptr<T> > and > ptr_vector<T>. The semantics are closer to vector<T> when it comes > to "copying". OK, thanks. It sounds like the library isn't really doing what I expect or want. To the point where I question whether "ptr_vector" is a good name for it, since it does not behave like a vector of pointers. Maybe something like "poly_vector" would better reflect the intent. I think I've missed the end of the review period now - they just whizz past, don't they? - but that probably doesn't matter because all I can really say is that I don't think I am a prospective user of the library. I might have been interested in a container which took ownership of the things pointed-to, but was otherwise a simple container of pointers. -- Dave Harris, Nottingham, UK

1 0

Re: [boost] Re: [Poll] New look-n-feel for Boost documentation
by brangdon＠cix.compulink.co.uk 07 Oct '04

07 Oct '04

In-Reply-To: <cjpj7l$9c2$2(a)sea.gmane.org> dheld(a)codelogicconsulting.com (David B. Held) wrote (abridged): > > I had a quick look from my mobile phone, and it worked > > reasonable well. > > Is this an important use case? I can't remember a single time where > I said to myself: "It would be really handy to look up some Boost > documentation from my phone right now." I'm a bit of a web purist. I think it should be viewable from anywhere unless there's a good reason not to be. Partly because there's so much variety in clients. Anyway, even if we do all have huge hi-res desk-top monitors available, screen real estate is precious. A good web-site should cope gracefully with small browser windows. -- Dave Harris, Nottingham, UK

1 0

[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