- Boost - lists.boost.org

Re: Copyright (again, sorry...)
by Jürgen Hunold 11 Sep '04

11 Sep '04

Hi John ! On Friday 10 September 2004 12:08, John Maddock wrote: > Juergen, > > In case you missed this at the end of my last mail, there are still > some copyright issues to try and sort out; the copyright I'm seeing > in some of your work is: > > // Copyright (c) 2003 Institute of Transport, > // Railway Construction and Operation, > // University of Hanover, Germany > // > // Author: Jürgen Hunold > > In the files: > > libs/graph/test/property_iter.cpp This was changed to BSL in current cvs already > tools/build/v2/test/railsys/libx/include/libx/test_libx.h > tools/build/v2/test/railsys/libx/src/test_libx.cpp > tools/build/v2/test/railsys/program/include/test_a.h > tools/build/v2/test/railsys/program/liba/test_a.cpp > tools/build/v2/test/railsys/program/main/main.cpp > > I don't think having your name in blanket-permission.txt is enough > for us to move these over to the BSL is it? Well, I thought it was enough ;-) Especially because all files (should) have stated: // Permission to copy, use, modify, sell and distribute this software is // granted provided this copyright notice appears in all copies. This // software is provided "as is" without express or implied warranty, and // with no claim as to its suitability for any purpose. So I thought that changing to the equivalent BSL would not be such an issue, especially because all that matters is the fact that the copyright itself stays. But luckily I'm no lawyer. > So I guess what we really need is the permission of the "Institute of > Transport", would you be able to help us out with that? Yes I can. I'm in charge of the Boost issue here, and the author of all the files, so I can give you the permission: You may change these files to the Boost Software License. I hope this is sufficient. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen, Eisenbahnbau * voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover * fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover * hunold(a)ive.uni-hannover.de ! www.ive.uni-hannover.de

2 1

serialization tests status
by Robert Ramey 10 Sep '04

10 Sep '04

NOB_AVEx - mingw >From the test output I have no idea why this fails. I also don't know which version of gcc is being used. General - mingw Tests which use wide char i/o fail because mingw standard library doesn't implement wchar_t i/o VC 8.0 Library fails to build because of an error compiling a spirit 1.8 header. This also fails in the spirit tests (chest) Comeau Wide char tests because of a bug in library implementation. Comeau has been notified and verified it's a bug. Borland, msvc 6.0, 7.0 These libraries fail to build. They depend on spirit 1.61. Spirit 1.61 in turn depends upon the existence of mpl/apply_if.hpp which has been removed. For backwards compatibility sake, there should be an apply_if even only if it's a wrapper around eval_if. intel- win32- 7.1- vc6- stlport- 4.5.3 pending library issue - under investigation gcc- 2.95.3- stlport- 4.5.3- linux I have verified that this works on Win 32 if spirit 1.61 is installed (subject to the above). Robert Ramey

1 0

[serialization] building fails on OS X...
by Ronald Garcia 10 Sep '04

10 Sep '04

Hi, I have tried a few times recently to build Boost from CVS under OS X on machine with 2 GB of memory. Unfortunately building fails at the following point: darwin-C++-action bin/boost/libs/serialization/build/libboost_wserialization.a/darwin/ release/xml_wgrammar.o virtual memory exhausted: Cannot allocate memory Has anyone else run into this problem? ron

2 1

Re: [boost] Re: [admin] Overlapping reviews -- should this be allowed?
by brangdon＠cix.compulink.co.uk 10 Sep '04

10 Sep '04

In-Reply-To: <chm2sp$bs9$1(a)sea.gmane.org> reportbase(a)yahoo.com (tom brinkman) wrote (abridged): > 2) The current backlog of libraries to review is quite large. How large? The schedule at: http://www.boost.org/more/formal_review_schedule.html is years out of date and I couldn't find an online schedule using google. > 7) The reason for not having overalpping reviews is based on the > preference for a flexible review schedule. This flexibility, > however, has a large cost in terms of not being able to provide > firm start dates for our library authors. That partly depends on whether the current necessary adjustment is a once-off or a regular thing. I suppose if a review looks like going over time, we have 4 choices: (1) Give up and reschedule the review for later - presumably 6 or more months later if it goes to the back of the queue, so as not to upset published schedules. (2) Force the review to end on time anyway, with a hurried judgement. (3) Extend the review period, and reschedule subsequent reviews. (4) Extend the review period, and don't reschedule subsequent reviews. This is the option which may lead to overlap. None of which are ideal, of course, but to me the latter two seem better then the first two. I'm inclined to think (4) should be considered on a case by case basis. It would depend mainly on whether the same people would be reviewing both of the overlapping libraries. Or rather, whether the people who aim to review both can get the first one done in time. Is it fair to say that the people who review all submissions do so relatively shallowly and quickly? And the people who review in depth, only do so for submissions they are specifically interested in and/or have expertise about and/or an immediate real-world application for? -- Dave Harris, Nottingham, UK

1 0

Re: [boost] Re: static sized strings
by Reece Dunn 10 Sep '04

10 Sep '04

Rob Stewart wrote: >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > [1] How do I pass the buffer and capacity to the implementation while > > allowing both fixed_string_base and fixed_string access to the >basic_string > > interface? I have chosen to route the data through one of the >basic_string > > constructors, requiring a const_cast. This is the best approach AFAICS. > >I haven't looked at your recent implementation, and I don't >presently have the time, so I really don't know what you're >talking about. If you can explain the dependencies to which you >refer, I'd appreciate it. I think it has bearing on the swap() >discussion. I have a class called detail::fixed_string_impl that has three data members: size, capacity and a pointer to the data buffer (len, cap and str respectively). Doing this allows the virtual functions to be removed and the implementation moved out of fixed_string. The fixed_string class can then pass its buffer and the capacity template parameter to the implementation via a constructor. The problem is that fixed_string is derived from fixed_string_base, which itself is derived from detail::basic_string_impl. This is needed to allow both fixed_string and fixed_string_base to have access to the full basic_string interface (like was done in the old implementation). The solution I have taken is to use the basic_string_impl( const CharT * s, size_type l ) constructor and use this to pass the buffer (s) and capacity (l) to the string. This is not ideal since it requires a const_cast to extract the buffer. This required modifying the constructor implementation in basic_string_impl to forward the parameters to Base and not implement them using append. The old implementation had the same problem with swap as the current one, since the string would get clipped when it is copied. For now, I will leave the implementation of swap as is (i.e. clipping and not signalling an exception), but add a note on this issue in the docs so that users are aware of it. Another problem I can forsee is using a custom char_traits or format_policy class, e.g. boost::fixed_string< 20, char, std::char_traits< char > > s1; strcpy( s1, "Hello" ); // ok boost::fixed_string< 20, char, win_char_traits< char > > s2; strcpy( s2, "There" ); // error This is the problem shared with basic_string when implementing functions using std::string. I have also fixed the problems relating to using the strxxx functions with Borland: the compiler may set them as instrinsic and add a macros defining strxxx as __strxxx__. To get around this, I now detect if they are macros and the Borland compiler is being used, then create an inlined function to the __strxxx__ version. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

filesystem exists/is_directory suggestion
by Martin 10 Sep '04

10 Sep '04

The filesystem status operations exists & is_directory will both throw if the status of the file can't be determined (access problems or race conditions). I think this makes the operations overly complicated to use since you need to enclose them in try catch blocks. You normally guard operations that use files in some way but it is easy to forget try/catch around exists / is_directory. (Noticed that exists has been updated in CVS to return true on error which is probably ok but I think is_directory need to be updated as well.) I think a good solution would be to have a non-throwing overload where the return value in case of error is specified. bool is_directory(const tdFS::path& aPath, bool aErrorRet) { try { return tdFS::is_directory(aPath); } catch (...) { return aErrorRet; } } Another way could be to have a "is_accessable" operation that determines if the status of the entry can be determined but it will not solve the racing problem. usage: for (directory_iterator itr(mypath); itr != directory_iterator(); ++itr) if (is_directory(*itr, true)) continue; // skip directories or for (directory_iterator itr(mypath); itr != directory_iterator(); ++itr) if (!is_accessable(*itr) || is_directory(*itr)) continue; instead of for (directory_iterator itr(mypath); itr != directory_iterator(); ++itr) try { if (is_directory(*itr)) continue; } catch (...) { continue; }

4 8

[admin] Overlapping reviews -- should this be allowed?
by Jeff Garland 10 Sep '04

10 Sep '04

Hi all - Our review wizard, Tom B. has suggested to me that we allow subsequent reviews to begin even if a previous review has been extended. This means 2 or more reviews will possibly be running in parallel. I don't believe we have a written policy, but I'm quite certain we have never run reviews in parallel. I also think it is a very bad idea. I believe reviews will suffer because people that want to review all the libraries in progress and participate in the discussion will not have enough time to do so. For most of us boost is a part-time thing -- we only have so much time per week to participate... This leads me to the conclusion that the current review schedule needs to be redone. 1st because IOStreams has been extended and 2nd because we agree that the current schedule is too aggressive. See http://lists.boost.org/MailArchives/boost/msg11034.php I realize it is a major pain to rearrange the agreed dates, but I don't think overlapping reviews is the answer. Thoughts? Jeff

11 26

Filesytem compile problem
by Martin 10 Sep '04

10 Sep '04

I get a compile error in boost/filesystem/operations.hpp when building an application that also uses the date_time library (using current CVS files). The problem is that date_time includes boost/operator.hpp which defines the template boost::equivalent. The name collides with boost::filesystem::equivalent. Reordering the include files (filesystem before date_time) fixes the problem for me but since boost/operators.hpp is used in a lot of libraries it might not always be that easy.

2 1

intel problems
by Pavol Droba 10 Sep '04

10 Sep '04

Hi, Most of tests in intel-win32-7.1-vc6-stlport-4.5.3 toolset are failing for the string_algo lib. Here is the output: http://tinyurl.com/5l2k4 All are linkinig errors. So there is probably an error in my jamfiles. Can somebody give me a hint what's wrong? Thanks, Pavol

1 0

RE: [boost] [filesystem] large file support test added
by Ben Hutchings 10 Sep '04

10 Sep '04

Beman Dawes <bdawes(a)acm.org> wrote: <snip> > Normally we would have a regression test that identifies the systems > which fail. But we don't test large file support directly because to > do so would be a burden on those who run the regression tests; such > tests would chew up gigabytes of disk space and might also be very > slow. <snip> why so? Unix file-systems support sparse files, as does NTFS.

2 1