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

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

08 Oct '04

Jürgen Hunold writes: > On Wednesday 06 October 2004 17:35, Aleksey Gurtovoy wrote: > > 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. > > I've got this impression, too. > > My old PPC-6100-Mac is rotting in a corner ... ;-((( > > I don't want to spoil the release, but did you take a look at the > BoostBook generated docs ? > At least BBv2 generates files like > "bbv2.reference.buildprocess.alternatives.html" Yep, I'm aware of the issue. Or, rather, I was aware. It's taken care of now -- http://article.gmane.org/gmane.comp.lib.boost.documentation/661. > This will not work when someone tries to ship pre-built documentation on > pure ISO-9660 CD, either. > And I thought that a release tarball should contain a pre-built > documentation because no-one can be expected to install all the > necessary components to build it. Yep, it should and it will. > Do you/we want to change this, too ? > And have *lots* of cryptic, human-unreadable file names ? Well, the name length is still partly an issue, but certainly not to the extent it was before the subdirectories fix. And even the overly long names don't necessarily have to be turned into cryptic ids. For instance, something like "static_local_time_adjustor.html" doesn't have to become "id413791.html"; it can be "static_local_time_adjust00.html", or "static_local_time_00.html", or something else along these lines. Having said that, I'm going to repeat myself -- while I think all other requirements are worth sticking to, I don't feel strongly about keeping the 31-character limit. But now that we have not that many names to fix, it's tempting to go with it to the end at least for this release. > When we discuss this further, we should do it on Boost-Mailing-List Transferred; Cc'd to jamboost. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

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

08 Oct '04

< .... Thank for a very clear and concise explanation to something that is just about impossible to understand. >The solution I suggested before does the dependency: ><directory>test_*_load_*.test --> <->test_*_save_*.test >Which make that last line of the DAG above: >test --> *.test -> *.run -> *.exe, *.obj, etc -> *_load_*.test directory >-> *_save_*.test >Make sense? More or less. If I understand this correctly, then on a second run if the directory is already created, the desired dependency won't be enforces. That is the following scenario won't work a) test_..._save builds but fails at runtime. This creates all directory structures for test...save. b) test...._load will build and run but will fail because test...save failed to create an temporary file that test...load needs. >PS. If you are sure you are only going to have run tests. You could do >things like: >local test-part-2 = [ test-bsl-run_files test_class_info_load ] ; >local >test-part-1 = [ test-bsl-run_files test_class_info_save ] ; >DEPENDS $(test->part-2:S=.run) : $(test-part-1:S=.run) ; Actually I think this latter is more a kin to what is required. The dependency is that test..save must be executed successfully to create the appropriate output file to test the run of the corresponding test...load. Even if the test..save fails to build or run, it is valuable to build (though not run) to check for compilation and linkage errors) Your explanation has motivated to spend a little time with this. Robert Ramey

1 0

Re: [boost] Re: [multi_index] problem with gcc 3.4.2 for Compaq Tru64UNIX
by JOAQUIN LOPEZ MU?Z 08 Oct '04

08 Oct '04

----- Mensaje original ----- De: Markus Schöpflin <markus.schoepflin(a)comsoft.de> Fecha: Viernes, Octubre 8, 2004 5:04 pm Asunto: [boost] Re: [multi_index] problem with gcc 3.4.2 for Compaq Tru64 UNIX > Markus Schöpflin wrote: > > > Joaquín Mª López Muñoz wrote: > > > >> mips-tfile, /tmp//cctFjnCI.s:10965 string too big (35326 bytes) > >> line:? #.stabs?"and_<boost::mpl::not_<boost::is_same<boost::mpl: > >> [very long expression] > > > > A quick google search indicates that this is a problem with gcc > on alpha > > when compiling with debug symbols. A possible workaround might > be to use > > -gstabs instead of -g, I'll try it ASAP. > > I did some experiments and the only way to compile these files it > to > disable debug symbols completely. I have done that on the toolset > for gcc > used for the regression runs, I hope it helps to clean up some of > the errors. > Thanks for your help! Indeed, Boost.MultiIndex generates horribly long symbol names, it's a pita when trying to decode compiler errors (comparatively, regular STL errors are even pleasant to deal with). I'll have to think some way to shorten them in future releases. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[multi_index] problem with gcc 3.4.2 for Compaq Tru64 UNIX
by Joaquín Mª López Muñoz 08 Oct '04

08 Oct '04

Seems like some multi_index tests are failing due to lack of resources or something like that, for COMSOFT reports. http://tinyurl.com/66t2h mips-tfile, /tmp//cctFjnCI.s:10965 string too big (35326 bytes) line:? #.stabs?"and_<boost::mpl::not_<boost::is_same<boost::mpl: [very long expression] Anyone has an idea what this could be about? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

Problematic inclusion of "pthread.h".
by Markus Schöpflin 08 Oct '04

08 Oct '04

When compiling the smart pointer tests with gcc 3.4.2 on Tru64, two tests fail with an error message. (See http://tinyurl.com/4jngu ) As far as I can see, the shared pointer implementation at some point includes the "pthread.h" system header file but gcc on Tru64 requires that -pthread must be specified on the command line when including this header file. When running this test with gcc 3.4.2 on Linux the file "pthread.h" is also included but gcc doesn't require the addition of -pthread in the command line on this platform. This leads to the question whether it is ok to include "pthread.h" without specifying -pthread on the command line. Does anyone know an answer to this? Markus

5 26

Re: uBLAS broken on MSVC 6.5
by Michael Stevens 08 Oct '04

08 Oct '04

Alekskey, > Seems like some recent changes brought MSVC to its knees -- > http://tinyurl.com/3vmlv. Fix is already committed. Tomorrow we should be all green again. My plan is for this release is to get maximum compatibility with the older compilers. In particular VC6.5 7.0, GCC 2.95, Intel 7.0, and CV8.3 Then after this release I can drop many of the multitude of workaround necessary for these. With regard to Code Warrior I was hoping to develop a fix for the debug mode compilation errors show up on you metacomm test. I didn't come up with anything satisfactory however. Do you have any idea why there is such a large difference between your cw-8.3 and the RSI's cw-8.3-release tests? I can only see the command line options in the failing build. The only option I can see which could be of relevance is the '-iso-template on'. If you are both using stock versions of the build system this same option should be set for the release build as well. Thanks for you interest (and hard work), Michael

2 2

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

[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

[Boost-bugs] [ boost-Support Requests-1041059 ] Building Boost on mac os10
by SourceForge.net 05 Oct '04

05 Oct '04

Support Requests item #1041059, was opened at 2004-10-05 15:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1041059&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Building Boost on mac os10 Initial Comment: My name is Justin Heisler and i'm trying to build boost on my mac. I seem to have problems when I try the actual bjam -sTOOL=darwin command. It runs everything fine except fails on 6 targets. It says something about the -shared command not being recongized. Is there any way I can get help or work arounds? Thanks Justin heislerj(a)purdue.edu ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1041059&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

Status of Boost.Python docs?
by Christoph Ludwig 05 Oct '04

05 Oct '04

Hi, I tried to become acquainted with Boost.Python. But even the examples in the documentation won't compile. The examples leave the impression as if they are untested because they contain quite obvious errors. For instance, from libs/python/doc/v2/operators.html (current CVS): [...] struct number : boost::integer_arithmetic<number> { number(long x_) : x(x_) {} operator long() const { return x; } number& operator+=(number const& rhs) { x += rhs } number& operator-=(number const& rhs); { x -= rhs } number& operator*=(number const& rhs) { x *= rhs } number& operator/=(number const& rhs); { x /= rhs } number& operator%=(number const& rhs); { x %= rhs } long x; }; [...] There are spurious semicolons after the argument list of operators -=, /=, and %=. On the other hand, there are semicolons missing in the bodies of the in-place operators... OK, it was no problem to fix this. But if run on the complete operators example, the compiler (gcc 3.4.2 on 686-pc-linux-gnu) chokes nevertheless. And this time I can't make much sense out of the error messages. (In case someone is interested, the compiler output is online at <URL:http://tinyurl.com/5u3rr>.) The regression test table at <URL:http://boost.sourceforge.net/regression-logs/cs-Linux.html> shows a runtime failure of the operators test for gcc 3.4.2. So the corresponding C++ module could be compiled, in contrast to the example from the docs. The user-level report at the meta-comm site <URL:http://tinyurl.com/4ebxv> (last updated on Aug 11) shows that the operators test passed with gcc 3.4.1. Since the regression tests show some problems with gcc 3.4.2, I can't be completey sure whether the errors I see are due to a compiler / platform problem or to a erroneous example. Since the example contained errors that had nothing to do with Boost.Python and the compiler and since examples from the tutorial also failed I suspect the latter. Can someone explain how this particular example needs to be changed so it can be compiled? Will the examples in the docs be checked before the upcoming release? Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

3 5

re: size_t*size_t is not size_t
by Michael Stevens 05 Oct '04

05 Oct '04

On Tuesday 05 October 2004 15:19, Kasper Peeters <kasper.peeters(a)aei.mpg.de wrote: > I need to handle extremely large sparse matrices, of approximately > half a million square elements (with, typically, on the order of 5 > million non-zero entries). > > The following, however, fails on a machine where std::size_t is 4 > bytes long: > > #include <boost/numeric/ublas/matrix_sparse.hpp> > > int main () { > using namespace boost::numeric::ublas; > sparse_matrix<double> m(400000, 400000); > } I assume this is uBLAS from Boost 1.31.0 If that is the case the short answer is that you need a more recent uBLAS. The current Boost CVS HEAD will do. These overflow problem have been fix for a few months. Longer answer. Don't forget that uBLAS has several sparse format to choose from. You may find coordinate_matrix or compress_matrix more suitable then sparse_matrix. Your problem is very large and to get efficient solutions you may need to exploit any structure it has! > It fails with > > Assertion failed in file > boost/numeric/ublas/functional.hpp at line 1345: The overflow test BOOST_UBLAS_CHECK ((size1 * size2) / size1 == size2, bad_size ()); is quite amusing. It actually checks if the calculation has not already overflowed, with a small chance of a false positive. Michael -- ___________________________________ Michael Stevens Systems Engineering 34128 Kassel, Germany Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

1 0