- Boost - lists.preview.boost.org

Tom Brinkman to become the new Review Wizard
by John Maddock 22 Jul '04

22 Jul '04

Boosters, As you will know already, we recently advertised for a Review Wizard to take over from Thomas Witt, who pioneered the role and has done an excellent job, but now has other commitments. We have had several excellent applications giving the moderators a tough choice: but in the end an excellent application and a healthy dose of enthusiasm gave Tom Brinkman the job. On behalf of all the moderators I'd like to welcome Tom to the post, and look forward to the reviews once again progressing. Regards, John Maddock.

1 0

[bug, patch] Bashism in boost/tools/build/v2/tools/common.jam
by Philipp Frauenfelder 22 Jul '04

22 Jul '04

Hi There is a bashism in common.jam of Boost.Build v2. I have reported this problem to the jamboost mailing list but apparently, nobody picked it up (no reply whatsoever). The normal 'sh' shell does not allow 'export VAR=value' but only 'VAR=value;export VAR' instead. The patch against 1.24 is attached (I also removed some trailing white space, there is more 4 lines down but I did not correct it). Regards -- Philipp | work: pfrauenf(a)math.ethz.ch +41 44 632 60 38 Frauenfelder | home: pfrauenf(a)debian.org +41 44 862 73 14 [PGP] | http://www.math.ethz.ch/~pfrauenf/ Proudly running Debian GNU/Linux. See http://www.debian.org/

1 0

question regarding vacpp tests and mpl
by Robert Ramey 22 Jul '04

22 Jul '04

The serialization library is failing all tests with IBM visual age compiler. Errors occur within mpl. a) Can any one give me some hints to try to address this? b) Is there not a new version of mpl that is going to uploaded. Maybe if I just wait things will improve? Robert Ramey

2 1

RE: Boost.Test and mingw (Was: [boost] [1.32 release] Intel 8.0/M ingw regression results)
by Rob Lievaart 22 Jul '04

22 Jul '04

Hi, Hi Volodya, There are some lines in test_tools.cpp to work around this but are defined only for GCC 3.3 and I am using 3.2 :-( There was a discussion on this isssue (I think) 2 days ago: http://lists.boost.org/MailArchives/boost/msg67745.php Where Gennadiy says he wil fix it. But that has not made it into cvs yet. This is the cause of a lot of errors in the report. I "hacked" around it locally by also testing for GCC 3.2 and that clears up a lot of the problems. I could post a diff for what I changed locally, but it is not a nice solution. I simply changed the == sign in the test for minor version to <= . The test discussed in the mail is better I guess. Kind regards, Rob Lievaart. Vladimir Prus wrote: > > Aleksey Gurtovoy wrote: > > Stefan Slapeta's Intel 8.0 and Rob Lievaart's Mingw/gcc 3.2.3 results > > are now available in the Boost-wide summary reports: > > > > http://www.boost.org/regression-logs/developer/summary.html > > It shows that Boost.Test fails to build at mingw, with this error: > > Z:/regression/boost/libs/test/src/test_tools.cpp: In function `bool > > boost::test_tools::tt_detail::equal_and_continue_impl(const wchar_t*, const > > wchar_t*, boost::wrap_stringstream&, boost::unit_test::basic_cstring<const > > char>, unsigned int, boost::unit_test::log_level)': > > Z:/regression/boost/libs/test/src/test_tools.cpp:190: `wcscmp' undeclared in > > namespace `std' > > Any ideas how to fix this?

3 2

Problems with program_options using GCC 3.4 on FreeBSD
by Jonathan Wakely 22 Jul '04

22 Jul '04

Hi Boosters, I've just tried building the program_options library, using GCC 3.4.1 on FreeBSD 4.8 and hit a couple of compilation errors. One error is caused by the platform, one by the compiler's stdlib. The first problem is line 116 in libs/program_options/src/utf8_codecvt_facet.cpp gcc-C++-action bin/boost/libs/program_options/build/libboost_program_options.a/gcc/debug/utf8_codecvt_facet.o /data/development/jw/src/extcvs/boost/libs/program_options/build/../src/utf8_codecvt_facet.cpp: In member function `virtual std::codecvt_base::result boost::program_options::detail::utf8_codecvt_facet_wchar_t::do_out(mbstate_t&, const wchar_t*, const wchar_t*, const wchar_t*&, char*, char*, char*&) const': /data/development/jw/src/extcvs/boost/libs/program_options/build/../src/utf8_codecvt_facet.cpp:116: error: `WCHAR_MAX' undeclared (first use this function) /data/development/jw/src/extcvs/boost/libs/program_options/build/../src/utf8_codecvt_facet.cpp:116: error: (Each undeclared identifier is reported only once for each function it appears in.) WCHAR_MAX is not defined by FreeBSD's wchar.h. Can boost::numeric_limits<wchar_t> be used instead? The second problem is visible because I built GCC with concept-checks enabled, which means the STL containers use a version of Boost's concept checks. This reveals that boost/program_options/options_description.hpp uses an incomplete type on line 232: gcc-C++-action bin/boost/libs/program_options/build/libboost_program_options.a/gcc/debug/options_description.o In file included from /data/development/jw/src/extcvs/boost/libs/program_options/build/../src/options_description.cpp:9: /data/development/jw/gcc/3.4/bin/../lib/gcc/i386-unknown-freebsd4.8/3.4.1/../../../../include/c++/3.4.1/bits/boost_concept_check.h: In instantiation of `__gnu_cxx::_SGIAssignableConcept<boost::program_options::options_description>': /data/development/jw/gcc/3.4/bin/../lib/gcc/i386-unknown-freebsd4.8/3.4.1/../../../../include/c++/3.4.1/bits/stl_vector.h:144: instantiated from `std::vector<boost::program_options::options_description, std::allocator<boost::program_options::options_description> >' /data/development/jw/src/extcvs/boost/boost/program_options/options_description.hpp:232: instantiated from here /data/development/jw/gcc/3.4/bin/../lib/gcc/i386-unknown-freebsd4.8/3.4.1/../../../../include/c++/3.4.1/bits/boost_concept_check.h:216: error: `__gnu_cxx::_SGIAssignableConcept<_Tp>::__a' has incomplete type /data/development/jw/src/extcvs/boost/boost/program_options/options_description.hpp:142: error: forward declaration of `class boost::program_options::options_description' This error can be reproduced by compiling with -D_GLIBCXX_CONCEPT_CHECKS, or -D_GLIBCXX_DEBUG. Both the concept-checks and debug mode will reject std::vector< incomplete type >. jon -- "Nothing is true. Everything is permissible." - Hassan i Sabbah

3 9

Latest Boost.Threads regression results on meta-como-win32-4.3.3-vc7
by Michael Glassford 22 Jul '04

22 Jul '04

The Boost.Threads regression results for meta-como-win32-4.3.3-vc7 at http://boost.sourceforge.net/regression-logs/developer/thread.html all fail because: <quote> "C:\Users\Administrator\boost\main\boost\boost/config/requires_threads.hpp", line 29: catastrophic error #35: #error directive: "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS" # error "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS" </quote> The reason BOOST_DISABLE_THREADS is defined is because -DBOOST_DISABLE_WIN32 being passed on the command line. Does anyone know whether this option is on the command line on purpose, or should I consider it a configuration error for that toolset? Mike

3 2

Re: [boost] Problems with program_options using GCC 3.4 on FreeBSD
by Robert Ramey 22 Jul '04

22 Jul '04

Jonathan Wakely wrote: >> Any chance we might convince you to run the whole test suite on the >> platform? I would be curious as to the results for the serialization >> library here. >Sure, but .. >I'm not able to compile it yet - more patches will be coming shortly. >The problems mostly stem from the fact that FreeBSD 4.x doesn't support >std::wstring, std::wstreambuf etc. >e.g. >libs/serialization/src/basic_text_wiprimitive.cpp should test >BOOST_NO_STD_WSTREAMBUF before using std::wistream >The wchar.h header is present, but incomplete, so GCC on FreeBSD doesn't >define the _GLIBCXX_USE_WCHAR_T macro, disabling all wchar_t support in >the C++ library. The serialization library is set up as two libraries. Serialization.lib and wserialization.lib. If there isn't proper support for wide chars, the later fails to build and the tests that depend upon fail to pass. This is what happens when I test gcc on cygwin. So the fact that there is no wide char support on a particular platform should be no problem as far as the serialization library is concerned. Of course in such environments wide char use has to be avoided. Robert Ramey

2 1

[1.32 release] Intel 8.0/Mingw regression results
by Aleksey Gurtovoy 22 Jul '04

22 Jul '04

Stefan Slapeta's Intel 8.0 and Rob Lievaart's Mingw/gcc 3.2.3 results are now available in the Boost-wide summary reports: http://www.boost.org/regression-logs/developer/summary.html -- Aleksey Gurtovoy MetaCommunications Engineering

4 4

RE: [boost] Re: Regression results
by Rob Lievaart 22 Jul '04

22 Jul '04

Hi Alekey, I am currently running your script, for tests with mingw (gcc 3.2.3) So you should see these results appearing as well, sometime today (machine is not that fast). I'll watch the output of the upload and if it fails I'll try the new script. After a quick glance at the bjam.log (still growing) I noticed that python was not setup correctly, so those tests are not run. I'll try to correct that for the next run. And in boost tests there is a problem with wcscmp not being declared in std, that causes a lot of tests to fail, but I thought I read on the list that a fix for that was submitted ?!? Well, lets see if the upload works. Kind regards, Rob Lievaart. -----Original Message----- From: Aleksey Gurtovoy [mailto:agurtovoy@meta-comm.com] Sent: 21 July, 2004 1:35 PM To: boost(a)lists.boost.org Subject: Re: [boost] Re: Regression results for Intel 8 online Stefan Slapeta writes: > The regressions are finished and should appear in the metacomm result > tables after the next update there. Stefan, It seems that the logs didn't get uploaded. Could you please run the attached 'regression.py' with the 'upload' command, e.g. python regression.py upload --runner=<your runner id> ?

2 1

Como --windows experiment failed
by Jeff Garland 22 Jul '04

22 Jul '04

Based on the regression report it looks like --windows isn't accepted: The core of it is Command-line error #571: invalid option: --windows 1 catastrophic error detected in this compilation. Compilation terminated. Details at: http://www.boost.org/regression-logs/output/metacomm-bin-boost-libs-date_ti… or http://tinyurl.com/45z6v Thanks guys -- you will need to back out the change when you get a chance. Looks like it's time to mark the dll case as failing for Comeau. Jeff

2 1

[Range] partial_workaround failure on Linux
by Jeff Garland 22 Jul '04

22 Jul '04

One of the few remaining failures on Mandrake is a range library failure that's been there for the better part of a week. Looks like it might be easy to solve... Jeff URL: http://boost.sourceforge.net/regression-logs/cs-LinuxMandrake-links.html#ra… or http://tinyurl.com/6xwh9 Small tease: range - workaround_test - gcc Compiler output: In file included from /boost_regression1/boost/boost/range/detail/common.hpp:23, from /boost_regression1/boost/boost/range/detail/iterator.hpp:14, from /boost_regression1/boost/boost/range/iterator.hpp:21, from ../libs/range/test/partial_workaround.cpp:13: /boost_regression1/boost/boost/mpl/if.hpp:141: error: namespace `algo_' undeclared /boost_regression1/boost/boost/mpl/if.hpp:143: error: `void_' was not declared in this scope /boost_regression1/boost/boost/mpl/if.hpp:143: error: `void_' was not declared in this scope ... set -e "g++" -c -Wall -ftemplate-depth-100 -g -O0 -fno-inline -I"../bin/boost/libs/range/test" -I "/home/jeff/devTools/boost_regression1/boost" -o "../bin/boost/libs/range/test/workaround_test.test/gcc/debug/partial_workaround.o" "../libs/range/test/partial_workaround.cpp" "/usr/bin/objcopy" --set-section-flags .debug_str=contents,debug "../bin/boost/libs/range/test/workaround_test.test/gcc/debug/partial_workaround.o"

2 1

Proposal for String Algorithms Library [CODE]
by zaufi＠sendmail.ru 22 Jul '04

22 Jul '04

---------- Forwarded Message ---------- Subject: Proposal for String Algorithms Library Date: Thursday 22 July 2004 09:43 From: zaufi(a)sendmail.ru To: boost(a)lists.boost.org hi boosters I would like to propose one more algorithm to SAL -- squeeze. It removes leading/trailing spaces and duplicate spaces between words. So sample string " This is \n\n a test \n" become "This is\na test". I use this function with XML/HTML related code to 'normalize' content... Hope this will help to smbd else ;) Have fun! ------------------------------------------------------- Oops. Forget to paste code... ;) <squeeze.cc> std::string squeeze(const std::string& str) { std::string out; // bool is_start_of_line = true; char last_space = 0; for (std::string::const_iterator i = str.begin(); i != str.end(); ++i) { if (std::isspace(*i)) last_space = int(!is_start_of_line) * (int(*i == '\n') * '\n' + int((*i != '\n') & (last_space != '\n')) * ' ' + int(last_space == '\n') * last_space); else { if (last_space) { out.push_back(last_space); last_space = 0; } out.push_back(*i); is_start_of_line = false; } } return out; } </squeeze.cc>

1 0

typeof: lvalue preserving
by Vertleyb 22 Jul '04

22 Jul '04

One more addition to the typeof library is a macro, that, unlike BOOST_TYPEOF(), which removes top-level consts and references, attempts to be closer to the decltype, by preserving lvalue-ness of its argument: BOOST_TYPEOF_PRESERVE_LVALUE(expr) I do admit that the name is quite clumzy :( It is directly based on the rules of binding a reference. The following table outlines which types are returned: Expression lvalue? typeof_preserve_lvalue(expression) ---------- ------- ------ int n; lvalue int& const int m; lvalue const int& int& rn = n; lvalue int& const int& rm; lvalue const int& int foo1(); int const int foo2(); const int& (unfortunately, in both VC7.1 and GCC 3.3) int& foo3(); lvalue int& const int& foo4(); lvalue const int& int(21) int 21 int The BOOST_AUTO remains based on the BOOST_TYPEOF. The references, in the same way as proposed in http://www.osl.iu.edu/~jajarvi/publications/papers/decltype_n1478.pdf, should be specified explicitly: int& foo(); BOOST_AUTO(v, foo()); // auto v = foo(); BOOST_AUTO(&r, foo()); // auto& r = foo(); BOOST_AUTO(const& cr, foo()); // auto const& cr = foo(); See http://groups.yahoo.com/group/boost/files/typeof.zip (or Spirit repository, TYPEOF_DEV branch). As always any comments are welcome. Thanks, Arkadiy

1 0

Tribool missing title in docs
by Jeff Garland 22 Jul '04

22 Jul '04

Doug -- Maybe you've already noticed, but the Tribool title isn't showing up in the generated docs table of contents... http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/libraries.h… Jeff

2 1

Re:Re: [boost] Regression Tests, Boost.Serialization
by Robert Ramey 22 Jul '04

22 Jul '04

Jeff Garland wrote: >> Houston, we have a problem. >> >> I had a few GB of disk space left a few days ago. >> Now, I'm unable to run all the tests. I could >> drop one of the gcc-3.4 versions. However, I'd >> still be short by ~10GB after that. It's a fact - running the bjam serialization test is going to consume 20 GB. If the test machine doesn't have it the best is just to remove the serialization test from the status jamfile for that machine. Actually I think it would be unusual for a machine used for testing boost not to have this much free space available. So I would hope it only affects martin's tests. >It would be nice if we could drop serialization on compilers that just >aren't going to work. Having looked at the test results on all the compilers the only ones that I really wonder about are HP, and for now Comeau. All tests run with MSVC 6.0 and borland will fail without spirit 1.61 being installed. This is because spirit 1.61 is needed to build the libraries. So if the library build fails then all the tests are skipped. They are marked "fail" which is a little misleading - "skipped" might be better. >This is where we were hoping to be able to allow regression levels like >'basic' and 'torture' that would provide standard ways of controlling the >number of tests. But none of this is currently available. All in all I think the testing program is working well and in reasonable time. I need this to shake out issues with each platform. It just takes the resources that it takes. So far I've only been through two test cycles so it's premature to panic. >As for what we should do now, it would be nice to have an answer to the >question I posed this morning: is serialization going into 1.32 or are we >cutting it out in the final release: I want to keep working to finish regardless of which release it becomes a part of. >If we are cutting it out the we can just remove it from status bjam now.... But that would mean that progress would be stopped on getting this done. Robert Ramey

7 8

RE: [boost] Re: Lock unification [move]
by Batov, Vladimir 22 Jul '04

22 Jul '04

Yes, I fully agree with your argument against >> basic_lock(mutex_type&, const elapsed_time&, defer_type); That suggestion was OTOH and clearly messy and bad. Although the point I tried to make was that the interface appeared somewhat inconsistent -- I can create a deferred blocking lock but not a deferred "try" lock. However, I now clearly see that I was thinking in terms of separate classes "scoped, try, timed". That is not true anymore. After thinking about it some more (I know, I should have done it from the start :-) ), I like the proposed interface. Essentially, scoped_lock(mutex_type& m, detail::defer_lock_type); is a constructor in its own right as (unlike the other three) it does not create a specific (blocking, try, timed) lock. The more I think about it, the more I like it. > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Howard Hinnant > Sent: Thursday, 22 July 2004 11:19 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: Lock unification [move] > > On Jul 21, 2004, at 7:16 PM, Batov, Vladimir wrote: > > > Howard, > > > > Thank you for taking on the task of shaping up the interface. That > > activity is of great importance. A few comments. > > > > explicit scoped_lock(mutex_type& m); > > scoped_lock(mutex_type& m, detail::defer_lock_type); > > scoped_lock(mutex_type& m, detail::try_lock_type); > > scoped_lock(mutex_type& m, const elapsed_time& elps_time); > > > > The problem (as I can see it) with the set above is that "deferred", > > "tried" and "timed" appear to be alternatives or mutually exclusive. > > However, "deferred" and, say, "try" functionalities are orthogonal. > > That > > is, as one might need to defer a blocking lock > > > > scoped_lock l(m, deferred); > > > > one might need a deferred try_lock as well. Therefore, as we are trying > > to provide one universal lock, it appears we have to have something > > complex like > > > > basic_lock(mutex_type&, const elapsed_time&, defer_type); > > > > that would address all the lock variability/configurability. > > I'm not seeing that the combination of time and defer always make sense: > > time defer description > --------------------------------------------------- > 0 yes interpret as don't lock > 0 no interpret as try-lock > finite yes no interpretation > finite no lock if you can get it in time > infinite yes no interpretation > infinite no interpret as lock > > Some of the combinations don't appear to have clear meanings. > > Even more importantly, the underlying mutex might not support time. > Below is a list of mutex functionality that I have so far identified in > the spec. Recursion is ignored for this discussion (it isn't relevant > to locks, and thus not relevant to mutex interface, only to mutex > implementation details): > > Mutex interface: > ---------------- > > void lock(); > void unlock(); > > bool try_lock(); > > bool timed_lock(const elapsed_time&); > > void lock_sharable(); > void unlock_sharable(); > > bool try_lock_sharable(); > > bool timed_lock_sharable(const elapsed_time&); > > void lock_upgradable(); > void unlock_upgradable(); > > bool try_lock_upgradable(); > > bool timed_lock_upgradable(const elapsed_time&); > > void unlock_and_lock_sharable(); > > void unlock_and_lock_upgradable(); > void unlock_upgradable_and_lock(); > > void try_unlock_upgradable_and_lock(); > > The spaces between signatures are relevant. They represent groupings > where I believe it is reasonable for a mutex to support a group of > signatures, but exclude other groups. For example, it is very > reasonable for a mutex to support lock and unlock but not try_lock. Or > perhaps lock, unlock and try_lock, but not timed_lock. If a lock > constructor forces the semantics of "deferred lock" to call > m_.timed_lock(elps_time), then a compile time error results if the > mutex does not support timed_lock(), even though timed_lock isn't > needed to support "deferred lock" (no mutex interface is required to > support deferred lock). So I'm very reluctant to have a lock function > that calls two mutex functions that can reasonably be expected to not > be implemented in the same mutex. > > -Howard > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

RE: [boost] Re: Boost.Test problem
by Rozental, Gennadiy 22 Jul '04

22 Jul '04

> > My personal preference is fully qualified reference > everywhere. And I > > don't see how other solution is any better. > > Whatever... Just fix the thing! That's great! First you say don't do a thing, than - why you did not do it yet. I had enough headache with things that were "sure thing". I did not touch anything I am not 100% sure about. Gennadiy.

2 1

RE: [boost] Re: Lock unification [move]
by Batov, Vladimir 22 Jul '04

22 Jul '04

I second that. > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of David Abrahams > Sent: Thursday, 22 July 2004 9:16 AM > To: boost > Subject: [boost] Re: Lock unification [move] > > Howard Hinnant <hinnant(a)twcny.rr.com> writes: > > > <nod> How's: > > > > scoped_lock lk1(m, defer_lock); // not locked > ^^^^ ^^^^ > > Redundant. "deferred" is better. > > -- > Dave Abrahams > Boost Consulting > http://www.boost-consulting.com > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Boost under QNX 6.2.1
by Dave Wolfe 21 Jul '04

21 Jul '04

I recently tried to d/l boost_1_31_0 and compile a short test program (appended below) on QNX 6.2.1. My first attempt to compile with: % make bindtest CPPFLAGS=-I/home/projects/boost_1_31_0 resulted in a yard+ of errors that I was able to quiet by adding '-ftemplate-depth-32' to CPPFLAGS. But I still got the error: g++ -I. -ftemplate-depth-32 bindtest.cpp -o bindtest /tmp/ccIdnnhy.o: In function `boost::bad_function_call::bad_function_call(void)': /tmp/ccIdnnhy.o(.boost::bad_function_call::gnu.linkonce.t.(void)+0x29): undefined reference to `runtime_error::runtime_error(basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> > const &)' collect2: ld returned 1 exit status make: *** [bindtest] Error 1 After quite a lot of mucking about, I discovered that I had to define CXX to 'QCC' and comment out the following line in boost/config/compiler/gcc.hpp: #ifndef __EXCEPTIONS //# define BOOST_NO_EXCEPTIONS #endif in order to compile successfully. So the appended test program works, at least. However, the complete boost tarball seems to have some problems. When I run bjam, the compiler keeps carping: g++: unrecognized option '-pthread' And there seem to be quite a few files with a basename longer than the QNX max of 48 charactes. I'm willing to help figure out how to get boost to compile better under QNX if someone can give me a little guidance as to how to proceed. Part of the problem may be that QNX 6.2.1 uses an STL implementation from Dinkum instead of the one that comes with gcc 2.95.3. If someone'll help direct my fingers where to go, I can probably sort some of this out... Cheers, - Dave P.S. If it's helpful to anyone, I can post a QNX 6.2.1 binary of bjam... -------- % uname -a QNX rtblnx1196 6.2.1 2003/01/18-02:12:22est x86pc x86 % gcc --version 2.95.3qnx-nto -------- // File: bindtest.cpp // Compile: make bindtest CXX=QCC CPPFLAGS="-I. -ftemplate-depth-32" #include <iostream> #include <string> #include <boost/bind.hpp> #include <boost/ref.hpp> #include <boost/function.hpp> using namespace std; typedef boost::function<void(void)> Callback; struct Dummy { void memberFunc( int num, const string& msg ) { cout << "memberFunc args: " << num << ", \"" << msg << "\"" << endl; } }; main( void ) { Dummy mydummy; Callback c = boost::bind( &Dummy::memberFunc, boost::ref(mydummy), 7, "is a lucky number..." ); c( ); // prints: "memberFunc args: 7, "is a lucky number..." return 0; }

1 0

counting_iterator_test.hpp fails on aC++
by DY, JERRY U (SBCSI) 21 Jul '04

21 Jul '04

I'm troubleshooting counting_iterator_test.hpp. In particular: FILE: counting_iterator_test.cpp class my_int2 { public: ... typedef std::bidirectional_iterator_tag iterator_category; }; FILE: counting_iterator.hpp template <class Incrementable, class CategoryOrTraversal, class Difference> struct counting_iterator_base { typedef typename detail::ia_dflt_help< CategoryOrTraversal , mpl::apply_if< is_numeric<Incrementable> , mpl::identity<random_access_traversal_tag> , iterator_traversal<Incrementable> > >::type traversal; ... } The class my_int2 is passed as parameter "Incrementable" to counting_iterator_base, but is failing the is_numeric test so my_int2 is just a bidirectional iterator (see mpl::apply_if above). If it passes the is_numeric test, then it's a random access traversal tag. The way it passes the is_numeric test is to specialize std::numeric_limits like so: template <> class std::numeric_limits<my_int2> { public: static bool const is_specialized = false; }; But I don't find that in the source. It appears that aC++ doing the right thing, but I know I'm wrong. Could somebody please help?? Thanks! -Jerry

1 0

RE: [boost] Re: Regression results for Intel 8 online
by Michael Stevens 21 Jul '04

21 Jul '04

Stefan thanks for you work and the reply On Wednesday 21 July 2004 10:15, "Stefan Slapeta" <stefan(a)slapeta.com> wrote: > Did you see the __declspec(dllimport)? Should this be ok? > > test21.obj : error LNK2019: unresolved external symbol > "__declspec(dllimport) public: __thiscall > std::complex<float>::complex<float>(class std::complex<float> const &)" etc. > > test21.obj : error LNK2019: unresolved external symbol I saw it but don't really know what to make of it! Essentially uBLAS just makes use of the system <complex> header. How this result in an unresolved symbol I don't know. My wild guess the they are normally for it the compiler runtime, and something has gone haywire! > "C:\Programme\Intel\CPP\Compiler80\Ia32\bin\icl" /Zm800 -nologo -GX -c > -DBOOST_UBLAS_USE_INTERVAL /Z7 /Od /Ob0 /GX /GR /MDd /Op /Zc:forScope > /Zc:wchar_t /Qwn5 /Qwd985 -Qoption,c,--arg_dep_lookup /Qansi_alias > -D_NATIVE_WCHAR_T_DEFINED /Qvc7.1 I am really guessing here as I don't have manuals! The /Z7 and /Qv7.1 look interesting. I think the /Z7 is specifying old style debug symbols which is a bit odd. I guess they are usually smaller then the "edit and continue" symbols. /Qv7.1 I assume is enabling VC 7.1 compatibility bugs and all. I guess this adds a few extra bugs of Intels own. I not sure why the default build options for boost have this in. Anyone know? Do you think it would be appropriate to do the regression testing in the compilers native mode? Thanks, Michael

2 1

RE: [boost] Re: What is it with boost and tinyurl?
by Rozental, Gennadiy 21 Jul '04

21 Jul '04

> > Too much trouble. I certainly wouldn't want to set that policy; it > > would just discourage posting links. > > Too much trouble? An extra Ctrl+V is too much trouble for > someone who doesn't mind opening tinyurl.com, pasting the > link there, copying the result, and pasting it back? Actually it's only one click http://tinyurl.com/#toolbar Gennadiy.

1 0

RE: Boost.Test problems (Was: [boost] Multiple link definitions o n Darwin tests)
by Rozental, Gennadiy 21 Jul '04

21 Jul '04

>A change to Boost.Test basically means all > tests will have to be recompiled on the testing machines. > This means test results will be available at a lower > frequency. A higher frequency is very desirable during the > release preparations. I did 1(one) update during this release preparation. It included mainly only license text update. I don't believe Boost.Test modification interfere with frequency of regression test run. Gennadiy.

1 0

RE: Boost.Test problems (Was: [boost] Multiple link definitions o n Darwintests)
by Rozental, Gennadiy 21 Jul '04

21 Jul '04

> Thank you Peter. After the release, I'll definitely move > Spirit to use this simple, no frills, test utility. The > requirements for such a facility should be 1) Works 100% on > *ALL* compilers 2) Is transparent and does not get in the way > (you can pretend it's not there at all) 3) Is 100% stable (no > frequent API changes) > 4) Is as simple as possible (less chance for Murphy's law to > kick in). IMO, Boost.Test does not satisfactorily satisfy > these requirements. Boost.Test minimal testing facility practically did not change since the day it was introduced (maybe only licence test updates). Gennadiy.

1 0

Re:[boost] Problems with program_options using GCC 3.4 on FreeBSD
by Robert Ramey 21 Jul '04

21 Jul '04

Jonathan Wakely wrote: >I've just tried building the program_options library, using GCC 3.4.1 >on FreeBSD 4.8 and hit a couple of compilation errors. >One error is caused by the platform, one by the compiler's stdlib. Any chance we might convince you to run the whole test suite on the platform? I would be curious as to the results for the serialization library here. Robert Ramey

2 1

Re: Boost.Test problems (Was: [boost] Multiple link definitions on Darwintests)
by Robert Ramey 21 Jul '04

21 Jul '04

>Joel de Guzman wrote: >Peter Dimov wrote: >> Vladimir Prus wrote: >> >>>Of all Boost.Test functionality I use only 'test_main' and >>>BOOST_CHECK, and I'd be really gratefull if that subset just worked. >> >> #include <boost/detail/lightweight_test.hpp> >> >> int main() >> { >> int x = 0; >> >> BOOST_TEST( ++x == 1 ); >> BOOST_TEST( ++x == 1 ); >> >> return boost::report_errors(); >> } >From the very beginning I've been using: #include <boost/test> Int main(){ BOOST_CHECK(...); Return boost:success; } I've never had a problem and have been pleased as punch. Robert Ramey

1 0

Wow, lotsa updates last night
by Victor A. Wagner Jr. 21 Jul '04

21 Jul '04

The full log is in the usual place ( ftp://rudbek.com/pub/boost/status.log ) I attempted to "fix" the lower and upper ambiguous symbols by changing lower(value) to value.lower() and the same for upper(value), but that causes problems later in the compile when apparently some ublas things are being used. .....perhaps the solution will be to add the required methods lower()const and upper()const to the ublas system. at any rate, here are the "interesting" lines: File: status.log ...found 38391 targets... ...using 2 temp targets... ...updating 4251 targets... ...on 100th target... ...on 200th target... ...on 300th target... ...on 400th target... C:\Projects\boost\boost\numeric\interval\io.hpp(35) : error C2872: 'lower' : ambiguous symbol C:\Projects\boost\boost\numeric\interval\io.hpp(35) : error C2872: 'upper' : ambiguous symbol ...failed vc-C++ ..\bin\boost\libs\numeric\ublas\test7.test\vc7.1\debug\test71.obj... C:\Projects\boost\boost\numeric\interval\io.hpp(35) : error C2872: 'lower' : ambiguous symbol C:\Projects\boost\boost\numeric\interval\io.hpp(35) : error C2872: 'upper' : ambiguous symbol ...failed vc-C++ ..\bin\boost\libs\numeric\ublas\test7.test\vc7.1\debug\test72.obj... ...skipped <@boost!libs!numeric!ublas\test7.test\vc7.1\debug>test7.CMD for lack of <@boost!libs!numeric!ublas\test7.test\vc7.1\debug>test71.obj... ...skipped <@boost!libs!numeric!ublas\test7.test\vc7.1\debug>test7.exe for lack of <@boost!libs!numeric!ublas\test7.test\vc7.1\debug>test7.CMD... ...on 500th target... ...on 600th target... ...on 700th target... ...on 800th target... ...on 900th target... ...on 1000th target... ...on 1100th target... ...on 1200th target... ...on 1300th target... ...on 1400th target... ...on 1500th target... ...on 1600th target... ...on 1700th target... ...on 1800th target... ...on 1900th target... ...on 2000th target... ...on 2100th target... ...on 2200th target... ...on 2300th target... ...on 2400th target... ..\libs\multi_array\test\fail_ref_cview3.cpp(54) : error C2166: l-value specifies const object ..\libs\multi_array\test\fail_ref_cview2.cpp(48) : error C2440: 'initializing' : cannot convert from 'boost::multi_array_ref<T,NumDims>::const_array_view<NDims>::type' to 'boost::detail::multi_array::multi_array_view<T,NumDims>' ..\libs\multi_array\test\fail_ref_cview.cpp(52) : error C2166: l-value specifies const object ..\libs\multi_array\test\fail_ref_csubarray3.cpp(49) : error C2166: l-value specifies const object ..\libs\multi_array\test\fail_ref_csubarray2.cpp(45) : error C2440: 'initializing' : cannot convert from 'boost::multi_array_ref<T,NumDims>::const_reference' to 'boost::detail::multi_array::sub_array<T,NumDims>' ..\libs\multi_array\test\fail_ref_csubarray.cpp(45) : error C2440: 'initializing' : cannot convert from 'boost::detail::multi_array::multi_array_impl_base<T,NumDims>::const_subarray<NDims>::type' to 'boost::detail::multi_array::sub_array<T,NumDims>' ..\libs\multi_array\test\fail_ref_criterator.cpp(30) : error C2440: 'initializing' : cannot convert from 'boost::reverse_iterator<Iterator>' to 'boost::reverse_iterator<Iterator>' ..\libs\multi_array\test\fail_ref_cparen.cpp(41) : error C2166: l-value specifies const object ..\libs\multi_array\test\fail_ref_citerator.cpp(30) : error C2440: 'initializing' : cannot convert from 'boost::detail::multi_array::array_iterator<T,TPtr,NumDims,Reference>' to 'boost::detail::multi_array::array_iterator<T,TPtr,NumDims,Reference>' ..\libs\multi_array\test\fail_ref_cdata.cpp(38) : error C2166: l-value specifies const object ..\libs\multi_array\test\fail_ref_cbracket.cpp(41) : error C2166: l-value specifies const object ..\libs\multi_array\test\fail_cview3.cpp(56) : error C2166: l-value specifies const object ..\libs\multi_array\test\fail_cview2.cpp(52) : error C2440: 'initializing' : cannot convert from 'boost::multi_array_ref<T,NumDims>::const_array_view<NDims>::type' to 'boost::detail::multi_array::multi_array_view<T,NumDims>' ..\libs\multi_array\test\fail_cview.cpp(55) : error C2166: l-value specifies const object ..\libs\multi_array\test\fail_csubarray3.cpp(46) : error C2166: l-value specifies const object ..\libs\multi_array\test\fail_csubarray2.cpp(42) : error C2440: 'initializing' : cannot convert from 'boost::multi_array_ref<T,NumDims>::const_reference' to 'boost::detail::multi_array::sub_array<T,NumDims>' ..\libs\multi_array\test\fail_csubarray.cpp(43) : error C2440: 'initializing' : cannot convert from 'boost::detail::multi_array::multi_array_impl_base<T,NumDims>::const_subarray<NDims>::type' to 'boost::detail::multi_array::sub_array<T,NumDims>' ..\libs\multi_array\test\fail_criterator.cpp(30) : error C2440: 'initializing' : cannot convert from 'boost::reverse_iterator<Iterator>' to 'boost::reverse_iterator<Iterator>' ..\libs\multi_array\test\fail_cparen.cpp(41) : error C2166: l-value specifies const object ..\libs\multi_array\test\fail_citerator.cpp(30) : error C2440: 'initializing' : cannot convert from 'boost::detail::multi_array::array_iterator<T,TPtr,NumDims,Reference>' to 'boost::detail::multi_array::array_iterator<T,TPtr,NumDims,Reference>' ..\libs\multi_array\test\fail_cdata.cpp(39) : error C2166: l-value specifies const object ..\libs\multi_array\test\fail_cbracket.cpp(37) : error C2166: l-value specifies const object C:\Projects\boost\boost\archive\detail\iserializer.hpp(215) : error C2027: use of undefined type 'boost::STATIC_ASSERTION_FAILURE<x>' ...on 2500th target... ..\libs\spirit\test\fixed_size_queue_fail_tests.cpp(57) : error C2784: 'bool std::operator ==(const std::allocator<_Ty> &,const std::allocator<_Other> &)' : could not deduce template argument for 'const std::allocator<_Ty> &' from 'void' ..\libs\spirit\test\fixed_size_queue_fail_tests.cpp(57) : error C2784: 'detail::enable_if_interoperable<Derived1,Derived2,mpl::apply2<boost::detail::always_bool2,Derived1,Derived2>::type>::type boost::operator ==(const boost::iterator_facade<Derived1,V1,TC1,R1,D1> &,const boost::iterator_facade<Derived2,V2,TC2,R2,D2> &)' : could not deduce template argument for 'const boost::iterator_facade<Derived,Value,CategoryOrTraversal,Reference,Difference> &' from 'void' ..\libs\spirit\test\fixed_size_queue_fail_tests.cpp(57) : error C2784: 'bool std::operator ==(const std::istream_iterator<_Ty,_Elem,_Traits,_Diff> &,const std::istream_iterator<_Ty,_Elem,_Traits,_Diff> &)' : could not deduce template argument for 'const std::istream_iterator<_Ty,_Elem,_Traits,_Diff> &' from 'void' ..\libs\spirit\test\fixed_size_queue_fail_tests.cpp(57) : error C2784: 'bool std::operator ==(const std::istreambuf_iterator<_Elem,_Traits> &,const std::istreambuf_iterator<_Elem,_Traits> &)' : could not deduce template argument for 'const std::istreambuf_iterator<_Elem,_Traits> &' from 'void' ..\libs\spirit\test\fixed_size_queue_fail_tests.cpp(57) : error C2784: 'bool std::operator ==(const std::reverse_iterator<_RanIt> &,const std::reverse_iterator<_RanIt> &)' : could not deduce template argument for 'const std::reverse_iterator<_RanIt> &' from 'void' ..\libs\spirit\test\fixed_size_queue_fail_tests.cpp(57) : error C2784: 'bool std::operator ==(const std::pair<_Ty1,_Ty2> &,const std::pair<_Ty1,_Ty2> &)' : could not deduce template argument for 'const std::pair<_Ty1,_Ty2> &' from 'void' ..\libs\spirit\test\fixed_size_queue_fail_tests.cpp(57) : error C2677: binary '==' : no global operator found which takes type 'iter_t' (or there is no acceptable conversion) ..\libs\spirit\test\fixed_size_queue_fail_tests.cpp(58) : error C2186: '+' : illegal operand of type 'void' ..\libs\spirit\test\fixed_size_queue_fail_tests.cpp(59) : error C2784: 'detail::enable_if_interoperable<Derived1,Derived2,mpl::apply2<boost::detail::always_bool2,Derived1,Derived2>::type>::type boost::operator <(const boost::iterator_facade<Derived1,V1,TC1,R1,D1> &,const boost::iterator_facade<Derived2,V2,TC2,R2,D2> &)' : could not deduce template argument for 'const boost::iterator_facade<Derived,Value,CategoryOrTraversal,Reference,Difference> &' from 'void' ..\libs\spirit\test\fixed_size_queue_fail_tests.cpp(59) : error C2784: 'bool std::operator <(const std::reverse_iterator<_RanIt> &,const std::reverse_iterator<_RanIt> &)' : could not deduce template argument for 'const std::reverse_iterator<_RanIt> &' from 'void' ..\libs\spirit\test\fixed_size_queue_fail_tests.cpp(59) : error C2784: 'bool std::operator <(const std::pair<_Ty1,_Ty2> &,const std::pair<_Ty1,_Ty2> &)' : could not deduce template argument for 'const std::pair<_Ty1,_Ty2> &' from 'void' ..\libs\spirit\test\fixed_size_queue_fail_tests.cpp(59) : error C2677: binary '<' : no global operator found which takes type 'boost::spirit::impl::fsq_iterator<QueueT,T,PointerT>' (or there is no acceptable conversion) ...on 2600th target... FAIL :: Get time of day micro second clock not supported due to inadequate compiler ...failed execute-test ..\bin\boost\libs\date_time\test\testmicrosec_time_clock.test\vc7.1\debug\testmicrosec_time_clock.run... ...on 2700th target... ...on 2800th target... ...on 2900th target... ...skipped <@boost!libs!numeric!ublas\test7.test\vc7.1\debug>test7.run for lack of <@boost!libs!numeric!ublas\test7.test\vc7.1\debug>test7.exe... ...on 3000th target... ...on 3100th target... ...on 3200th target... ...on 3300th target... ...on 3400th target... ...on 3500th target... ...on 3600th target... ...on 3700th target... ...on 3800th target... ...on 3900th target... ...on 4000th target... ...on 4100th target... **** error return code: -1 ...failed RmTemps ..\bin\boost\libs\test\test\prg_exec_fail4.test\vc7.1\debug\prg_exec_fail4.run... ...failed RmTemps ..\bin\boost\libs\test\test\prg_exec_fail3.test\vc7.1\debug\prg_exec_fail3.run... ...failed RmTemps ..\bin\boost\libs\test\test\prg_exec_fail2.test\vc7.1\debug\prg_exec_fail2.run... **** exception(205): C string: Test error by throwing C-style string exception ...failed RmTemps ..\bin\boost\libs\test\test\prg_exec_fail1.test\vc7.1\debug\prg_exec_fail1.run... ../libs/test/test/test_exec_fail4.cpp(22): error in "call_test_main": Msg Exception in "call_test_main": C string: Test error by throwing C-style string exception ...failed RmTemps ..\bin\boost\libs\test\test\test_exec_fail4.test\vc7.1\debug\test_exec_fail4.run... ../libs/test/test/test_exec_fail3.cpp(23): error in "call_test_main": test v == 2 failed ../libs/test/test/test_exec_fail3.cpp(24): error in "call_test_main": test 2 == v failed ...failed RmTemps ..\bin\boost\libs\test\test\test_exec_fail3.test\vc7.1\debug\test_exec_fail3.run... ../libs/test/test/test_exec_fail2.cpp(25): error in "call_test_main": test v == 2 failed ../libs/test/test/test_exec_fail2.cpp(26): error in "call_test_main": sample BOOST_ERROR call ../libs/test/test/test_exec_fail2.cpp(27): fatal error in "call_test_main": test 2 == v failed ...failed RmTemps ..\bin\boost\libs\test\test\test_exec_fail2.test\vc7.1\debug\test_exec_fail2.run... C:/Projects/boost/libs/test/build/../src/test_main.cpp(40): error in "call_test_main": test test_main_result == 0 || test_main_result == boost::exit_success failed ...failed RmTemps ..\bin\boost\libs\test\test\test_exec_fail1.test\vc7.1\debug\test_exec_fail1.run... ../libs/test/test/ifstream_line_iterator_test.cpp(28): error in "test_default_delimeter": test it != utf::ifstream_line_iterator() failed ../libs/test/test/ifstream_line_iterator_test.cpp(30): error in "test_default_delimeter": test *it == "acv ffg" failed [ != acv ffg] ../libs/test/test/ifstream_line_iterator_test.cpp(36): error in "test_default_delimeter": test *it == " " failed [ != ] ../libs/test/test/ifstream_line_iterator_test.cpp(39): error in "test_default_delimeter": test *it == "1" failed [ != 1] ../libs/test/test/ifstream_line_iterator_test.cpp(51): error in "test_custom_delimeter": test it != utf::ifstream_line_iterator() failed ../libs/test/test/ifstream_line_iterator_test.cpp(53): error in "test_custom_delimeter": test *it == "{ abc d " failed [ != { abc d ] ../libs/test/test/ifstream_line_iterator_test.cpp(56): error in "test_custom_delimeter": test *it == "\n{ d \n dsfg\n" failed [ != ../libs/test/test/ifstream_line_iterator_test.cpp(59): error in "test_custom_delimeter": test *it == "\n" failed [ != ...failed execute-test ..\bin\boost\libs\test\test\ifstream_line_iterator_test.test\vc7.1\debug\ifstream_line_iterator_test.run... ...on 4200th target... ..\libs\test\test\minimal_test.cpp(66): Some error in function: 'int __cdecl test_main(int,char *[])' ...failed RmTemps ..\bin\boost\libs\test\test\minimal_test.test\vc7.1\debug\minimal_test.run... ...failed updating 13 targets... ...skipped 24 targets... ...updated 4214 targets... Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

Regression results for Intel 8 online
by Stefan Slapeta 21 Jul '04

21 Jul '04

I've put them here: http://genericprogramming.com/boost Failures: - ublas (2) - test (_many_)!! - thread/test_read_write_mutex like on other compilers - random(2) - date_time/testmicrosec_time_clock -> should be expected??? Furthermore some in range and serialization. Spirit is missing somehow; were the tests not included when the source was moved to boost CVS? Stefan

9 14

Latest read_write_mutex regression results
by Michael Glassford 21 Jul '04

21 Jul '04

The latest regression results for test_read_write_mutex at http://boost.sourceforge.net/regression-logs/cs-Linux/developer/thread.html report a number of different errors on different compilers, the most common being <quote> Assertion failed: valid_read_lock(m_state), file C:\Users\administrator\main\boost\libs\thread\build\..\src\read_write_mutex.cpp, line 218 </quote> This indicates to me that these regression tests were run without the changes I checked in yesterday afternoon. Is this just because it takes so long to run regression tests that I have to wait for the next run to find out how my changes worked, or is there another reason? Also, the only reason I can tell that the regression tests were run without recent changes is because the changes were significant enough that the assertion in question is no longer anywhere near line 218. Is there any possibility at some point in the future of adding information to the regression log indicating what version of each source file was used to run the tests? I realize that this information isn't directly available to the regression testing tools, but perhaps the build process could be modified to record the cvs version information for each source file it uses (not sure how it would get it) whenever it builds anything, and the information could be incorporated into the regression reports? Mike

2 1

Re:Re: [boost] Serialization and tmpnam
by Robert Ramey 21 Jul '04

21 Jul '04

>> [1] As does the manpage say: "Never use this function". >Depending on the version, you may even see a more helpful message in the >manpage. >BUGS > Never use this function. Use mkstemp(3) instead. Well, not helpful enough. Making a stream from a file descriptor is code I don't have. Robert Ramey.

6 12

Linux regression results are stale?
by Vladimir Prus 21 Jul '04

21 Jul '04

There's something wrong with http://boost.sourceforge.net/regression-logs/cs-Linux.html That page shows 06:48:12 UTC, Wednesday 21 as timestamp, and there are no failures with algorithm/string on gcc 3.4. But http://boost.sourceforge.net/regression-logs/cs-Linux/developer/ has timestamp of Tue, 20 Jul 2004 18:22:30, and there are some fails in the same library on the same compiler. - Volodya

2 1

[Boost-bugs] [ boost-Bugs-995270 ] perfomance: memory cleanup for pool takes too long
by SourceForge.net 21 Jul '04

21 Jul '04

Bugs item #995270, was opened at 2004-07-21 07:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=995270&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: perfomance: memory cleanup for pool takes too long Initial Comment: hi, In my project I use boost::pool because I have to instantiate millions of object at the beginning of the application, and only get rid of the at termination time. I noticed that when processing large data (which may require 1Gb memory for the application while it is running) the application may finish its processing approx after 10 seconds. the cleanup part (which consists only of calling the pool release methods on allocated objects) on the other hand, takes many minutes (I usually give up after 5 minutes) debugging the code i noticed that the while loop in the nextof function (of SIMPLE SEGREGATED STORAGE.HPP) takes many iterations. this leads me to the belief that the reason the cleanup takes too long is because trying to cleanup 1GB memory of million of objects at once causes pool to retain all its chunks in the hope of more allocations in the future which in turns causes it to waste all computation on running to the end of (endless) lists in the nextof function I will appreciate a suggestion on how to fix this until a more permanent solution is applied to the pool library thanks aviad aviadr(a)pob.huji.ac.il ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=995270&group_i… ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[assign] comitted some fixes for array test (this is a call to Thorsten)
by Joaquín Mª López Muñoz 21 Jul '04

21 Jul '04

I've just commited a couple of trivial fixes so that the test assign does now work for toolset msvc (and possibly for msvc-stlport and intel- win32-7.1-vc6, too.) Thorsten, are you there? I'm afraid he's on vacation or something. If he does not appear and nobody complains, I'll try to clear out more problems in the Assignment Library next Monday. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

[assign] CW8 failure...
by Rene Rivera 21 Jul '04

21 Jul '04

At least one problem can be fixed on this library... It uses std::slist instead of looking for slist in the extensions namespace: =================================================================== RCS file: /cvsroot/boost/boost/boost/assign/std/slist.hpp,v retrieving revision 1.1 diff -u -r1.1 slist.hpp --- slist.hpp 29 Jun 2004 01:16:50 -0000 1.1 +++ slist.hpp 18 Jul 2004 13:13:03 -0000 @@ -28,8 +28,8 @@ { template< class V, class A, class V2 > - inline list_inserter< assign_detail::call_push_back< std::slist<V,A> >, V > - operator+=( std::slist<V,A>& c, V2 v ) + inline list_inserter< assign_detail::call_push_back< BOOST_STD_EXTENSION_NAMESPACE::slist<V,A> >, V > + operator+=( BOOST_STD_EXTENSION_NAMESPACE::slist<V,A>& c, V2 v ) { return push_back( c )( v ); } =================================================================== OK to commit? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

2 2

re: Boost.Random patch for gcc-3.4.1
by Michael Stevens 21 Jul '04

21 Jul '04

On Tuesday 13 July 2004 09:17, Synge Todo <wistaria(a)comp-phys.org> wrote: > I'm sending a small patch for Boost.Random to compile by using > gcc-3.4.1 (on Linux Fedora Core 2). > Could somebody apply this patch? Thank you in advance. The patches add #include<cmath> to a couple of the Random headers. This is I assume to provide std::pow definitions for builtin types. In this situation this is wrong. The Random headers are totally generic and can be used on a variety of numeric types. Not necessarily the builtin float etc. It is the user's responsibility to make sure that a 'pow' is defined for the specific type used. Random will find such definition in namespace std or with type dependant (Konig) lookup. This is hard on the user, but make the code generic and with the minmum of dependencies. Michael

4 5

[program_options] Need help with remaining fails
by Vladimir Prus 21 Jul '04

21 Jul '04

The current test results: http://tinyurl.com/4ghk7 show just three failures which I'd like to fix other than by marking them expected. Those are options_description_test_dll, on msvc and intel7-vc6, and variable_map_test_dll, on intel7-vc6. They all fail at runtime with memory access violation. Since I don't have vc6, I'd appreciate if someone could look at the failures in a debugger. This is probably some bug in vc6 library, so I hope a single fix will suffice. Thanks in advance, Volodya

4 6

[serialization] 100% pass in latest Mandrake test
by Jeff Garland 21 Jul '04

21 Jul '04

Robert - Things are looking good in my latest round of regression tests, all tests pass, down to a few warnings. Nice work! http://boost.sourceforge.net/regression-logs/cs-LinuxMandrake.html I even included the date_time serialization tests (exercises the code that serializes dates, times, durations, etc) in this run :-) Jeff

1 0

More errors today than yesterday
by Victor A. Wagner Jr. 21 Jul '04

21 Jul '04

This morning's grepped output (full log at ftp://rudbek.com/pub/boost ): ...found 35276 targets... ...using 215 temp targets... ...updating 2890 targets... ...on 100th target... ...on 200th target... ...on 300th target... ...on 400th target... C:\Projects\boost\boost\numeric\interval\io.hpp(35) : error C2872: 'lower' : ambiguous symbol C:\Projects\boost\boost\numeric\interval\io.hpp(35) : error C2872: 'upper' : ambiguous symbol ...failed vc-C++ ..\bin\boost\libs\numeric\ublas\test7.test\vc7.1\debug\test71.obj... C:\Projects\boost\boost\numeric\interval\io.hpp(35) : error C2872: 'lower' : ambiguous symbol C:\Projects\boost\boost\numeric\interval\io.hpp(35) : error C2872: 'upper' : ambiguous symbol ...failed vc-C++ ..\bin\boost\libs\numeric\ublas\test7.test\vc7.1\debug\test72.obj... ...skipped <@boost!libs!numeric!ublas\test7.test\vc7.1\debug>test7.CMD for lack of <@boost!libs!numeric!ublas\test7.test\vc7.1\debug>test71.obj... ...skipped <@boost!libs!numeric!ublas\test7.test\vc7.1\debug>test7.exe for lack of <@boost!libs!numeric!ublas\test7.test\vc7.1\debug>test7.CMD... ...on 500th target... ...on 600th target... ...on 700th target... ...on 800th target... ...on 900th target... ...on 1000th target... ...on 1100th target... ...on 1200th target... ...on 1300th target... ..\libs\conversion\test\implicit_cast_fail.cpp(22) : error C2664: 'boost::implicit_cast' : cannot convert parameter 1 from 'const char [7]' to 'boost::mpl::identity<T>::type' ..\libs\conversion\test\implicit_cast_fail.cpp(22) : error C2512: 'foo' : no appropriate default constructor available C:\Projects\boost\boost\function\function_template.hpp(78) : error C2198: 'int (__cdecl *)(float)' : too few arguments for call through pointer-to-function C:\Projects\boost\libs\function\test\function_test_fail1.cpp(22) : error C2451: conditional expression of type 'void' is illegal C:\Projects\boost\libs\function\test\function_test_fail1.cpp(29) : fatal error C1004: unexpected end of file found ..\libs\multi_array\test\fail_ref_cview3.cpp(55) : error C2166: l-value specifies const object ..\libs\multi_array\test\fail_ref_cview2.cpp(49) : error C2440: 'initializing' : cannot convert from 'boost::multi_array_ref<T,NumDims>::const_array_view<NDims>::type' to 'boost::detail::multi_array::multi_array_view<T,NumDims>' ..\libs\multi_array\test\fail_ref_cview.cpp(53) : error C2166: l-value specifies const object ..\libs\multi_array\test\fail_ref_csubarray3.cpp(50) : error C2166: l-value specifies const object ..\libs\multi_array\test\fail_ref_csubarray2.cpp(46) : error C2440: 'initializing' : cannot convert from 'boost::multi_array_ref<T,NumDims>::const_reference' to 'boost::detail::multi_array::sub_array<T,NumDims>' ..\libs\multi_array\test\fail_ref_csubarray.cpp(46) : error C2440: 'initializing' : cannot convert from 'boost::detail::multi_array::multi_array_impl_base<T,NumDims>::const_subarray<NDims>::type' to 'boost::detail::multi_array::sub_array<T,NumDims>' ..\libs\multi_array\test\fail_ref_criterator.cpp(31) : error C2440: 'initializing' : cannot convert from 'boost::reverse_iterator<Iterator>' to 'boost::reverse_iterator<Iterator>' ..\libs\multi_array\test\fail_ref_cparen.cpp(42) : error C2166: l-value specifies const object ..\libs\multi_array\test\fail_ref_citerator.cpp(31) : error C2440: 'initializing' : cannot convert from 'boost::detail::multi_array::array_iterator<T,TPtr,NumDims,Reference>' to 'boost::detail::multi_array::array_iterator<T,TPtr,NumDims,Reference>' ...on 1400th target... ..\libs\multi_array\test\fail_ref_cdata.cpp(39) : error C2166: l-value specifies const object ..\libs\multi_array\test\fail_ref_cbracket.cpp(42) : error C2166: l-value specifies const object ..\libs\multi_array\test\fail_cview3.cpp(57) : error C2166: l-value specifies const object ..\libs\multi_array\test\fail_cview2.cpp(52) : error C2440: 'initializing' : cannot convert from 'boost::multi_array_ref<T,NumDims>::const_array_view<NDims>::type' to 'boost::detail::multi_array::multi_array_view<T,NumDims>' ..\libs\multi_array\test\fail_cview.cpp(56) : error C2166: l-value specifies const object ..\libs\multi_array\test\fail_csubarray3.cpp(47) : error C2166: l-value specifies const object ..\libs\multi_array\test\fail_csubarray2.cpp(43) : error C2440: 'initializing' : cannot convert from 'boost::multi_array_ref<T,NumDims>::const_reference' to 'boost::detail::multi_array::sub_array<T,NumDims>' ..\libs\multi_array\test\fail_csubarray.cpp(44) : error C2440: 'initializing' : cannot convert from 'boost::detail::multi_array::multi_array_impl_base<T,NumDims>::const_subarray<NDims>::type' to 'boost::detail::multi_array::sub_array<T,NumDims>' ..\libs\multi_array\test\fail_criterator.cpp(31) : error C2440: 'initializing' : cannot convert from 'boost::reverse_iterator<Iterator>' to 'boost::reverse_iterator<Iterator>' ..\libs\multi_array\test\fail_cparen.cpp(42) : error C2166: l-value specifies const object ..\libs\multi_array\test\fail_citerator.cpp(31) : error C2440: 'initializing' : cannot convert from 'boost::detail::multi_array::array_iterator<T,TPtr,NumDims,Reference>' to 'boost::detail::multi_array::array_iterator<T,TPtr,NumDims,Reference>' ..\libs\multi_array\test\fail_cdata.cpp(40) : error C2166: l-value specifies const object ..\libs\multi_array\test\fail_cbracket.cpp(38) : error C2166: l-value specifies const object C:\Projects\boost\boost\detail\typed_in_place_factory.hpp(50) : error C2440: 'initializing' : cannot convert from 'int' to 'const char [3]' C:\Projects\boost\boost\detail\typed_in_place_factory.hpp(50) : fatal error C1903: unable to recover from previous error(s); stopping compilation C:\Projects\boost\boost\detail\in_place_factory.hpp(51) : error C2661: 'A::A' : no overloaded function takes 3 arguments ..\libs\python\test\object_fail1.cpp(10) : error C2039: '_' : is not a member of 'boost::python::api::object' ...on 1500th target... FAIL :: Get time of day micro second clock not supported due to inadequate compiler ...failed execute-test ..\bin\boost\libs\date_time\test\testmicrosec_time_clock.test\vc7.1\debug\testmicrosec_time_clock.run... ...on 1600th target... ...on 1700th target... ...skipped <@boost!libs!numeric!ublas\test7.test\vc7.1\debug>test7.run for lack of <@boost!libs!numeric!ublas\test7.test\vc7.1\debug>test7.exe... ...on 1800th target... ...on 1900th target... ...on 2000th target... ...on 2100th target... ...on 2200th target... ...on 2300th target... ...on 2400th target... ...failed execute-test ..\bin\boost\libs\serialization\test\test_demo_xml_save.test\vc7.1\debug\test_demo_xml_save.run... ...failed execute-test ..\bin\boost\libs\serialization\test\test_demo_xml_load.test\vc7.1\debug\test_demo_xml_load.run... ...failed execute-test ..\bin\boost\libs\serialization\test\test_demo_xml.test\vc7.1\debug\test_demo_xml.run... ...failed execute-test ..\bin\boost\libs\serialization\test\test_demo_shared_ptr.test\vc7.1\debug\test_demo_shared_ptr.run... ...failed execute-test ..\bin\boost\libs\serialization\test\test_demo_exception.test\vc7.1\debug\test_demo_exception.run... ...failed execute-test ..\bin\boost\libs\serialization\test\test_demo.test\vc7.1\debug\test_demo.run... ...on 2500th target... ../libs/thread/test/test_read_write_mutex.cpp(205): error in "test_read_write_mutex": test r1.m_value == 10 failed ...failed execute-test ..\bin\boost\libs\thread\test\test_read_write_mutex.test\vc7.1\debug\threading-multi\test_read_write_mutex.run... ...on 2600th target... ...on 2700th target... ...on 2800th target... **** error return code: -1 ...failed RmTemps ..\bin\boost\libs\test\test\prg_exec_fail4.test\vc7.1\debug\prg_exec_fail4.run... ...failed RmTemps ..\bin\boost\libs\test\test\prg_exec_fail3.test\vc7.1\debug\prg_exec_fail3.run... ...failed RmTemps ..\bin\boost\libs\test\test\prg_exec_fail2.test\vc7.1\debug\prg_exec_fail2.run... **** exception(205): C string: Test error by throwing C-style string exception ...failed RmTemps ..\bin\boost\libs\test\test\prg_exec_fail1.test\vc7.1\debug\prg_exec_fail1.run... ../libs/test/test/test_exec_fail4.cpp(22): error in "call_test_main": Msg Exception in "call_test_main": C string: Test error by throwing C-style string exception ...failed RmTemps ..\bin\boost\libs\test\test\test_exec_fail4.test\vc7.1\debug\test_exec_fail4.run... ../libs/test/test/test_exec_fail3.cpp(23): error in "call_test_main": test v == 2 failed ../libs/test/test/test_exec_fail3.cpp(24): error in "call_test_main": test 2 == v failed ...failed RmTemps ..\bin\boost\libs\test\test\test_exec_fail3.test\vc7.1\debug\test_exec_fail3.run... ../libs/test/test/test_exec_fail2.cpp(25): error in "call_test_main": test v == 2 failed ../libs/test/test/test_exec_fail2.cpp(26): error in "call_test_main": sample BOOST_ERROR call ../libs/test/test/test_exec_fail2.cpp(27): fatal error in "call_test_main": test 2 == v failed ...failed RmTemps ..\bin\boost\libs\test\test\test_exec_fail2.test\vc7.1\debug\test_exec_fail2.run... C:/Projects/boost/libs/test/build/../src/test_main.cpp(40): error in "call_test_main": test test_main_result == 0 || test_main_result == boost::exit_success failed ...failed RmTemps ..\bin\boost\libs\test\test\test_exec_fail1.test\vc7.1\debug\test_exec_fail1.run... ../libs/test/test/ifstream_line_iterator_test.cpp(28): error in "test_default_delimeter": test it != utf::ifstream_line_iterator() failed ../libs/test/test/ifstream_line_iterator_test.cpp(30): error in "test_default_delimeter": test *it == "acv ffg" failed [ != acv ffg] ../libs/test/test/ifstream_line_iterator_test.cpp(36): error in "test_default_delimeter": test *it == " " failed [ != ] ../libs/test/test/ifstream_line_iterator_test.cpp(39): error in "test_default_delimeter": test *it == "1" failed [ != 1] ../libs/test/test/ifstream_line_iterator_test.cpp(51): error in "test_custom_delimeter": test it != utf::ifstream_line_iterator() failed ../libs/test/test/ifstream_line_iterator_test.cpp(53): error in "test_custom_delimeter": test *it == "{ abc d " failed [ != { abc d ] ../libs/test/test/ifstream_line_iterator_test.cpp(56): error in "test_custom_delimeter": test *it == "\n{ d \n dsfg\n" failed [ != ../libs/test/test/ifstream_line_iterator_test.cpp(59): error in "test_custom_delimeter": test *it == "\n" failed [ != ...failed execute-test ..\bin\boost\libs\test\test\ifstream_line_iterator_test.test\vc7.1\debug\ifstream_line_iterator_test.run... ..\libs\test\test\minimal_test.cpp(66): Some error in function: 'int __cdecl test_main(int,char *[])' ...failed RmTemps ..\bin\boost\libs\test\test\minimal_test.test\vc7.1\debug\minimal_test.run... ...failed updating 20 targets... ...skipped 31 targets... ...updated 2839 targets... Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

3 5

BOOST_CHECK_EQUAL: different behaviour on VC 7.1 and Intel
by Stefan Slapeta 21 Jul '04

21 Jul '04

This produces different results on VC 7.1 (fail) and Intel 8 (pass): char *p = "Hi!"; BOOST_CHECK_EQUAL(p, "Hi!"); Stefan

2 2

RE: [boost] Regression results for Intel 8 online
by Aleksey Gurtovoy 21 Jul '04

21 Jul '04

Stefan Slapeta writes: > I've put them here: http://genericprogramming.com/boost Stefan, this is very much appreciated! But these results are ought to be in the overall summary (http://boost.sourceforge.net/regression-logs/developer/summary.html) Could you give a shot to the new regression driver script which, among other things, would take care of it -- http://tinyurl.com/4f2zp? > > Spirit is missing somehow; were the tests not included when > the source was moved to boost CVS? No, that's the current default: Spirit test suite is not included into "boost/status/Jamfile". It appears in Win32 and Lunix tests because both sites path the "Jamfile" locally before running the tests. I think the original reasons for it long lost their merits, though. Same for the MPL. OK, fixed in the CVS. -- Aleksey Gurtovoy MetaCommunications Engineering

2 2

Re: Regression results for Intel 8 online
by Michael Stevens 21 Jul '04

21 Jul '04

On Tuesday 20 July 2004 14:04,Stefan Slapeta <stefan_nospam_(a)slapeta.com> Thanks Stefan for putting these up. With regard to uBLAS there appear to be two problems unique to Intel-8 (Windows). Neither occur on the Linux compiler version! The test2 fails with "unresolved external symbol" std::complex<float>::complex<float>(class std::complex<float> const &) Looks like the compiler has failed to instantiate this template or it is missing from the library! test7 are new tests that combine uBLAS with interval. Results are universally poor on all Windows compiler but in each case for different reasons! In this case the error suggests the windows compiler version is not finding a conversion that exits. Can you post the compiler options for these run. Maybe there are still VC compatibility options set which are introducing compiler bugs! Thanks, Michael

2 1

Multiple link definitions on Darwin tests
by Marshall Clow 21 Jul '04

21 Jul '04

Recently, many of the Darwin tests started failing. A bunch of them were the new serialization tests, and I've been working with Robert Ramey to figure out why and fix them. However, I have come to realize that a lot of the failing tests are not in the serialization library. Before I start debugging this myself, does anyone have any suggestions? For example, _all_ the program options tests are failing, with messages like: <http://boost.sourceforge.net/regression-logs/cs-Darwin-links.html#program_o…> >program_options - cmdline_test - darwin > >Linker output: > >ld: warning table of contents of library: >../bin/boost/libs/test/build/libboost_test_exec_monitor.a/darwin/debug/libboost_test_exec_monitor.a >not sorted slower link editing will result (use the ranlib(1) -s >option) >ld: multiple definitions of symbol >_ZN5boost9unit_test110_GLOBAL__N__ZGVZN5boost9unit_test9ut_detail11xml_printer13print_escapedERSoNS0_13basic_cstringIKcEEE9char_type22first_failed_assertionEv.eh >../bin/boost/libs/test/build/libboost_test_exec_monitor.a/darwin/debug/libboost_test_exec_monitor.a(unit_test_log.o) >definition of absolute >_ZN5boost9unit_test110_GLOBAL__N__ZGVZN5boost9unit_test9ut_detail11xml_printer13print_escapedERSoNS0_13basic_cstringIKcEEE9char_type22first_failed_assertionEv.eh >(value 0x0) >../bin/boost/libs/test/build/libboost_test_exec_monitor.a/darwin/debug/libboost_test_exec_monitor.a(supplied_log_formatters.o) >definition of absolute >_ZN5boost9unit_test110_GLOBAL__N__ZGVZN5boost9unit_test9ut_detail11xml_printer13print_escapedERSoNS0_13basic_cstringIKcEEE9char_type22first_failed_assertionEv.eh >(value 0x0) >ld: multiple definitions of symbol boost::unit_test::(anonymous >namespace)::first_failed_assertion() >../bin/boost/libs/test/build/libboost_test_exec_monitor.a/darwin/debug/libboost_test_exec_monitor.a(unit_test_log.o) >definition of boost::unit_test::(anonymous >namespace)::first_failed_assertion() in section (__TEXT,__text) >../bin/boost/libs/test/build/libboost_test_exec_monitor.a/darwin/debug/libboost_test_exec_monitor.a(supplied_log_formatters.o) >definition of boost::unit_test::(anonymous >namespace)::first_failed_assertion() in section (__TEXT,__text) >ld: warning table of contents of library: >../bin/boost/libs/test/build/libboost_test_exec_monitor.a/darwin/debug/libboost_test_exec_monitor.a >not sorted slower link editing will result (use the ranlib(1) -s >option) > > > export DYLD_LIBRARY_PATH > c++ -g -o >"../bin/boost/libs/program_options/test/cmdline_test.test/darwin/debug/cmdline_test" >"../bin/boost/libs/program_options/test/cmdline_test.test/darwin/debug/cmdline_test.o" >\ > \ > >-L"../bin/boost/libs/program_options/build/libboost_program_options.a/darwin/debug" >-L"../bin/boost/libs/test/build/libboost_test_exec_monitor.a/darwin/debug" >"../bin/boost/libs/program_options/build/libboost_program_options.a/darwin/debug/libboost_program_options-d-1_31.a" >"../bin/boost/libs/test/build/libboost_test_exec_monitor.a/darwin/debug/libboost_test_exec_monitor.a" >"../bin/boost/libs/program_options/build/libboost_program_options.a/darwin/debug/libboost_program_options-d-1_31.a" >"../bin/boost/libs/test/build/libboost_test_exec_monitor.a/darwin/debug/libboost_test_exec_monitor.a" >\ > -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

7 10

Re:Re: [boost] additional boost libraries?
by Robert Ramey 21 Jul '04

21 Jul '04

Vladimir Prus wrote: >> and, just out of curiosity: >> xml/html parsing >None so far. In fact, it seems unlikely that somebody will come along and >implement all the XML stack (DOM, XPath, XML Schema, XSTL, whatever) right >now. One chance would be is somebody boostify some existing XML toolkit -- >but which one? >Another chance is to initially create "tiny XML" library. In fact, both >regression tools and serialization have their own tiny XML parsers and >users aksed about XML support for program_options, so such library might >really be usefull. Note that the serialization library relies upon Spirit 100 % for XML parsing. The spirit package included a very complete example by Dan Nuffer for parsing XML. I copied that (along with a 50 line copyright notice !!!) and slimmed it down to my needs. I had to re-organize a little bit to handle botch char and wchar_t characters. And spirit is kind of abstract so it has a learning curve. Then just when I got "done" (the first time) it was announced that development of spirit was being forked - ARRRRGGGGHHH. Since the spirit developers have seen fit to maintain backward compatibility things have worked well. The code compiles on both spirit 1.6 - the "supported old version" as well Spirit 1.8 - so I'm pleased that the serialization package can be use spirit and still support older compilers without me having to write a yet another half-assed home brew xml parser. I suspect that Spirit is under-appreciated and maybe a little bit ahead of its time. It takes patience, It takes effort, it can sometimes drive you crazy, but using it can make your life better in the long run. I guess its sort of like being in love. Robert Ramey

4 4

Re:[boost] Re: Multiple files utf8_codecvt_facet.cpp
by Robert Ramey 21 Jul '04

21 Jul '04

>Tilman Kuepper >I'm jumping in, because I am interested in Unicode conversion facets... >> is there a reason why both program_options and serialization contain >> very similar files utf8_codecvt_facet.cpp? >I had a look at the serialization library's converter in >utf8_codecvt_facet.cpp >and noticed that utf8_codecvt_facet_wchar_t::do_in() doesn't check for >non-shortest UTF8-sequences. There might also be some issues on >platforms with 16-bit wchar_t (possible overflow). >I suggest using (parts of) the UTF library in the Boost files area to solve >those problems. This could also be another step towards an officially >supported Unicode library... ;-) >http://groups.yahoo.com/group/boost/files/utf/ We really, really need utf-8 facets to be part of boost. I've been pleased with Ron Garcia's that have been included in both the serialization and program options libraries. The only problems we've had is working through the fact that there is a lot of variation in which namespaces different libraries have put things. There were a couple of similar issues regarding function signatures as well. Ron's library also had a nice documentation page. All I had to do was write a test - even that was a hassle and its still not totally satisfactory - it gives bogus warnings. I've thought about Dave's suggestion about each of incorporating source code from a common spot. I was resolved to go along as I'm pleased to off load a stick but peripheral(to me) piece of code. Now I'm rethinking this and am not convinced that it's a good idea. I would like to a) make an "official" spot for it header/lib/ etc. b) move Ron's library into that spot. It's quite serviceable c) entertain "applications" for maintainers. Presumable it would be improved, and/or replaced with time. d) subject the next version to a review. This library has been looked at by various people and although several have offered ideas on how it can be improved - no one has found that it is lacking in the implementation as to what it does. And we need it now. Ron Garcia - Are you out there? Anything to add? Robert Ramey

4 3

RE: [boost] Re: Boost.Test problem
by Rozental, Gennadiy 20 Jul '04

20 Jul '04

> Anyway, the technique I suggested, which we use in Spirit, is > better than your trick of hoisting the names into namespace > std which is a hack that should be avoided if there are other ways. Why is it better? Let's compare: I. Hoisting the names into namespace std - require ifdef/endif + names are fully qualified, that prevent possible ambiguity/invalid function resolution (due to ADL for example) - does not allow to use ADL + located in one place + promote uniformity of access to the symbols in std namespace (particularly in a point on use, so I could see where this symbol came from) II. Use using declaration on function level + doesn't require ifdef/endif + allows ADL usage - unqualified name is a possible source of ambiguity/invalid function resolution - needs to be repeated in all functions that refer symbol - may stand out from the rest of std symbols, potentially leading to confusion/errors My personal preference is fully qualified reference everywhere. And I don't see how other solution is any better. > Regards, > -- > Joel de Guzman Regards, Gennadiy.

2 1

wrong order of test-suites in status/Jamfile
by JOAQUIN LOPEZ MU?Z 20 Jul '04

20 Jul '04

As per the policy of keeping the test-suites in alphabetical order, multi_array and multi_index appear in the wrong place --after numeric/ublas, when they should be following math. Anyone sees a problem with fixing this? I can commit the change tomorrow morning (CET time), if no one does it before. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[random] Building the random libraries
by Jody Hagins 20 Jul '04

20 Jul '04

Boost version 1.31.00, g++ 3.3, RedHat 9. When I build everything: # bjam -sTOOLS=gcc -builddir=./BUILD -stagedir=./STAGE stage I do not get the random library built. Worse, when I go to libs/random, there is no src directory and no build directory. Is there an easy way to get Boost.Random built like all the other boost libs? Thanks!

2 2

wrong order of test-suites in status/Jamfile [part 2]
by JOAQUIN LOPEZ MU?Z 20 Jul '04

20 Jul '04

Also, algorithm/minmax and numeric/conversion are misplaced. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

boost & STLport
by François Dumont 20 Jul '04

20 Jul '04

Hello boosters I am trying to build boost 1.31.0 with STLport 5.0 RC1 using MSVC 6 SP5. I already spend quite a long time on a very mysterious issue with no result, I hope you will be able to help me. When I build the boost libraries I have the following error messages: vc-C++ bin\boost\libs\filesystem\build\libboost_filesystem.lib\msvc-stlport\debug\s tlport-iostream-on\exception.obj exception.cpp C:\PROGRA~1\MICROS~4\VC98\include\objidl.h(9909) : error C2668: 'memset' : ambiguous call to overloaded function C:\PROGRA~1\MICROS~4\VC98\include\objbase.h(443) : error C2668: 'memcmp' : ambiguous call to overloaded function C:\PROGRA~1\MICROS~4\VC98\include\objbase.h(467) : error C2668: 'memcmp' : ambiguous call to overloaded function "cl" /Zm800 -nologo -GX -c -D_STLP_DO_IMPORT_CSTD_FUNCTIONS=1 -D_STLP_DEBUG=1 -D _STLP_DEBUG_UNINITIALIZED=1 /Z7 / Od /Ob0 /GX /GR /MDd -I"bin\boost\libs\filesystem\build" -I"C:\Utils\boost_1_31_0" -I"C:\ Utils\STLport-5.0.0\stlport" -I"C:\Utils\boost_1_31_0" -I"C:\PROGRA~1\MICROS~4\VC98\include" -Fo"bin\b oost\libs\filesystem\build\libboost_filesyst em.lib\msvc-stlport\debug\stlport-iostream-on\exception.obj" -Tp"C:\Utils\b oost_1_31_0\libs\filesystem\build\../src/exc eption.cpp" This only happen during boost build process with STLport 5.0. When I use both boost and STLport 5.0 in a simple test that call memset there is no ambiguity. Is there any special treatment within boost code for memset and memcmp? I also notice, looking at the command line, that STLport include path is not first. Is there a special reason not to have it first? If I want to test how can I make it first? Bests

1 0

[patch] minor docs clean up
by Jonathan Wakely 20 Jul '04

20 Jul '04

Hi all, The attached patch fixes several trivial spelling and markup errors, mostly in HTML files, that I came across while reading. It also updates the comment about DR 214 in libs/bind/bind.html, since that DR has been moved to WP status and is on the cwg_defects page, not cwg_active. Is it premature to say it's been "resolved" in the comment? Should the hostname for the defect list be changed to www.open-std.org as well? I assumed it should be. Affected files: libs/bind/bind.html libs/config/configure libs/date_time/doc/DesignGoals.html libs/date_time/xmldoc/date_time_autodoc.boostbook libs/date_time/xmldoc/design_goals.xml libs/filesystem/src/exception.cpp libs/program_options/doc/rationale.dox libs/regex/doc/match_flag_type.html libs/serialization/doc/archive_reference.html libs/serialization/doc/headers.html libs/serialization/doc/serialization.html libs/serialization/doc/traits.html libs/signals/doc/rationale.xml libs/test/src/supplied_log_formatters.cpp libs/test/src/test_tools.cpp I don't have write access, so if anyone cares whether these are fixed before the next release they'll have to commit them themselves. Jon T. Pedant P.S. while I'm being pedantic, has anyone else who owns a copy of the hardback ISO 14882 book, published by Wiley, noticed that one of the signatures* is bound upside down? * "Signature" meaning a bundle of paper folded together and bound to to other signatures to form a book. Have I got the right term? -- "Strange how potent cheap music is." - No�l Coward

2 1

Boost.test: minor fix
by Vladimir Prus 20 Jul '04

20 Jul '04

I've took the liberty of comitting the following change, which make "m_value" visible on compilers with two-phase lookup (like gcc 3.4) However, the token_iterator_test still fails to compile on 3.4 saying: token_iterator_test.cpp:47:38: converting to execution character set: Invalid or incomplete multibyte or wide character token_iterator_test.cpp:48:31: converting to execution character set: Invalid or incomplete multibyte or wide character token_iterator_test.cpp:48:42: converting to execution character set: Invalid argument token_iterator_test.cpp:48:49: converting to execution character set: Invalid argument token_iterator_test.cpp:48:55: converting to execution character set: Invalid or incomplete multibyte or wide character Looks like the text in L"" literals is not 7-bit, and that's why compiler errors out. Is it possible to change the test somehow? - Volodya Index: token_iterator.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/test/detail/iterator/token_iterator.hpp,v retrieving revision 1.3 diff -u -r1.3 token_iterator.hpp --- token_iterator.hpp 19 Jul 2004 12:29:57 -0000 1.3 +++ token_iterator.hpp 20 Jul 2004 12:45:47 -0000 @@ -309,7 +309,7 @@ typedef ut_detail::token_assigner<BOOST_DEDUCED_TYPENAME iterator_traversal<Iter>::type> Assigner; Iter checkpoint; - Assigner::clear( m_value ); + Assigner::clear( this->m_value ); if( !m_keep_empty_tokens ) { while( begin != end && m_is_dropped( *begin ) )

3 3

Re:[boost] Re: Serialization and tmpnam
by Robert Ramey 20 Jul '04

20 Jul '04

Guillaume wrote: >Le mar 20/07/2004 ` 08:06, Vladimir Prus a icrit : >> Robert Ramey wrote: >> > >> [1] As does the manpage say: "Never use this function". >> > > >> > >Depending on the version, you may even see a more helpful message in >the >> > >manpage. >> > > >> > > >> > >BUGS >> > > Never use this function. Use mkstemp(3) instead. >> > >> > Well, not helpful enough. Making a stream from a file descriptor is code I >> > don't have. >> >> Maybe, you should take a look at the code I've posted... you don't need >to >> create fstream from file descriptor. You can open the file using the name >> mkstemp returns via the in/out parameter. >No, using mkstemp this way is no different than using tmpnam. Even if >the file is already open, there is no reason for it to still be linked >in the directory. So you may end up with a different file, and chaos >ensues. So what course of action do you recommend? Also, as I understand the problem, If I don't use tmpnam but just assign a fixed name like "xyz", the same issues re race conditions and potential flaws are still present - are they not? This is sort of an interesting question but seems way beyond the scope of what can be addressed by a program whose function is to test a library during development. Perhaps you want to conjure up a definitive solution and submit for consideration as part of the filesystem library. Robert Ramey

2 1

Re: Boost.test: minor fix
by Gennadiy Rozental 20 Jul '04

20 Jul '04

> patch attached > > jon > Thanks. - utf::wstring_token_iterator tit( L"?????? ?? ? ???" ); - wchar_t const* res[4] = { L"??????", L"??", L"?", L"???" }; + utf::wstring_token_iterator tit( L"\317\356\367\345\354\363 \341\373 \350 \355\345\362" ); + wchar_t const* res[4] = { L"\317\356\367\345\354\363", L"\341\373", L"\350", L"\355\345\362" }; But could you please explain why do I need that and what is wrong with original? Gennadiy.

1 0

Re:Re: [boost] Re: Multiple files utf8_codecvt_facet.cpp
by Robert Ramey 20 Jul '04

20 Jul '04

Vladimir Prus wrote: >David Abrahams wrote: >> > It seems reasoable, because it's not templated code. Creating a library >> > will lead to a set of other problems. If both serialization and >> > program_options need to use utf library, then, should they link to that >> > new library, or ask that users link to the new library themself? >> > >> > Since it case of static libraries it's not possible to link utf into >> > program_options, seems like the user would have to link utf manually. >> > Hmm... that's not good, but I don't see better solution. >> >> For now you could put it in an unnamed namespace and just compile it into >> both of the libraries via #include. >>Yeah, I think that's possible. So I'm going to: >1. put new header to boost/detail >2. put new source to libs/detail/utf >3. #include new source in program_options. Fine. I'll #include new source in serialization as well so we'll all be in the same page. Question. Does this not mean that this if an application includes both the serialization package as well as the program options package that some linkers will fail to links with a duplicate symbol message? I would also like to see 1. The documentation page and test moved to a neutral spot. 2. Could you examine my version and your version and reconcile any differences. Given Rene's observations, I made a pass and fixed the issues he mentioned. It's a could of changes but they are small and make things much more transparent and reliable. I've also tested them on a variety of compilers and feel much better about it. Robert Ramey

2 1

Re: [boost] additional boost libraries?
by Igor Kholodov 20 Jul '04

20 Jul '04

Vladimir Prus wrote >> and, just out of curiosity: >> xml/html parsing > >None so far. In fact, it seems unlikely that somebody will come along and >implement all the XML stack (DOM, XPath, XML Schema, XSTL, whatever) right >now. One chance would be is somebody boostify some existing XML toolkit -- >but which one? > >Another chance is to initially create "tiny XML" library. In fact, both >regression tools and serialization have their own tiny XML parsers and users >aksed about XML support for program_options, so such library might really be >usefull. Here is another example of non-validating XML stream parser: http://cttl.sourceforge.net/xml/index.html Igor Kholodov http://cttl.sourceforge.net/

1 0

Boost.Thread fix for gcc 3.4
by Vladimir Prus 20 Jul '04

20 Jul '04

The test_thread test fails on g++3.4 on this line: BOOST_TEST(thrd == boost::thread()); saying that copy constructor of boost::noncopyable is not accessible. My understanding of the problem is that boost::thread() is rvalue. According to standard, implementation - bind reference to rvalue - create temporary the copy constructor, however, should be accessible no matter what implementation decides. Earlier gcc version did not enforce this rule, apparently. I've comitted the attached obvious fix, tested to work on 3.4, 3.3, 3.2 and 2.95. - Volodya

2 1

missing jam_log.xml
by DY, JERRY U (SBCSI) 20 Jul '04

20 Jul '04

The test results being generated on HP-UX-PARISC looks different than everybody else's. Not sure if it's related, but I also get the following messages towards the end of the testing: Missing jam_log.xml in target: /pics/log/ccase/boost/boost/bin/boost/libs/utility/test/binary_search_te st.test/acc/debug Missing jam_log.xml in target: /pics/log/ccase/boost/boost/bin/boost/libs/utility/test/checked_delete_t est.test/acc/debug Missing jam_log.xml in target: /pics/log/ccase/boost/boost/bin/boost/libs/utility/test/result_of_test.t est/acc/debug and indeed I don't find jam_log.xml anywhere. Who generates this file? This is not the same as test_log.xml, is it? Thanks! -Jerry

1 0

algorithm/string/iterator_range: copy-construction from singular iterator
by Guillaume Melquiond 20 Jul '04

20 Jul '04

Hi, Almost all is said in the subject. According to 24.1-5 it is undefined behavior; consequently default initialized parameters cannot be used. So here comes a patch. I didn't put the half constructor (only a "begin" parameter, no "end" parameter) because I don't think it makes sense; but if it does, just add it. Regards, Guillaume

2 1

Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 20 Jul '04

20 Jul '04

Do we need all three separate concepts -- mutex, try_mutex and timed_mutex? I'd expect the mutex concept to remain unchanged and "try" and "timed" refinements to be related solely to the ways I try locking that only mutex. That is, I always have one mutex and under different circumstances lock it unconditionally (scoped_lock) or try locking it and check if that attempt succeeds (scoped_try_lock) or try locking within a certain time period (scoped_timed_lock).

11 62

RE: [boost] Re: [1.32 release] ANN: Beta *overall* summary report s
by Aleksey Gurtovoy 20 Jul '04

20 Jul '04

David Abrahams writes: > Christopher Currie <codemonkey(a)gmail.com> writes: > > No one owns it, it doesn't exist. I'm trying to create it, and the > > problem is that the directory CVS-HEAD isn't group writeable. > > Then who owns the directory? Only its owner can fix it. Fixed. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

RE: [boost] Re:ANN: Beta *overall* summary reports
by Aleksey Gurtovoy 20 Jul '04

20 Jul '04

Victor A. Wagner Jr. writes: > > how does one go about uploading log sets Please see (a very short and easy!) setup procedure at http://tinyurl.com/4f2zp (the original is in the CVS -- http://tinyurl.com/68bdq, but the last revision is not available from the web yet). > I'm currently running all the tests every 0300 PDT right after doing a > cvs -z9 update -dPA >> update.log > > and rebuilding bjam (whether it needs it or not...there > doesn't seem to be a jamfile for it) The script above is fully automatic and takes care of the whole thing. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

RE: [boost] Re: [1.32 release] ANN: Beta *overall* summary report s
by Aleksey Gurtovoy 20 Jul '04

20 Jul '04

Christopher Currie writes: > Aleksey Gurtovoy wrote: > > As usual, comments/suggestions/bug reports are most welcome. > > This is a great effor, thanks for putting this together. Thank you; I hope we can bring this to a usable state within a few days. > > Unfortunately, I came across a few problems trying to run this on my > Solaris box. The first few center around the system( ) call, which > tries to run a 'tmp.cmd' that gets created in the execution directory: > > - This will fail if the CWD is read only to the user > - The CWD isn't usually in my PATH, so the shell can't find > it to run it > - The file isn't created with execute permissions, so the > shell can't run if it finds it. Sorry about that, that was basically a forgotten and untested Windows-only code. Fixed now. > > Once I worked around those problems (by pre-creating the file +x in the > CWD), I couldn't upload the results, due to a permissions error in the > incoming/CVS-HEAD directory: > > scp: > /home/groups/b/bo/boost/htdocs/regression-logs/incoming/CVS-HE > AD/cgc.xml: > Permission denied Fixed this one as well. Hopefully everything should work for you now. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

RE: [boost] additional boost libraries?
by Reece Dunn 20 Jul '04

20 Jul '04

Aleksander Demko wrote: >I, like billions of other developers, have a medium sized project >that for various reasons, invented its own thread, io, etc >libraries. I'm thinkin of switching over to boost stuff for all my >utility needs, but I'm wondering if boost has/possibly will have/is >open to the possibility of adding/ or will never have the following >facilities: > > serialization/object persistance (via iostreams) I am not sure if the Boost.Serialization library supports this, you'd need to ask Robert Ramey. I have a library in the sandbox (outfmt) that supports I/O of the standard containers and several boost constructs (e.g. contained_pair) for sequential types. I am currently in the process of overhauling the documentation and tests ready for the upcoming review. > network socket iostreams Check out Jonathan Turkanis's IOStreams library (pending review). As far as I am aware, this makes it easier to write custom I/O streams. You will probably need to implement the socket code for it, but there might be a Boost library that does that. > interface to dlls/.so loading I am not sure about these. I think the thread library provides something like this to perform thread cleanup, but you'd need to ask one of the Boost.Thread people. > url parsing (something like the filesystem lib) It should be possible to use Boost.Spirit to write a URL grammar. URL handling would be a good extension to the filesystem library, although I am not sure if/how it is possible. >and, just out of curiosity: > xml/html parsing It is possible to use Boost.Spirit for this. If you check out the Spirit repository (http://spirit.sourceforge.net/repository/applications/show_contents.php) you will find several examples. Also, if you want a SAX-based parser, contact me off-list and I'll e-mail the parser I have been working on. NOTE: my parser does not check tag/element name validity, but does perform basic structural clean-up. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

1 0

DLL linking with Como
by Jeff Garland 20 Jul '04

20 Jul '04

date-time has a number of regession test failures when it is built in the dll mode on windows. They look like this: C:\Progra~1\Comeau\4_3_3\bin\como --vc7 -c -e5 --no_version --no_prelink_verbose --display_error_number --long_long --diag_suppress=9,21,161,748,940,962 -D__STL_LONG_LONG -DBOOST_DATE_TIME_POSIX_TIME_STD_CONFIG -DBOOST_ALL_DYN_LINK=1 --a --no_inlining /Zi /Od -D_WIN32 --exceptions -DBOOST_DISABLE_WIN32 --wchar_t -I"C:\Users\Administrator\boost\main\results\bin\boost\libs\date_time\build" -I"C:\Users\Administrator\boost\main\boost" -I"C:\Progra~1\Comeau\4_3_3\libcomo" -I"C:\Progra~1\Comeau\4_3_3\libcomo\cnames" -o "C:\Users\Administrator\boost\main\results\bin\boost\libs\date_time\build\boost_date_time.dll\meta-como-win32-4.3.3-vc7\debug\greg_month.obj" "C:\Users\Administrator\boost\main\boost\libs\date_time\build\../src/gregorian/greg_month.cpp" "C:\Users\Administrator\boost\main\boost\boost/date_time/gregorian/greg_month.hpp", line 55: error #70: incomplete type is not allowed class BOOST_DATE_TIME_DECL greg_month : public greg_month_rep { ^ Which looks like it is complaining about the BOOST_DATE_TIME_DECL macro. I'm wondering if in config/platform/win32.hpp we need to at como to this little macro that controls the definition of BOOST_HAS_DECLSPEC. #if !defined(__GNUC__) && !defined(BOOST_HAS_DECLSPEC) # define BOOST_HAS_DECLSPEC #endif I've never used this compiler -- anyone out there know how it handles dll symbol export on win32? Jeff

4 5

RE: [boost] Re: Boost.Test problem
by Rozental, Gennadiy 20 Jul '04

20 Jul '04

> >>Ok... more Boost.Test (minor) problems: > >> > >>http://tinyurl.com/72awd > > > > > > And what is the problem here? > > It's giving a "fail" flag on Comeau. See the MetaCom test > results for Boost.Test. See your basic_cstring_test at > http://tinyurl.com/55xg6 for example. Well. I do not have an access to this compiler. And this test pass on most Windows compilers I have access to. Could somebody give me explanation on what this compiler complains about? Gennadiy.

2 2

Multiple files utf8_codecvt_facet.cpp
by Matthias Troyer 20 Jul '04

20 Jul '04

Hi, is there a reason why both program_options and serialization contain very similar files utf8_codecvt_facet.cpp? Matthias

4 9

RE: [boost] Re: Boost.Test problem
by Rozental, Gennadiy 20 Jul '04

20 Jul '04

> The workaround should make use of the BOOST_NO_CWCHAR macro, > which is set if _GLIBCPP_USE_WCHAR_T / _GLIBCXX_USE_WCHAR_T > is not set (see > boost/config/stdlib/libstdcpp3.hpp) > > Maybe something like this (but using BOOST_WORKAROUND): > > #if defined( __GNUC__ ) && defined( BOOST_NO_CWCHAR ) > namespace std { using ::wcscmp; } > #endif Why do I need to test for gcc here in a first place? > Although this isn't quite right, as it only tests for GCC, > but it's the stdlib that affects the availablity of > std::wcscmp (i.e. GCC with STLPort wouldn't be affected AFAICT) > > jon Thanks for analysis, I will apply this fix. Gennadiy.

2 1

Re: Bjam won't build thread static library VC .NET
by Tonko Juricic 20 Jul '04

20 Jul '04

Michael Glassford wrote: > The upcoming 1.32.0 has some support for building > as a static library (i.e. you can build it that > way, but you must call functions at appropriate > times-- not an easy thing to do--to prevent the > memory leaks if you use thread_specific_ptr). > Hopefully the next release after 1.32.0 will do > cleanup for you automatically. Mike, I'm still reading group archives to catch up with the past issues so the following may be a dumb question: Assuming that motivation is to provide cross-platform support for thread_specific_ptr (that is my current understanding), is it worthy of complications with thread exit cleanup? I tend to think that only people familiar with threading issues would use thread_specific_ptr, therefore 'generic' thread code should not be responsible for tss cleanup. Tony __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

[threads] Compilation problems on CW and others...
by Rene Rivera 20 Jul '04

20 Jul '04

Michael, I believe one of the last remaining problems with the compilation of threads in Win32 platforms, maybe others, is that the line-endings on the files are totally incorrect. When I look at the files I see double spaced lines with line-endings of the CR-CR-LF variety. This causes all kinds of problems when the CW preprocessor tries to parse multi-line macros as it only parses the first line and error on the rest, for example: ### mwcc Compiler: # File: ..\src\exceptions.cpp # ------------------------------ # 49: || defined(__CYGWIN__) # Error: ^^ # declaration syntax error Which is the second line of: # if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) \ || defined(__CYGWIN__) It will likely be easier for me to fix this directly than have you try and get the line endings just right, as the editor I use has functionality to fix those problems. Would it be OK for me to fix those at this time? I don't want to collide with anything you might be changing. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

6 35

RE: [boost] This afternoon's test run
by Victor A. Wagner Jr. 20 Jul '04

20 Jul '04

At Monday 2004-07-19 12:47, you wrote: > > ../libs/test/test/ifstream_line_iterator_test.cpp(28): error in > > "test_default_delimeter": test it != utf::ifstream_line_iterator() failed > >I do not understand something in Boost.Build system. This test should pass. >Are you sure you did update -d ? cvs -z9 update -dPA >> update.log and it ran at 0300 -0700 (PDT) >Gennadiy. >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

2 1

dynamic_bitset question & compiler warning
by Terence Wilson 20 Jul '04

20 Jul '04

I have an unsigned char array which I would like to represent as an array of bits in order to perform bit shift operations. My code is as follows: // rotate bits as one large bitset typedef unsigned char octet; void Normalize(boost::shared_array<octet> RawHash, int RawHashLength) { int ShiftLength=7; boost::dynamic_bitset<octet> HashBits; for (int i=0; i<RawHashLength; ++i) { HashBits.append(RawHash[i]); } boost::dynamic_bitset<octet> ShiftedBits=HashBits << ShiftLength; } A couple of issues: 1) How do I get bits out as unsigned chars after the shift operation? 2) I get a compiler warning, it doesn't seem to like me using unsigned char. I am using Visual Studio 2003- c:\PROJECTS\vcpp\Libs\Boost\boost_1_31_0\boost\dynamic_bitset.hpp(655) : warning C4267: 'initializing' : conversion from 'size_t' to 'const boost::dynamic_bitset<Block>::block_type', possible loss of data with [ Block=octet ] c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xmemory(115) : while compiling class-template member function 'boost::dynamic_bitset<Block> &boost::dynamic_bitset<Block>::operator <<=(boost::dynamic_bitset<Block>::size_type)' with [ Block=octet ] c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xmemory(156) : while compiling class-template member function 'boost::dynamic_bitset<Block>::dynamic_bitset(const Allocator &)' with [ Block=octet, Allocator=std::allocator<octet> ] c:\PROJECTS\vcpp\PasswordGenerator\Normalizer.cpp(46) : see reference to class template instantiation 'boost::dynamic_bitset<Block>' being compiled with [ Block=octet ] c:\PROJECTS\vcpp\Libs\Boost\boost_1_31_0\boost\dynamic_bitset.hpp(658) : warning C4267: '=' : conversion from 'size_t' to 'octet', possible loss of data c:\PROJECTS\vcpp\Libs\Boost\boost_1_31_0\boost\dynamic_bitset.hpp(660) : warning C4267: '=' : conversion from 'size_t' to 'octet', possible loss of data c:\PROJECTS\vcpp\Libs\Boost\boost_1_31_0\boost\detail\dynamic_bitset.hpp(88) : warning C4267: 'return' : conversion from 'size_t' to 'octet', possible loss of data c:\PROJECTS\vcpp\Libs\Boost\boost_1_31_0\boost\detail\dynamic_bitset.hpp(88) : while compiling class-template member function 'octet boost::detail::dynamic_bitset_base<Block,Allocator>::mask1(boost::detail::dy namic_bitset_base<Block,Allocator>::size_type)' with [ Block=octet, Allocator=std::allocator<octet> ] c:\PROJECTS\vcpp\Libs\Boost\boost_1_31_0\boost\dynamic_bitset.hpp(76) : see reference to class template instantiation 'boost::detail::dynamic_bitset_base<Block,Allocator>' being compiled with [ Block=octet, Allocator=std::allocator<octet> ]

2 1

Re:[boost] Re: [serialization] CW problems...
by Robert Ramey 20 Jul '04

20 Jul '04

> Yes. But did anyone try other non intrusive approaches? Here are some > possibilities: Yesterday I studied this question carefully in light of the experience gained from testing with my own compilers and reviewing the test results. I altered the utf8_codecvt_facet.cpp to make it more correct and more obvious as to the issues it addresses with regard to each compiler. I tested on all the compilers I have (borland 5.51, borland 5.60, msvc 6.0, msvc-stlport, msvc 7.1 and gcc 3.3/cygwin and was satisfied with the results. I am awaiting test results for other compilers. I'm hopeful that this will achieve results satisfactory to all concerned. Vladimir's point is a interesting one: The is code module doesn't really belong to either package - the question arises as to where it should be placed. If I leave in the serialization package or Vladimir leaves it in the program options package its unsatisfactory as we either have to more or less identical packages or a non-sensical cross dependency. There is currently not neutral place for *.cpp code, docs and tests for unreviewed code of this nature. As to the particular case of this code module, there was an open invitation to review/scrutinize it and several people did comment it should be moved to boost directory/namespace, Vladimir found it sufficiently useful to copy it into the program options project. No one has found any major fault with its design, interface or implementation. The only problem has is that it depends upon libraries whose implementation is inconsistent in this area and this is being addressed and resolved by testing. My only regret is that Vladimir didn't communicate to me the changes he saw fit to make. I certainly would have been very happy to either incorporate the changes he included for CW (as I did the changes submitted by Pavel Vozenilek). Actually I would have been happy to hand this off to Vladimir or anyone else who would like to take responsibility for it as it's really peripheral to the serialization library in any case. Robert Ramey

2 1

Some SFINAE for vc6
by David Abrahams 20 Jul '04

20 Jul '04

Tip for those insane persons who are trying to nurse vc6 along: Some kinds of SFINAE are possible. Forming a pointer to a reference, for example, will remove a function signature from the overload set. Here's something I did in Boost.Python just now. In this case it was only needed for VC6, but it should work for any SFINAE-ish compiler: template <class T> explicit object( T const& x # if BOOST_WORKAROUND(BOOST_MSVC, == 1200) // use some SFINAE to un-confuse MSVC about its // copy-initialization ambiguity claim. , typename mpl::if_<is_proxy<T>,int&,int>::type* = 0 # endif ) Ron Garcia reminded me that I had done this for the multi_array library a while ago, and I realized I had forgotten all about it. I thought y'all should know. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

Multiple or union range iterators
by Piccolboni, Antonio 20 Jul '04

20 Jul '04

Hi, I have n arrays of float and I need to take median of all the values. I have a nifty templatized implementation median(start stop) and I don't have the space to make a copy of all the arrays. Well I do most of the times but I like zero-copy implementations. So I was thinking that I could use an itarator that spans multiple ranges. Something like Vector<float a,b>; [fill them] Multiple_range_iterator<vector<float::iterator> start(a.end(),b.begin()), stop(start); start = a.begin(); stop = b.end(); cout << median(start, stop); Of course this needs to be extended to n ranges. The intended meaning is that incrementing start would apply the increment operator of the argument type until it reaches a.end(), where it would jump straight to b.begin(). You can imagine how random jumps and comparisons are defined. I guess < would bring trouble. Well, the question is: has anyone seen anything like this? Does it make sense? Should I start from iterator_adaptor? Any suggestions (no, "go get another job" is not admissible)? Thanks Antonio

2 1

Spirit grammar definition
by Nico Massi 20 Jul '04

20 Jul '04

Hi, I have a problem with a spirit parser. My grammar/skipgrammer and its definition are working, but only on the first spirit::parse() call. My function around parse() looks like this. void function() { string str; file.open(); file >> str; file.close(); vector<string> library; vector<Group> groups; MyGrammar g( library, groups ); MySkipGrammar s(); boost::spirit::parse( str, g, s ); // library and groups are now filled properly setLibrary( library ); setGroups( groups ); } This works fine, as long as i call function() only one time. The second time i call the function ( even if the parse data(str) is the same ), the parse() function failes with a memory error ( access to 0xcccccccc ( MSVCs default debug value ) ) I have tried to debug it and found the following. It seems that in the second call, the inner class(definition) of MyGrammer is still referencing the old data. And the first access in one rule actor to library or groups failes with memory access to 0xcccccccc. And even if a create MyGrammar on the heap ( MyGrammar* g = new... ) it seems that the inner definition class is not created the second time. I have set breakpoints to a self created actor, and the actor is only created once on the first function call. Every other function() call other than the first does not create the actors, so they are still hold the old object references. Any ideas where the error could be? And why are the actors only created once? P.S.: I`m using MSVC.net 2003

3 3

[inspect] Updated inspect checks show more line-ending problems...
by Rene Rivera 19 Jul '04

19 Jul '04

My newest run of the inspect tool shows a new set of invalid end-of-line problems, all in Boost.Spirit: http://www.boost.org/regression-logs/inspection_report.html#spirit Boost Inspection Report But overall the number of errors went down :-) From... 8021 files scanned 675 directories scanned 1572 problems reported problem counts: 1231 files missing copyrights 1 files with invalid line endings 0 bookmarks with invalid characters 1 invalid urls 91 broken links 45 unlinked files 51 file names too long 152 files with tabs To... 8043 files scanned 676 directories scanned 1477 problems reported problem counts: 1204 files missing copyrights 14 files with invalid line endings 0 bookmarks with invalid characters 1 invalid urls 80 broken links 44 unlinked files 51 file names too long 83 files with tabs -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

2 1

Serialization and tmpnam
by Guillaume Melquiond 19 Jul '04

19 Jul '04

Hi, I see the serialization library uses "tmpnam" quite a lot. I don't know what the status of this function is on other operating system. But on GNU/Linux at least (and I suppose it is the same for any POSIX system), it is considered to be bad practice [1]. Such a bad practice that the linker ld is especially programed to complain whenever somebody uses this function. Moreover, I see that Borland and Microsoft compilers "have brain-dead tmpnam functions" [2] so a replacement was needed. So it may be a good idea to completely remove the function "tmpnam" from the Serialization library and use a saner replacement instead. This way, the library tests would compile without any complaint from the linker on Linux. Regards, Guillaume [1] As does the manpage say: "Never use this function". [2] Comment at the beginning of serialization/test/test_tools.hpp.

2 1

Re: Boost Software License Progress?
by Stephan T. Lavavej 19 Jul '04

19 Jul '04

[Doug Gregor] > This is a really good idea. Adding another mode to "inspect" > that outputs this web page would be the best way to start... Having such a page for each release of Boost would be good. > Looks like bind and smart pointers need the new license. Mlar! Can these be fixed before 1.32.0? Stephan T. Lavavej

1 0

[1.32 release] ANN: Beta *overall* summary reports
by Aleksey Gurtovoy 19 Jul '04

19 Jul '04

A beta version of Boost-wide, multi-platform regression status reports is available at http://boost.sourceforge.net/regression-logs/developer/. Well, they are not truly multi-platform at the moment -- only one set of results is shown, but they will become such as soon as somebody uploads another set of logs. The details on this and other matters follow. The reports are re-generated every two hours against the test logs collected from http://boost.sourceforge.net/regression-logs/incoming directory. To get their platform/compiler included into the report, the regression runners need to insert "boost\tools\regression\xsl_reports\runner\collect_and_upload_logs.py" script invocation somewhere in their driver scripts (after the bjam has already run, of course). A typical command line for the script is shown below: python collect_and_upload_logs.py --locate-root=C:\Users\Administrator\boost\main\r esults\bin\ --runner=metacomm --tag=CVS-HEAD --platform=win32 --comment=comment.html --timestamp="Sat, 17 Jul 2004 07:09:58 +0000" --user=agurtovoy To be most useful, a timestamp needs to be acquired right before *CVS checkout/update* is started (as opposite to when the test are finished). The script requires Python 2.3 and, for Windows platform, some version of Cygwin. The goal is to have a single page that reflects the status of the CVS across all platforms/compilers we currently test against. Moreover, a separation of test runs from report generation significantly lowers the regression's setup cost. Hopefully with other improvements in that area we will get more volunteers running the tests on a wider range of platforms. As usual, comments/suggestions/bug reports are most welcome. -- Aleksey Gurtovoy MetaCommunications Engineering

3 6

Boost Software License Progress?
by Stephan T. Lavavej 19 Jul '04

19 Jul '04

Hi Boosters, I've started working at Microsoft, and I would like to use Boost at work the way I do in my personal projects. But this isn't possible unless I can get big scary lawyers to bless it first, and /that/ isn't possible unless most or all of Boost is released under a single license. So, could someone summarize the status of the conversion to the Boost Software License? How far along will it be by the time 1.32.0 is released? I'm sure I'm not the only one this makes a difference to - I have a friend at Microsoft who also wants to use Boost. Can a page be put up on the Boost website summarizing the license state of every library in Boost? Then I could point the big scary lawyers at it. How actively are Boost developers being sought out to change their licenses over to the Boost Software License? From the attention I was paying to the list a few months ago, it seemed like the conversion wasn't being pursued very aggressively. I didn't care then, but I care now! It seems to me that the conversion is especially important for the libraries that have been incorporated into TR1. Stephan T. Lavavej

2 1

Re:ANN: Beta *overall* summary reports
by Robert Ramey 19 Jul '04

19 Jul '04

> A beta version of Boost-wide, multi-platform regression status reports > is available at http://boost.sourceforge.net/regression-logs/developer/. > Well, they are not truly multi-platform at the moment -- only one set > of results is shown, but they will become such as soon as somebody > uploads another set of logs. The details on this and other matters > follow. > As usual, comments/suggestions/bug reports are most welcome. When I click on the "fail" I don't get the links.html output as I did before. What are the plans (if any) for this? Robert Ramey

3 2

RE: [boost] This afternoon's test run
by Rozental, Gennadiy 19 Jul '04

19 Jul '04

> ../libs/test/test/ifstream_line_iterator_test.cpp(28): error in > "test_default_delimeter": test it != utf::ifstream_line_iterator() failed I do not understand something in Boost.Build system. This test should pass. Are you sure you did update -d ? Gennadiy.

1 0

graph/adjacency_matrix: iterator goes past end
by Guillaume Melquiond 19 Jul '04

19 Jul '04

Hi, Line 567 of adjacency_matrix.hpp is: typename Graph::MatrixIter l = g.m_matrix.end() + u; Obviously l is an iterator past the end. Looking at the algorithm, it seems to me it shouldn't be g.m_matrix.end() but f. So here comes a patch. Regards, Guillaume

2 7

Re:[boost] Threads Rewrite?
by Tonko Juricic 19 Jul '04

19 Jul '04

I just started using boost on Win32 platform and the lack of the ability to stop the thread is what immediately caught my attention. I understand it is difficult portability issue but I've seen too many uses where stop functionality is necessary. Looking at the current Win32 implementation, I'm afraid that adding thread stop would affect both mutextes and condition: as these call WaitOnSingleObject it seems impossible to stop the thread waiting on some 'external' mutex or condition. Off-hand, maybe TLS for each thread can have a default stop mutex and Win32 implementation of other synchronization primitives would always wait on at least two objects. It would also be nice to be able to start thread suspended, even if I guess it can be done now with mutex at the beginning of custom thread functor. Tony __________________________________ Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! http://advision.webevents.yahoo.com/yahoo/votelifeengine/

1 0

Seeking Boost round() function
by Matt Verona 19 Jul '04

19 Jul '04

I was reading the Boost documentation, and couldn't find a function to round floating point numbers (up or down) to the nearest integer. I have my own implementation of this algorithm as follows: #include <math.h> double round(double number) { return number < 0.0 ? ceil(number-0.5) : floor(number+0.5); } This round function produces the following output: round(0.0) = 0 round(1.49) = 1 round(1.5) = 2 round(-1.49) = -1 round(-1.5) = -2 Does Boost contain a simple rounding function like this? Thanks in advance, ~Matt Verona matt_verona(a)acm.org Houston, Texas USA

3 2

Boost.Threads static linking FYI
by Michael Glassford 19 Jul '04

19 Jul '04

I've made some changes to the Boost.Threads static linking support on Win32. Previously I had added back support for static linking, but without thread-specific storage classes. Now I've added the thread-specific storage classes back in, and exposed two functions that need to be called at the appropriate time: The function on_thread_exit() should be called when a thread exists, *in the context of the exiting thread*. The function on_process_exit() should be called when the process exit. If these functions are not called at the appropriate time, leaks may occur. If you know you don't need tss cleanup, of course you can just omit to call these functions. In addition, Boost.Threads static library on Win32 requires the user of the library to define a function called tss_cleanup_implemented(); if it is not defined, a link error results. The only purpose of this function is as a "link-time assertion": the linker error stating that the function is missing warns the the user of the necessity of calling the cleanup functions. In addition, if Boost.Threads later implements tss cleanup in the static library, the linker's duplicate symbol error should warn the user that their custom implementation is no longer needed. Comments? Mike

5 11

Re:[boost] [serialization] CW problems...
by Robert Ramey 19 Jul '04

19 Jul '04

>Rene Rivera wrote: >> Robert Ramey wrote: >> >>> While your looking at CW, might you find the time to look a little bit >>> into >>> the serialization library build problems. The error message is pretty >>> bizarre so I don't think it can be addressed without having CW >>> installed on >>> ones machine. >> >> OK, I'll try... Should I look for anything in specific? Or is it a >> general health issue? >I'm looking at this and one of the basic problems is that you seem to >assume a variety of things are available in the global namespace, >specifically size_t and other std types. Those are easy to fix by >specifying std::size_t. But I do have some questions... >1. Is using an unqualified size_t your intention? And therefore >something else is broken? Wow - its amazing to me I could have come so far and not know that size_t wasn't a built in type or macro - I think it used to be a macro definition. Anyway, I'll qualify this with std::size_t and check that no other compilers complain. If fact, now I can't understand why no other compiler complained since I never included <cstddef> >2. There is a similar problem with mbstate_t, but in this case you >attempt to do something special to handle it (from >boost/archive/codecvt_null.hpp): >#if BOOST_WORKAROUND(__BORLANDC__, <= 0x564) > #ifndef _RWSTD_NO_NAMESPACE > using std::codecvt; > using std::min; > #ifdef _RWSTD_NO_MBSTATE_T > using std::mbstate_t; > #endif > #endif >#elif defined(__COMO__) || defined(_MSC_VER) && _MSC_VER <= 1300 || >defined(__BORLANDC__) > typedef ::mbstate_t mbstate_t; >#elif defined(BOOST_NO_STDC_NAMESPACE) > typedef std::mbstate_t mbstate_t; > namespace std{ > using ::codecvt; > } // namespace std >#endif >And then you go ahead to use an unqualified mbstate_t. This just doesn't >work for CW. And I don't see how this would work for any library runtime >that puts mbstate_t only in the std namespace. Could you explain what >your intent is for this? The situation with mbstate_t is problematic. Some compilers define it in the global namespace while others define it in std::mbstate_t. The intent is to permit the code to use mbstate_t without qualification for those compilers that don't define it as std::mbstate_t. This sort of grew one compiler at time without too much thought. The typedef ::mbstate_t mbstate_t makes me wonder what I was thinking. Following the logic here for CW this would add #elif defined(CW) using std::mbstate_t; so that the rest of the code could use unqualified mbstate_t . I'll fix this (and a bunch other stuff) and we'll try again later. Thanks a lot. Robert Ramey

6 11

Bjam won't build thread static library VC .NET
by Tonko Juricic 19 Jul '04

19 Jul '04

First excuse me if this topic is not appropriate for boost developers list. This is my first post so I decided on asking a question rather than sending an empty message with test as a subject. I just built boost 1.31.0 libraries on Windows XP, using Visual Studio .NET 2003, compiler version 13.10.3077. To build both static libs and dlls I used this bjam command parameter -sBUILD=debug release <runtime-link>static/dynamic. Build worked just fine for all libs (for ex. I got both libboost_signals.lib and boost_signals.dll targets for signals) except for the thread library that created only boost_thread.dll target. What am I missing? Is there a reason that static threads library was not built and is there any way I can help? Tony __________________________________ Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! http://advision.webevents.yahoo.com/yahoo/votelifeengine/

3 2

[date-time] not showing up in nightly CVS boostbook?
by Jeff Garland 19 Jul '04

19 Jul '04

I checked in a change to switch date-time over to boostbook (added to the docs/src/boost.xml file), but I haven't seen it show up on the web site yet. Is this not being run / uploaded on the weekend? Jeff

2 2

numeric/conversion/detail/meta: void_ in boost::mpl namespace
by Guillaume Melquiond 19 Jul '04

19 Jul '04

Hi, Is BOOST_MPL_AUX_VOID_SPEC_PARAM supposed to be used by other libraries than MPL? The conversion library uses it (it is the only one to use it) and it obviously results in an error since void_ is in the boost::mpl namespace. This error is flagged by GCC, CodeWarrior, Como, and Intel (Linux). I won't suggest a patch since I'm not even sure to understand what this macro is supposed to do (is there any documentation or is it an undocumented internal macro?), but it can't be a bad thing to remove any reference to BOOST_MPL_AUX macros from the conversion library. Regards, Guillaume

2 1

Another regression testing problem.
by Martin Wille 19 Jul '04

19 Jul '04

Hi, I ran into another (small) problem with regression testing: Unpacking the tar-ball containing the XSL based reports takes approximately 1 hour on the (not very busy) SF shell server. The tar-ball is only 60MB in size, but it contains ~24000 files, which could explain why it takes that long. Is there any way to reduce the number of files? Regards, m

2 1

RE: [boost] uBLAS regressions
by Michael Stevens 19 Jul '04

19 Jul '04

On Monday 19 July 2004 09:51, Aleksey Gurtovoy <agurtovoy(a)meta-comm.com> wrote: > Unfortunately, it did -- it was producing a composite library name > with back instead of forward slashes ("numeric\ublas" instead of > "numeric/ublas"), and that confused process_jam_log, causing uBLAS > disappear from the report. > > Fixed in the CVS now, together with a test case to prevent future > disturbance ("tools\build\v1\test\test-testing.jam"). Thanks Aleksey! It was noticed by me and a couple of others that it dropped out from the report. Just show people look at the reports everyday. They are very useful and your effort is very much appreciated. The developer format reports are really very clear and informative. One question. The Comeau tests seem to be in VC7 compatability mode. For me this is a bit of a shame as it is the only Comeau regression test and I would love to know how well we do in strict mode! > For no good reason, IMO. To uBLAS maintainers -- can we fix it > sometime after the release? Certainly will. The layout was historical! All the best, Michael

1 0

program_options & mingw - patch
by Janusz Piwowarski 19 Jul '04

19 Jul '04

Hello, i attach a patch which allows to compile program_options library with mingw. Regards, Janusz

2 1

spirit/iterator/multi_pass: end iterator dereferenced
by Guillaume Melquiond 19 Jul '04

19 Jul '04

Hi, Lines 572-573 of multi_pass.hpp are: ensure_initialized(); return !data || data->input == InputT(); The code tries to read data in ensure_initialized even when testing for end of file (which means the input iterator is invalid). So here comes a patch. Regards, Guillaume

2 1

RE: [boost] uBLAS regressions
by Aleksey Gurtovoy 19 Jul '04

19 Jul '04

Vladimir Prus writes: > Aleksey Gurtovoy wrote: > > > > local rule get-library-name ( path ) > > > { > > > local match1 = [ MATCH [/\\]libs[/\\](.*)[/\\]test > : $(path) ] ; > > > > > > I'm not sure: > > > > > > ghost@zigzag:/tmp$ bjam -f- > > > ECHO [ MATCH [/\\]libs[/\\](.*)[/\\]test : > > > bin\\boost\\libs\\numeric\\ublas\\test1\\test1.test ] ; > > > numeric\ublas\test1 > > > > > > > > > It's numeric\ublas\test1, not numeric\ublas. > > > > 'get-library-name' will be passed > > "bin\\boost\\libs\\numeric\\ublas\\test1", though, not > > "bin\\boost\\libs\\numeric\\ublas\\test1\\test1.test". > > Well, first of all, when I create a separate test Jamfile for uBLAS > and subinclude it, I get: > > Cannot extract library name from path ../libs/numeric/ublas > > This is because when it's in status, 'get-library-name' just returns > empty string. When it's not in status, the 'get-library-name' rule > is called with > > ../libs/numeric/ublas > > and the first regex does not match because there's no "test" in the > name, and second regex does not match because there is slash between > "numeric" and "ublas". I've applied the attached patch -- since it > strictly adds the set of arguments to 'get-library-name' on which > that function does not fail, I think it should not cause any > problems. Unfortunately, it did -- it was producing a composite library name with back instead of forward slashes ("numeric\ublas" instead of "numeric/ublas"), and that confused process_jam_log, causing uBLAS disappear from the report. Fixed in the CVS now, together with a test case to prevent future disturbance ("tools\build\v1\test\test-testing.jam"). > > Another question whether all libraries should have their test > Jamfiles under "test" directory Yes, http://www.boost.org/more/lib_guide.htm#Directory_structure. > -- which is not what uBLAS does. For no good reason, IMO. To uBLAS maintainers -- can we fix it sometime after the release? > > And now back to original question. As I understand, the > 'get-library-name' rules gets the location of *Jamfile*. No, it is passed the location of the *target output directory*. > The primary heuristic is that location is "libs/ <library-name> / > test / whatever". Why can't this logic be applied to the name of > source file which bjam prints -- and be implemented in > process_jam_log. Nope, see my original posting -- http://article.gmane.org/gmane.comp.lib.boost.devel/105382. > > I'm asking because it seems to be that it's better to have smart > logic in process_jam_log than in jam. Sure, but in this case testing.jam is the only source of the information. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Re:[boost] Re: [serialization] CW problems...
by Robert Ramey 19 Jul '04

19 Jul '04

Dave Abrahams wrote: >Rene Rivera <grafik.list(a)redshift-software.com> writes: >> boost-root/boost/utf8_codecvt_facet.hpp is original. >> boost-root/boost/program_options/utf8_codecvt_facet.hpp + *.cpp >> is slightly modified copy. >> Intention is that utf8_codecvt_facet will become standalone library >> at some time and these files will be replaced. > > Then it should be moved to boost.detail, directory and namespace. >Right. We should never knowingly allow (near) duplicate code in the >repository. I don't think anyone did it knowingly. Something like this should really be subjected to a mini-review and have its own separate test and documentation and reside outside any of the systems that use it. This has been mentioned before by various people. I included Ron Garcia's version in the serialization project because I needed it. I added a test and found that as one moves to other compilers and standard libraries little things keep popping up. E.G. gcc standard library defines wchar_t as 4 byte while others use 2. So the status is "good enough for the serialization library" The serialization review specifically invited reviewers to critique this and no objections were raised that I recall. There have been proposals for an improved version. My response is that I'm glad to use one that gets reviewed and accepted rather than the one we have now. But so far nothing else has been submitted. It does work and navigates through the vagarities of the compilers that we use. Rene's criticism regarding the the resolution of namespace issues has been taken to heart and the code has been updated accordingly and tested. I expect to check in the improved version soon. Robert Ramey

2 1

This afternoon's test run
by Victor A. Wagner Jr. 18 Jul '04

18 Jul '04

I re-ran the boost tests this afternoon and here are the "interesting" lines from the output ...found 34702 targets... ...updating 529 targets... ...can't find 2 targets... ...can't make 4 targets... ...on 100th target... C:\Projects\boost\boost\numeric\interval\io.hpp(35) : error C2872: 'lower' : ambiguous symbol C:\Projects\boost\boost\numeric\interval\io.hpp(35) : error C2872: 'upper' : ambiguous symbol ...failed vc-C++ ..\bin\boost\libs\numeric\ublas\test7.test\vc7.1\debug\test71.obj... C:\Projects\boost\boost\numeric\interval\io.hpp(35) : error C2872: 'lower' : ambiguous symbol C:\Projects\boost\boost\numeric\interval\io.hpp(35) : error C2872: 'upper' : ambiguous symbol ...failed vc-C++ ..\bin\boost\libs\numeric\ublas\test7.test\vc7.1\debug\test72.obj... ...skipped <@boost!libs!numeric!ublas\test7.test\vc7.1\debug>test7.CMD for lack of <@boost!libs!numeric!ublas\test7.test\vc7.1\debug>test71.obj... ...skipped <@boost!libs!numeric!ublas\test7.test\vc7.1\debug>test7.exe for lack of <@boost!libs!numeric!ublas\test7.test\vc7.1\debug>test7.CMD... ...on 200th target... ...on 300th target... FAIL :: Caught unexpected exception during Stream in greg_month FAIL :: Caught unexpected exception during Stream in greg_month -- wide streams FAIL :: Bad month exception NOT caught (misspelled name) FAIL :: Caught unexpected exception during Stream in greg_weekday FAIL :: Caught unexpected exception during Stream in greg_weekday -- wide stream FAIL :: Bad weekday exception NOT caught (misspelled name) ...failed execute-test ..\bin\boost\libs\date_time\test\testfacet_dll.test\vc7.1\debug\testfacet_dll.run... FAIL :: Get time of day micro second clock not supported due to inadequate compiler ...failed execute-test ..\bin\boost\libs\date_time\test\testmicrosec_time_clock.test\vc7.1\debug\testmicrosec_time_clock.run... ...failed execute-test ..\bin\boost\libs\graph\test\adjacency_matrix_test.test\vc7.1\debug\adjacency_matrix_test.run... ...skipped <@boost!libs!numeric!ublas\test7.test\vc7.1\debug>test7.run for lack of <@boost!libs!numeric!ublas\test7.test\vc7.1\debug>test7.exe... ...failed execute-test ..\bin\boost\libs\python\test\slice.test\vc7.1\debug\slice.run... ...on 400th target... ...on 500th target... ...failed execute-test ..\bin\boost\libs\serialization\test\test_demo_xml_save.test\vc7.1\debug\test_demo_xml_save.run... ...failed execute-test ..\bin\boost\libs\serialization\test\test_demo_xml_load.test\vc7.1\debug\test_demo_xml_load.run... ...failed execute-test ..\bin\boost\libs\serialization\test\test_demo_xml.test\vc7.1\debug\test_demo_xml.run... ...failed execute-test ..\bin\boost\libs\serialization\test\test_demo_shared_ptr.test\vc7.1\debug\test_demo_shared_ptr.run... ...failed execute-test ..\bin\boost\libs\serialization\test\test_demo_exception.test\vc7.1\debug\test_demo_exception.run... ...failed execute-test ..\bin\boost\libs\serialization\test\test_demo.test\vc7.1\debug\test_demo.run... ../libs/thread/test/test_read_write_mutex.cpp(205): error in "test_read_write_mutex": test r1.m_value == 10 failed ...failed execute-test ..\bin\boost\libs\thread\test\test_read_write_mutex.test\vc7.1\debug\threading-multi\test_read_write_mutex.run... ../libs/test/test/ifstream_line_iterator_test.cpp(28): error in "test_default_delimeter": test it != utf::ifstream_line_iterator() failed ../libs/test/test/ifstream_line_iterator_test.cpp(30): error in "test_default_delimeter": test *it == "acv ffg" failed [ != acv ffg] ../libs/test/test/ifstream_line_iterator_test.cpp(36): error in "test_default_delimeter": test *it == " " failed [ != ] ../libs/test/test/ifstream_line_iterator_test.cpp(39): error in "test_default_delimeter": test *it == "1" failed [ != 1] ../libs/test/test/ifstream_line_iterator_test.cpp(51): error in "test_custom_delimeter": test it != utf::ifstream_line_iterator() failed ../libs/test/test/ifstream_line_iterator_test.cpp(53): error in "test_custom_delimeter": test *it == "{ abc d " failed [ != { abc d ] ../libs/test/test/ifstream_line_iterator_test.cpp(56): error in "test_custom_delimeter": test *it == "\n{ d \n dsfg\n" failed [ != ../libs/test/test/ifstream_line_iterator_test.cpp(59): error in "test_custom_delimeter": test *it == "\n" failed [ != ...failed execute-test ..\bin\boost\libs\test\test\ifstream_line_iterator_test.test\vc7.1\debug\ifstream_line_iterator_test.run... ...skipped <@boost!libs!test!test\result_report_test.test\vc7.1\debug>result_report_test.run for lack of C:\Projects\boost\libs\test\test\result_report_test.pattern... ...skipped <@boost!libs!test!test\errors_handling_test.test\vc7.1\debug>errors_handling_test.run for lack of C:\Projects\boost\libs\test\test\errors_handling_test.pattern... ...failed updating 14 targets... ...skipped 20 targets... ...updated 499 targets... The entire output log ( ftp://rudbek.com/pub/boost/status.log ) is available if one of the authors thinks it will be of assistance. The log from the v2 run is there also, but it has so many difficulties I'm not sure how useful it is. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

2 1

Memory Pool items
by Mark Deric 18 Jul '04

18 Jul '04

I have been studying Stephen Cleary's boost::pool template and its subclasses with respect to using them for non-array based allocations in our company's product. We don't use many arrays that we need to dynamically allocate or resize except at init time. But we use lots of map-like collections and shared_ptr-like objects. Our use case is allocation of memory for individual objects varying in size from tiny (8 bytes, the case of a minimal impl similar to shared_ptr) to not so tiny (150-250 bytes, the case of comprehensive state tracking of an individual TCP/IP flow). In several cases, the count of allocated objects can be in the 100,000-1,000,000 range. Two items I've been thinking about: 1) The Guaranteeing Alignment doc's "convoluted example where the requested_size is 7, sizeof(void *) == 3, and sizeof(size_type) == 5" caught my attention. The lcm approach yields 105 bytes per chunk "wasting" 98 bytes per chunk, or 93% of the alloc. This was not so offensive in that it doesn't represent a practical use case of significance. But then, I considered a more common use case in which the consumer's object only had a char[13] data member against an lcm(sizeof(size_type), sizeof(void*)) == 4. The char[13] comes from the semantics of the consumer's app. Here, the lcm method would be to alloc a chunk size of 52; and better would be a chunk size of 16. As a practical matter, what regressions would be introduced if the requested size were just increased to the next multiple of lcm(sizeof(size_type), sizeof(void*))? I get the theoretical issue of the next chunk not being on a multiple of 13; but I can't think of a practical case where this would matter. 2) The issue of the array allocation performance at O(free store size) has me wondering whether the pool class should incorporate the "ordered free list" semantics at all. Maybe a separate class that uses a model more like the Linux kernel model would be better (i.e., a tiering of pages, page pairs, pairs of page pairs, etc.). With allocated chunk counts in the 10e5 - 10e6 range; use of the pool classes array semantics could get nasty. Just my two cents worth. BTW, I totally enjoyed studying Mr. Cleary's work; he, like most of the boost contributor's is lot's smarter than me. That's why, when we are working on building our catherdrals in app land, it's great to have a resource like boost to check on the quality of our bricks. Thanks to all. Regards, Mark -- Mark Deric Director, Research and Development Deepnines, Inc. http://www.deepnines.com

1 0

String Algorithm Lib BCB workaround
by John Maddock 18 Jul '04

18 Jul '04

The string algo library is currently failing with Borland's compiler because it uses code like: template< typename T > class has_native_replace { #ifdef BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION private: static T* t; public: BOOST_STATIC_CONSTANT(bool, value=( sizeof(has_native_replace_tester(t))==sizeof(yes_type) ) ); #else // BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION public: # if BOOST_WORKAROUND( __IBMCPP__, <= 600 ) enum { value = false }; # else BOOST_STATIC_CONSTANT(bool, value=false); # endif // BOOST_WORKAROUND( __IBMCPP__, <= 600 ) #endif // BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION typedef mpl::bool_<value> type; //error here }; Rather than adding yet another workaround, I think this can all be simplified by just using: #ifdef BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION template< typename T > class has_native_replace { private: static T* t; public: BOOST_STATIC_CONSTANT(bool, value=( sizeof(has_native_replace_tester(t))==sizeof(yes_type) ) ); typedef mpl::bool_<value> type; }; #else template< typename T > class has_native_replace : public mpl::bool_<false> { }; #endif // BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION and similar for the other traits classes. John.

2 3

sandbox
by Franz Mueller 18 Jul '04

18 Jul '04

Hi, I've heared of the ublas-binding to lapack, which sounds very good. Thus I tried to install it, but I didn't succeed. I got boost-sandbox using cvs. Then I went to the boost-sandbox directory and did a bjam. But I got this: libs\numeric\blasbindings\tst\Jamfile: No such file or directory libs\numeric\blasbindings\tst\Jamfile: No such file or directory don't know how to make <@boost-sandbox!libs!numeric!bindings!amos>amos.cpp ...found 227 targets... ...updating 34 targets... ...can't find 1 target... ...can't make 5 targets... MkDir1 bin I am using Visual Studio.NET Prof. 2003. I'd love to try the ublas-bindings, so can anybody help me installing it? Anything else I have to take care of once the bindings work (e.g. link to clapack or so)? -- Franz

2 1

[Boost-bugs] [ boost-Bugs-993272 ] xtime_cmp: use comparison not subtraction
by SourceForge.net 18 Jul '04

18 Jul '04

Bugs item #993272, was opened at 2004-07-18 15:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=993272&group_i… Category: timer Group: None Status: Open Resolution: None Priority: 5 Submitted By: Philip Hodges (phhodges) Assigned to: Beman Dawes (beman_dawes) Summary: xtime_cmp: use comparison not subtraction Initial Comment: Subtraction of integral types is prone to arithmetic overflow. It is not well-behaved for implementing comparison unless we first cast both operands to a wider integral type or assert that they fall in a narrower range. Choose comparison order to slightly favour future timeouts, or imminent timeouts in the same second? Patch provided "as is" without express or implied warranty. It may contain any number of intended and unintended flaws. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=993272&group_i… ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] Re: [threads] Compilation problems on CW and others...
by Robert Ramey 18 Jul '04

18 Jul '04

Rene Rivera wrote: >Robert Ramey wrote: >> While your looking at CW, might you find the time to look a little bit into >> the serialization library build problems. The error message is pretty >> bizarre so I don't think it can be addressed without having CW installed on >> ones machine. vOK, I'll try... Should I look for anything in specific? Or is it a >general health issue? It's a (one?) very bizarre error building of the libraries(2). This prevents running of any tests. If this were fixed and the libraries built the test can run and we can take a look and see where we stand on this. Thanks a lot. Robert Ramey

1 0

mpl::at_c as lambda
by Scott Graham 18 Jul '04

18 Jul '04

Hi Is it possible to make mpl::at_c lambda-able? For example, the following (dumb) code works as I would expect, but changing "at<_, int_<0> >" at // XXX to "at_c<_, 0>" does not. BOOST_MPL_AUX_LAMBDA_SUPPORT is not in the at_c struct, which is why it doesn't work I assume, but I don't know enough about mpl to know if it can be added (nor how, if so). ---------- #include <boost/mpl/count_if.hpp> #include <boost/mpl/vector.hpp> #include <boost/mpl/vector_c.hpp> #include <boost/mpl/equal_to.hpp> #include <boost/mpl/at.hpp> #include <boost/mpl/int.hpp> int main() { using namespace boost::mpl; typedef vector < vector_c<int, 9>, vector_c<int, 0>, vector_c<int, 6>, vector_c<int, 0> >::type v; BOOST_STATIC_ASSERT((count_if < v, equal_to < int_<0>, at<_, int_<0> > // XXX > >::type::value == 2)); } ---------- thanks, scott

2 1

Uncaught exception in testfacet_dll
by Victor A. Wagner Jr. 18 Jul '04

18 Jul '04

I'm getting a "stop the script" error when running the test for testfacet_dll (VC7.1) it pops up a requestor telling me the program terminated unexpectedly, and (unfortunately) waits for a human reply (which causes my scheduled run to stop after 4 hours (it starts at 0300 local)), so I'm not getting the rest of the tests run. I chased it down to a std:exception w/ what() == bad cast I'm refining where the error occurs. with the following patches to testfacet.cpp: RCS file: /cvsroot/boost/boost/libs/date_time/test/gregorian/testfacet.cpp,v retrieving revision 1.14 diff -w -r1.14 testfacet.cpp 11c11 < --- > #include <exception> 39a40,41 > try > { 264a267,268 > try > { 265a270,272 > } > catch(std::exception& e) {check(e.what(), false);} > catch(...) {check("some unknown exception found", false);} 317d323 < 319d324 < 321c326,328 < --- > catch(std::exception& e) {check(e.what(), false);} > catch(...) {check("some unknown exception found", false);} > } ======================================================================== I get the following output when I run it from the command line C:\Projects\boost\status>..\bin\boost\libs\date_time\test\testfacet_dll.test\vc7.1\debug\testfacet_dll Pass :: check german short month: Okt Pass :: check german short month: Okt Pass :: check ymd: 01.Okt.2002 Pass :: ostream low level check string:01.Okt.2002 global: C Pass :: no registered facet here Pass :: facet registered here Pass :: check string imbued ostream: 2002-Okt-01 Pass :: check string imbued ostream: +unbegrenztheit Pass :: check string imbued ostream: +unbegrenztheit Pass :: check string imbued ostream: NichtDatumzeit Pass :: check any old ostream: 2002-Oct-01 Pass :: check date order: 01.10.2002 Pass :: check date order: 2002 Okt 01 Pass :: check date order: Oktober 01 2002 Pass :: check date period: [Oktober 01 2002/Oktober 03 2002] Pass :: date_duration stream out Pass :: date_duration stream out Pass :: partial date stream out Pass :: nth kday of month Pass :: first kday of month Pass :: last kday of month Pass :: first kday after Pass :: first kday after 26 Jun second Fri of Sep first Sat of May last Mon of Aug Thu after Tue before FAIL :: bad cast FAIL :: Stream in month FAIL :: bad cast C:\Projects\boost\status> ================================================================================== the log appears to show that this test PASSED tho..... execute-test ..\bin\boost\libs\date_time\test\testfacet_dll.test\vc7.1\debug\testfacet_dll.run 1 file(s) copied. **passed** ..\bin\boost\libs\date_time\test\testfacet_dll.test\vc7.1\debug\testfacet_dll.test ================================================================================== I'm working on getting some better "catch unknown exception" code put together so it can be added readily to tests to keep this from happening in the future. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

2 4

[test] Broken Jamfile or missing files?
by Jeff Garland 17 Jul '04

17 Jul '04

When I run the regression tests on Linux I get a couple errors from the test library: don't know how to make boost_regression1/boost/libs/test/test/result_report_test.pattern don't know how to make boost_regression1/boost/libs/test/test/errors_handling_test.pattern Is the Jamfile broken or are there some files that need to be checked in? Jeff ps: This has been like this for at least the last 2-3 days....

3 2

[serialization] CW problems...
by Rene Rivera 17 Jul '04

17 Jul '04

Rene Rivera wrote: > Robert Ramey wrote: > >> While your looking at CW, might you find the time to look a little bit >> into >> the serialization library build problems. The error message is pretty >> bizarre so I don't think it can be addressed without having CW >> installed on >> ones machine. > > OK, I'll try... Should I look for anything in specific? Or is it a > general health issue? I'm looking at this and one of the basic problems is that you seem to assume a variety of things are available in the global namespace, specifically size_t and other std types. Those are easy to fix by specifying std::size_t. But I do have some questions... 1. Is using an unqualified size_t your intention? And therefore something else is broken? 2. There is a similar problem with mbstate_t, but in this case you attempt to do something special to handle it (from boost/archive/codecvt_null.hpp): #if BOOST_WORKAROUND(__BORLANDC__, <= 0x564) #ifndef _RWSTD_NO_NAMESPACE using std::codecvt; using std::min; #ifdef _RWSTD_NO_MBSTATE_T using std::mbstate_t; #endif #endif #elif defined(__COMO__) || defined(_MSC_VER) && _MSC_VER <= 1300 || defined(__BORLANDC__) typedef ::mbstate_t mbstate_t; #elif defined(BOOST_NO_STDC_NAMESPACE) typedef std::mbstate_t mbstate_t; namespace std{ using ::codecvt; } // namespace std #endif And then you go ahead to use an unqualified mbstate_t. This just doesn't work for CW. And I don't see how this would work for any library runtime that puts mbstate_t only in the std namespace. Could you explain what your intent is for this? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

1 0

Re:[boost] Re: [threads] Compilation problems on CW and others...
by Robert Ramey 17 Jul '04

17 Jul '04

While your looking at CW, might you find the time to look a little bit into the serialization library build problems. The error message is pretty bizarre so I don't think it can be addressed without having CW installed on ones machine. Thanks, Robert Ramey

2 1

Re:Re: [boost] Boost Serialization Tests Status
by Robert Ramey 17 Jul '04

17 Jul '04

Martin Wille wrote: >> c) I don't think that gcc 2.95 can be used with the serialization library. >> The error messages seem to indicate this gcc doesn't have templated streams >> and the serialization library requires them. Perhaps some combination of >> gcc 2.95 - stlPort might work. I will exclude markup to skip the vanilla >> gcc 2.5 tests. >That's correct. The standard library implementation shipped with gcc-2 >is very limit with respect to streams: no templates, no locales, etc. >I'll remove the intel-8 results again. This looks very much like there >were stale .o files from the time when I didn't have enough disk space. >gcc-2 is not supported by Spirit. I planning to make Spirit 1.6.1 >available for the tests. Note that so far I know that spirit is only required for borland, msvc 6 and msvc 7.0. It's NOT needed for gcc 3.x. It might well be required for Intel 7.1 - I don't know. Robert Ramey

3 2

Re:Re: [boost] Boost Serialization Tests Status
by Robert Ramey 17 Jul '04

17 Jul '04

>I was talking about gcc-2.95.3, which is not supported by Spirit 1.8 > (you wrote about testing Serialization against gcc 2.95.3-stlport). >Intel 7.1 works fine with Spirit. I checked in changes that should make the demo tests pass. This weekend I'm going to experiment some with msvc-stlport and gcc-stlport. Robert Ramey

1 0

graph/subgraph: end iterator dereferenced
by Guillaume Melquiond 17 Jul '04

17 Jul '04

Hi, Line 189 of subgraph.hpp is: return std::make_pair((*i).second, i != m_local_vertex.end()); Consequently iterator i is dereferenced even when it is equal to m_local_vertex.end(). So here comes a patch. When *i is not valid, the patch simply returns u_global (the closest vertex_descriptor available to the code), another value may make better sense (but since the value is not supposed to be used). Regards, Guillaume

2 2

Boost Serialization Tests Status
by Robert Ramey 17 Jul '04

17 Jul '04

In review the test compiler status tables things are looking very much better. There a number of pending issues: a) test_demo and others are failing at runtime in both gcc and vc environments. They pass on my machine. In checking the code in example/demo I come upon the following: void save_schedule(const bus_schedule &s){ // make an archive std::ofstream ofs("../example/demofile.txt"); boost::archive::text_oarchive oa(ofs); oa << s; } void restore_schedule(bus_schedule &s) { // open the archive std::ifstream ifs("../example/demofile.txt"); boost::archive::text_iarchive ia(ifs); // restore the schedule from the archive ia >> s; } Which in light or our test strikes me as suspicious. It makes a couple of presumptions which I don't know are really true: 1) that the current directory while the test is being run is boost/libs/serialization/test and that the directory 2) boost/libs/serialization/example has it permissions set to permit file creation. Upon reflection it seems that there is no reason to suppose these to be true. I wonder if someone could check to see if this is the problem. Meanwhile I'll investigate what it would take to change the demos so that this is not a problem. b) in several cases it seems that there is a build configuration issue as it relates to multi-threading libraries. This might be an issue with intel 8.0, and gcc 3.4.1 builds. c) I don't think that gcc 2.95 can be used with the serialization library. The error messages seem to indicate this gcc doesn't have templated streams and the serialization library requires them. Perhaps some combination of gcc 2.95 - stlPort might work. I will exclude markup to skip the vanilla gcc 2.5 tests. d) I'm hoping that the metacomm test setup can make spirit 1.61 available and set SPIRIT_ROOT accordingly. This would resolve most of the issues with vc 6.0, 7.0, and borland. Robert Ramey

3 2

Re:[boost] Serialization and tmpnam
by Robert Ramey 17 Jul '04

17 Jul '04

Guillaume Melquiond wrote: >I see the serialization library uses "tmpnam" quite a lot. I don't know >what the status of this function is on other operating system. But on >GNU/Linux at least (and I suppose it is the same for any POSIX system), it >is considered to be bad practice [1]. Such a bad practice that the linker >ld is especially programed to complain whenever somebody uses this >function. Moreover, I see that Borland and Microsoft compilers "have brain->dead tmpnam functions" [2] so a replacement was needed. >So it may be a good idea to completely remove the function "tmpnam" from >the Serialization library and use a saner replacement instead. This way, >the library tests would compile without any complaint from the linker on >Linux. I need this functionality to run the tests. What is the best way to go about it? Robert Ramey

8 7

Borland const/partial specialization weirdness?
by Doug Gregor 16 Jul '04

16 Jul '04

I'm rather confused over the tuple_test_bench failure in Borland 5.6.4: http://www.boost.org/regression-logs/cs-win32_metacomm/developer/output/bin… Borland supports partial specialization, but I seem to remember some weirdness with its handling of cv-qualifiers in partial specializations. Does anyone know if this is the case, or how the weirdness goes? Doug

2 1

Scalar.H, tiny addition
by Neal D. Becker 16 Jul '04

16 Jul '04

I found numeric::ublas::promote_traits to be pretty useful. This tiny addition is also useful to go the other direction: #include <complex> template<typename T> struct Scalar { typedef T type; }; template<typename T> struct Scalar<std::complex<T> > { typedef T type; };

2 1

Suggestion for iterator_adaptor
by Fredrik Blomqvist 16 Jul '04

16 Jul '04

Hi Wouldn't it be convenient if iterator_adaptor provided a protected "self typedef" for use by client code? In particular I'm thinking of the constructor case that basically always is feeding an iterator to the iterator_adaptor baseclass, thus needing its explicit type. (In most examples and tests this typedef is manually created as a 'super_t' for example). Having a predefined type would reduce the amount of boilerplate code and the risk of getting out-of-sync with the declaration. I suggest a name something like 'iterator_adaptor_t' instead of 'super_t' to lessen name-clash possibility. I'm a bit confused why I haven't seen this discussed previously though. Hope I'm not missing something (tm).. ;-) Regards // Fredrik Blomqvist

4 9

pdf files in libs/iterator/doc
by Janusz Piwowarski 16 Jul '04

16 Jul '04

Hello, These files are not marked as binary: M libs/iterator/doc/iterator_concepts.pdf M libs/iterator/doc/iterator_traits.pdf Regards, Janusz

2 1

namespace symbol injection
by François Dumont 16 Jul '04

16 Jul '04

Hello I am testing boost 1.31.0 build under MSVC6 SP5 using STLport 5.0 RC1. In libs/filesystem/src/operations_posix_windows.cpp strcmp, remove and rename symbols are imported within std namespace before being defined (check comment next to the cstdio file inclusion). According the comments in boost/config/stdlib/stlport.hpp STLport do not grant all the necessary symbols within std. If there are others than the one fixed in this header don't hesitate to report on the STLport forum. Bests.

1 0

Re: [boost] Regression Tests, Boost.Serialization
by Robert Ramey 16 Jul '04

16 Jul '04

>BTW, I had to remove the line > <runtime-link>static >from the serialization/test/Jamfile to get the serializiation >regression tests to link on my Linux machine. With g++ this was > adding a -static which was apparently making it not find libstd++. Hmm - no other gcc setup required this. Might this indicate that a tweak is necessary somewhere in config gcc/linux/mandrake/? Combination> This brings up an enduring mystery to me. Here is the key part of the jamfile from the build directory. lib boost_serialization : ## sources ## ../src/$(SOURCES).cpp : ## requirements ## <msvc><*><include>$(SPIRIT_ROOT) <borland><*><include>$(SPIRIT_ROOT) <borland-5.5.1><*><include>$(SPIRIT_ROOT) <borland-5.6.4><*><include>$(SPIRIT_ROOT) <sysinclude>$(BOOST_ROOT) <borland><*><cxxflags>"-w-8080 -w-8071 -w-8057" <msvc><*><cxxflags>-Gy <vc7><*><cxxflags>-Gy <vc7.1><*><cxxflags>-Gy <define>BOOST_TEST_NO_AUTO_LINK=1 : ## default-build <runtime-link>static <threading>single/multi ; I set default-build based on - I don't remember. I did horse around with it to get it in sync with with my MSVC IDE settings so I could inter-operate with MSVC IDE and bjam. This was very helpful for development. However, I really don't know that the build should even specify a default. Is this a default or does this override some other default build setting. That is if I just leave it out do I get no build at all or what. I did spend a little time perusing the included JAM files - but that's a mind bending exercise for "the rest of us". Would think I would just leave off the default build and let the upper level test/build build what it wants. Of course then is a silently morphing side-effect which I'm generally against. I don't believe the current test results displayed reflect the true current state of the serialization system. My results are: a) I've tested borland 5.5.1, 5.60, VC 6.0 with good results. Test results show failure for these platforms because the test setup doesn't make spirit 1.61 available which is a requirement for these platforms. b) I've tested VC 7.1 and gcc 3.3 under cygwin. VC 7.1 Is 100 % passing. Gcc under cygwin passes all tests except those requiring wide char i/o which is not supported on this platform. The table generates "fail" for these tests but that's not really accurate. c) Christophe has 100% passing on linux with gcc 3.4.1 . (gcc 3.4.0 had a show stopping issue which was easiest to address by upgrading. Unknown results: a) gcc 3.3.? on linux - I would expect 100% here. No results available pending the disk space issue. b) a) gcc 3.3.? on linux/mandrake - see above. Problems: a) Macos/Darwin. i) lots of tests passing ii) some confusion as to whether wide char i/o is supported here iii) a couple of run failures that need to be looked at with a debugger. Any volunteer? b) Comeau - a compiler issue with non-intrusive serialization. Set aside for now. c) IBM C++ - a comple issue re-interator traits. Since these tests are run very infrequently, its almost hopeless to address by trial and error. d) CWPro - compile issue - size_t not recognized? Clearly this needs an expert. e) Intel 7.1 - I had Intel 8.0 passing 100% before my eval license exprired. I can't fix this from my own machine. Needs an expert - or my own copy of intel 7.1. I'm sure this is easily fixable given that msvc 6.0 works pretty well. f) HP - very bizarre compilation error. I don't know but I suspect this would be the tip of an ice berg. Needs an expert. So - there you have it - In my view test results of the serialization library are not out of line from those of other platforms. Also the fact that there are more combinations tested perhaps brings to fore more issues than with other libraries. I would suggest we keep flogging away at it until just before the branch is made. That would be a good time to make a final decision. Robert Ramey

2 1

test library tests broken
by David Abrahams 16 Jul '04

16 Jul '04

Gennadiy, did you forget to check in result_report_test.pattern and errors_handling_test.pattern? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

Serialization Menu
by David Abrahams 16 Jul '04

16 Jul '04

We have a kind of policy against using scripting in our library doc pages, mostly because in the past scripts have caused major portability or usability problems. I personally love the menu on the left of the serialization lib docs page, but if it uses scripts and we can't really be assured that they'll work everywhere, it probably ought to be removed. There are alternatives that might actually be more usable: http://article.gmane.org/gmane.comp.lib.boost.documentation/389 -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

6 12

Re:Re: [boost] Regression Tests, Boost.Serialization
by Robert Ramey 16 Jul '04

16 Jul '04

>Martin Wille wrote: >> Any other suggestions? >Would it be viable to modify the build system such that test binaries which >ran successfully get stripped after they ran? Having the then unneeded >debug symbols removed would help a lot. Why stop there. Maybe a tweak in the build system could implement the option to remove the executable after the test is run. After we have the results we don't need it. It would have to be an option as I like to debug failed test executables. Robert Ramey

2 1

Bibliography update (patch)
by Fredrik Blomqvist 16 Jul '04

16 Jul '04

Attached a patch for bibliography.html Contains several additions like Beman's MSDN article, Thomas Witt's ACCU presentation and Dave's and Aleksey's new book. Regards // Fredrik Blomqvist begin 666 bibliography.patch M26YD97@Z(&UO<F4O8FEB;&EO9W)A<'DN:'1M; T*/3T]/3T]/3T]/3T]/3T] M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T] M/3T]/3T]/0T*4D-3(&9I;&4Z("]C=G-R;V]T+V)O;W-T+V)O;W-T+VUO<F4O M8FEB;&EO9W)A<'DN:'1M;"QV#0IR971R:65V:6YG(')E=FES:6]N(#$N-@T* M9&EF9B M=2 M<C$N-B!B:6)L:6]G<F%P>2YH=&UL#0HM+2T@;6]R92]B:6)L M:6]G<F%P>2YH=&UL"3(V($9E8B R,# T(#$P.C,U.C(W("TP,# P"3$N-@T* M*RLK(&UO<F4O8FEB;&EO9W)A<'DN:'1M; DQ-2!*=6P@,C P-" Q,CHU-SHQ M,B M,# P, T*0$ @+3(T+#<@*S(T+#<@0$ -"B )"0D\02!H<F5F/2(C4')I M;G1?;65N=&EO;G,B/E!R:6YT(&UE;G1I;VYS(&]F($)O;W-T(&]R($)O;W-T M($QI8G)A<FEE<SPO03X\8G(^#0H@"0D)/$$@:')E9CTB(T]N;&EN95]M96YT M:6]N<R(^3VYL:6YE(&UE;G1I;VYS(&]F($)O;W-T(&]R($)O;W-T($QI8G)A M<FEE<SPO03X\8G(^#0H@"0D)/$$@:')E9CTB(W5P9&%T92(^2&]W('1O('5P M9&%T92!T:&ES('!A9V4\+T$^/&)R/@T*+2 @(" @(" @(" @(#QA(&AR968] M(B-!8VMN;W=L961G96UE;G1S(CY!8VMN;W=L961G96UE;G1S/"]A/CPO<#X- M"BL)"0D\82!H<F5F/2(C06-K;F]W;&5D9V5M96YT<R(^06-K;F]W;&5D9V5M M96YT<SPO83X\+W ^#0H@"0D\:#(^/&$@;F%M93TB4')I;G1?<'5B;&EC871I M;VYS(CY0<FEN="!P=6)L:6-A=&EO;G,\+V$^(&%B;W5T($)O;W-T(&]R($)O M;W-T( T*( D)"4QI8G)A<FEE<SPO:#(^#0H@"0D\=&%B;&4@<W1Y;&4](D)/ M4D1%4BU#3TQ,05!313H@8V]L;&%P<V4B(&)O<F1E<D-O;&]R/2(C,3$Q,3$Q M(B!C96QL4&%D9&EN9STB-2(@=VED=&@](C$P,"4B#0I 0" M-3,L-R K-3,L M-R! 0 T*( D)"0D)2F5R96UY(%-I96LL($QI92U1=6%N($QE92!A;F0@06YD M<F5W($QU;7-D86EN92P@/&D^5&AE($)O;W-T($=R87!H($QI8G)A<GD\+VD^ M+B -"B )"0D)"4%D9&ES;VXM5V5S;&5Y+" R,# R+B!)4T).(# M,C Q+3<R M.3$T+3@N(#QA(&AR968](FAT=' Z+R]W=W<N87=L+F-O;2]C<V5N9R]T:71L M97,O,"TR,#$M-S(Y,30M."(^#0H@"0D)"0D)=W=W+F%W;"YC;VTO8W-E;F<O M=&ET;&5S+S M,C Q+3<R.3$T+3@\+V$^#0HM"0D)"0D\4#Y386UP;&4@8VAA M<'1E<B S.B \02!H<F5F/2)H='1P.B\O=&EN>75R;"YC;VTO,C0V-C8B/G1I M;GEU<FPN8V]M+S(T-C8V/"]!/CPO4#X-"BL)"0D)"3Q0/E-A;7!L92!C:&%P M=&5R.B \02!H<F5F/2)H='1P.B\O=&EN>75R;"YC;VTO,C0V-C8B/G1I;GEU M<FPN8V]M+S(T-C8V/"]!/CPO4#X-"B )"0D)/"]T9#X-"B )"0D\+W1R/@T* M( D)"3Q44CX-"D! ("TY-BPQ," K.38L,3D@0$ -"B )"0D)"0E,:6)R87)Y M.B!);FQI;F4@4&%R<VEN9R!I;B!#*RL\+VD^+"!#+T,K*R!5<V5R<R!*;W5R M;F%L+"!397!T96UB97(L(#(P,#,L( T*( D)"0D)5F]L+B R,2P@27-S=64@ M.2P@<&%G92 R,BX\+U1$/@T*( D)"3PO5%(^#0HM(" @(" @(" @(" @(" @ M(" @(" @(" @/%12/@T**PD)"3Q44CX-"B )"0D)/%1$('9!;&EG;CTB=&]P M(B!A;&EG;CTB;&5F="(@=VED=&@](C$V)2(^/&(^6SQA(&YA;64](DMA<FQS M<V]N7S S(CY+87)L<W-O;B P,SPO83Y=/"]B/CPO5$0^#0HM"0D)"3Q41"!V M06QI9VX](G1O<"(@86QI9VX](FQE9G0B('=I9'1H/2(X-"4B/D)J]G)N($MA M<FQS<V]N+" \:3Y,86UB9&$@17AP<F5S<VEO;G,@)B!#*RL\+VD^+"!#+T,K M*R!5<V5R<R!*;W5R;F%L+"!$96-E;6)E<BP@,C P,RP@#0HM"0D)"0E6;VPN M(#(Q+"!)<W-U92 Q,BP@<&%G92 R,"X\+U1$/@T**PD)"0D\5$0@=D%L:6=N M/2)T;W B(&%L:6=N/2)L969T(B!W:61T:#TB.#0E(CY":O9R;B!+87)L<W-O M;BP@/&D^3&%M8F1A($5X<')E<W-I;VYS("9A;7 [( T**PD)"0D)"4,K*SPO M:3XL($,O0RLK(%5S97)S($IO=7)N86PL($1E8V5M8F5R+" R,# S+"!6;VPN M(#(Q+"!)<W-U92 Q,BP@<&%G92 R,"X\+U1$/@T**PD)"3PO5%(^#0HK"0D) M/%12/@T**PD)"0D\5$0@=D%L:6=N/2)T;W B(&%L:6=N/2)L969T(B!W:61T M:#TB,38E(CX\8CY;/&$@;F%M93TB06)R86AA;7,M1W5R=&]V;WE?,#0B/D%B M<F%H86US+4=U<G1O=F]Y( T**PD)"0D)"0DP-#PO83Y=/"]B/CPO5$0^#0HK M"0D)"3Q41"!V06QI9VX](G1O<"(@86QI9VX](FQE9G0B('=I9'1H/2(X-"4B M/D1A=FED($%B<F%H86US(&%N9"!!;&5K<V5Y($=U<G1O=F]Y+" \:3Y#*RL@ M#0HK"0D)"0D)5&5M<&QA=&4@365T87!R;V=R86UM:6YG.B!#;VYC97!T<RP@ M5&]O;',L(&%N9"!496-H;FEQ=65S(&9R;VT@0F]O<W0@86YD($)E>6]N9#PO M:3XL( T**PD)"0D)061D:7-O;B!797-L97DL($YO=F5M8F5R+" R,# T+B \ M02!H<F5F/2)H='1P.B\O8F]O<W0M8V]N<W5L=&EN9RYC;VTO;7!L8F]O:R\B M/F)O;W-T+6-O;G-U;'1I;F<N8V]M+VUP;&)O;VLO/"]!/@T**PD)"0D)/% ^ M*%1W;R!S86UP;&4@8VAA<'1E<G,@87)E(&%V86EL86)L92!A="!T:&4@;&]C M871I;VX@86)O=F4I/"]0/@T**PD)"0D\+U1$/@T*( D)"3PO5%(^#0H@"0D\ M+W1A8FQE/@T*( D)/&@R/CQA(&YA;64](D]N;&EN95]P=6)L:6-A=&EO;G,B M/D]N;&EN92!P=6)L:6-A=&EO;G,\+V$^(&%B;W5T($)O;W-T(&]R($)O;W-T M( T*0$ @+3$R,RPX("LQ,S(L."! 0 T*( D)"3Q44CX-"B )"0D)/%1$('9! M;&EG;CTB=&]P(B!A;&EG;CTB;&5F="(@=VED=&@](C$V)2(^/&(^6SQA(&YA M;64](D)R;W=N96QL7S R(CY"<F]W;F5L;" P,CPO83Y=/"]B/CPO5$0^#0H@ M"0D)"3Q41"!V06QI9VX](G1O<"(@86QI9VX](FQE9G0B('=I9'1H/2(X-"4B M/D1A=FED($)R;W=N96QL+" \:3Y#*RL@5&5C:&YI<75E<R!F;W(@#0HM"0D) M"0D)5&]M;W)R;W<@5&AA="!#86X@8F4@26UP;&5M96YT960@5&]D87D@*&$N M:RYA+B!";V]S=&EN9R!Y;W5R($-O9&4I/"]I/BX@3E=#4% L($YO=F5M8F5R M(#$S+" R,# R+B -"BT)"0D)"0D\02!H<F5F/2)H='1P.B\O=W=W+FYW8W!P M+F]R9R]-965T:6YG<R\R,# R+S$Q+FAT;6PB/G=W=RYN=V-P<"YO<F<O365E M=&EN9W,O,C P,B\Q,2YH=&UL/"]!/CPO5$0^#0HK"0D)"0D)5&]M;W)R;W<@ M5&AA="!#86X@8F4@26UP;&5M96YT960@5&]D87D@*&$N:RYA+B!";V]S=&EN M9R!Y;W5R($-O9&4I/"]I/BX@#0HK"0D)"0E.5T-04"P@3F]V96UB97(@,3,L M(#(P,#(N(#Q!(&AR968](FAT=' Z+R]W=W<N;G=C<' N;W)G+TUE971I;F=S M+S(P,#(O,3$N:'1M;"(^=W=W+FYW8W!P+F]R9R]-965T:6YG<R\R,# R+S$Q M+FAT;6P\+T$^/"]41#X-"B )"0D\+U12/@T*( D)"3Q44CX-"B )"0D)/%1$ M('9!;&EG;CTB=&]P(B!A;&EG;CTB;&5F="(@=VED=&@](C$V)2(@:&5I9VAT M/2(S,B(^/&(^6SQA(&YA;64](D%B<F%H86US7S S82(^06)R86AA;7,@#0I M0" M,34T+#8@*S$V,RPQ-R! 0 T*( D)"0D\5$0@=D%L:6=N/2)T;W B(&%L M:6=N/2)L969T(B!W:61T:#TB.#0E(CY*97)E;7D@1RX@4VEE:RP@/&D^02!" M;V]S="!'<F%P:"!,:6)R87)Y( T*( D)"0D)"51U=&]R:6%L/"]I/BX@26YF M;W)M250L($UA<F-H(#$L(#(P,#(N(#Q!(&AR968](FAT=' Z+R]T:6YY=7)L M+F-O;2\R<V$T<R(^=&EN>75R;"YC;VTO,G-A-',\+T$^/"]41#X-"B )"0D\ M+U12/@T**PD)"3Q44CX-"BL)"0D)/%1$('9!;&EG;CTB=&]P(B!A;&EG;CTB M;&5F="(@=VED=&@](C$V)2(^/&(^6SQA(&YA;64](D1A=V5S7S T(CY$87=E M<R P-#PO83Y=/"]B/CPO5$0^#0HK"0D)"3Q41"!V06QI9VX](G1O<"(@86QI M9VX](FQE9G0B('=I9'1H/2(X-"4B/D)E;6%N($1A=V5S+" \:3Y";V]S="!F M;W(@5FES=6%L($,K*R -"BL)"0D)"0E$979E;&]P97)S/"]I/BX@35-$3BP@ M36%Y(#$W+" R,# T+B \02!H<F5F/2)H='1P.B\O=&EN>75R;"YC;VTO,FQZ M>6@B/G1I;GEU<FPN8V]M+S)L>GEH/"]!/CPO5$0^#0HK"0D)/"]44CX-"BL) M"0D\5%(^#0HK"0D)"3Q41"!V06QI9VX](G1O<"(@86QI9VX](FQE9G0B('=I M9'1H/2(Q-B4B/CQB/EL\82!N86UE/2)7:71T7S T(CY7:71T(# T/"]A/ET\ M+V(^/"]41#X-"BL)"0D)/%1$('9!;&EG;CTB=&]P(B!A;&EG;CTB;&5F="(@ M=VED=&@](C@T)2(^5&AO;6%S(%=I='0L(#QI/E1H92!";V]S="!)=&5R871O M<B!,:6)R87)Y/"]I/BX@#0HK"0D)"0E!0T-5(%-P<FEN9R!#;VYF97)E;F-E M+" R,# T+B \02!H<F5F/2)H='1P.B\O=W=W+F%C8W4N;W)G+V-O;F9E<F5N M8V4O<')E<V5N=&%T:6]N<R]7:71T7RU?0F]O<W1?271E<F%T;W)?3&EB<F%R M>2YP9&8B/@T**PD)"0D)"7=W=RYA8V-U+F]R9R]C;VYF97)E;F-E+W!R97-E M;G1A=&EO;G,O5VET=%\M7T)O;W-T7TET97)A=&]R7TQI8G)A<GDN<&1F/"]! M/CPO5$0^#0HK"0D)/"]44CX-"B )"3PO=&%B;&4^#0H@"0D\:#(^/&$@;F%M M93TB4')I;G1?;65N=&EO;G,B/E!R:6YT(&UE;G1I;VYS/"]A/B!O9B!";V]S M="!O<B!";V]S="!,:6)R87)I97,\+V@R/@T*( D)/'1A8FQE('-T>6QE/2)" M3U)$15(M0T],3$%04T4Z(&-O;&QA<'-E(B!B;W)D97)#;VQO<CTB(S$Q,3$Q M,2(@8V5L;%!A9&1I;F<](C4B('=I9'1H/2(Q,# E(@T*0$ @+3$X-RPW("LR M,#<L-R! 0 T*( D)"0D\+U1$/@T*( D)"3PO5%(^#0H@"0D)/%12/@T*+0D) M"0D\5$0@=D%L:6=N/2)T;W B(&%L:6=N/2)L969T(B!W:61T:#TB,38E(CX\ M8CY;/&$@;F%M93TB2'EL<V]P+5-U='1E<E\P,2(^2'EL<V]P+5-U='1E<B P M,3PO83Y=/"]B/CPO5$0^#0HK"0D)"3Q41"!V06QI9VX](G1O<"(@86QI9VX] M(FQE9G0B('=I9'1H/2(Q-B4B/CQB/EL\82!N86UE/2)(>7-L;W M4W5T=&5R M7S Q(CY(>7-L;W M4W5T=&5R(# Q/"]A/ET\+V(^/"]41#X-"B )"0D)/%1$ M('9!;&EG;CTB=&]P(B!A;&EG;CTB;&5F="(@=VED=&@](C@T)2(^2FEM($AY M<VQO<"!A;F0@2&5R8B!3=71T97(L(#QI/D-O;G9E<G-A=&EO;G,Z( T*( D) M"0D)"4DG9"!(;VQD($%N>71H:6YG(&9O<B!9;W4\+VD^+B!#+T,K*R!5<V5R M<R!*;W5R;F%L+"!$96-E;6)E<BP@,C P,2X@/$$@:')E9CTB:'1T<#HO+W=W M=RYC=6HN8V]M+V1O8W5M96YT<R]S/3<Y.#@O8W5J8V5X<#$Y,3)H>7-L;W O M(CX-"B )"0D)"0EW=W<N8W5J+F-O;2]D;V-U;65N=',O<STW.3@X+V-U:F-E M>' Q.3$R:'ES;&]P+SPO03X-"D! ("TQ.34L-R K,C$U+#<@0$ -"B )"0D) M/"]41#X-"B )"0D\+U12/@T*( D)"3Q44CX-"BT)"0D)/%1$('9!;&EG;CTB M=&]P(B!A;&EG;CTB;&5F="(@=VED=&@](C$V)2(^/&(^6SQA(&YA;64](DAY M;'-O<"U3=71T97)?,#(B/DAY;'-O<"U3=71T97(@,#(\+V$^73PO8CX\+U1$ M/@T**PD)"0D\5$0@=D%L:6=N/2)T;W B(&%L:6=N/2)L969T(B!W:61T:#TB M,38E(CX\8CY;/&$@;F%M93TB2'ES;&]P+5-U='1E<E\P,B(^2'ES;&]P+5-U M='1E<B P,CPO83Y=/"]B/CPO5$0^#0H@"0D)"3Q41"!V06QI9VX](G1O<"(@ M86QI9VX](FQE9G0B('=I9'1H/2(X-"4B/DII;2!(>7-L;W @86YD($AE<F(@ M4W5T=&5R+" \:3Y#;VYV97)S871I;VYS.B -"B )"0D)"0E'971T:6YG('1O M('1H92!0;VEN=#PO:3XN($,O0RLK(%5S97)S($IO=7)N86PL($IU;'DL(#(P M,#(N(#Q!(&AR968](FAT=' Z+R]W=W<N8W5J+F-O;2]D;V-U;65N=',O<STW M.3@Q+V-U:F-E>' R,# W:'ES;&]P+R(^#0H@"0D)"0D)=W=W+F-U:BYC;VTO M9&]C=6UE;G1S+W,]-SDX,2]C=6IC97AP,C P-VAY<VQO<"\\+T$^#0I 0" M M,S P+#8@*S,R,"PQ,R! 0 T*( D)"0D)/"]0/@T*( D)"0D\+U1$/@T*( D) M"3PO5%(^#0HK"0D)/%12/@T**PD)"0D\5$0@=D%L:6=N/2)T;W B(&%L:6=N M/2)L969T(B!W:61T:#TB,38E(CX\8CY;/&$@;F%M93TB4W1E:6Y?,#0B/E-T M96EN(# T/"]A/ET\+V(^/"]41#X-"BL)"0D)/%1$('9!;&EG;CTB=&]P(B!A M;&EG;CTB;&5F="(@=VED=&@](C@T)2(^#0HK"0D)"0D\4#Y396)A<W1I86X@ M4W1E:6XL(#QI/DAO=R!T;R!U<V4@0F]O<W0@5&5S="!F;W(@875T;VUA=&5D M('1E<W1I;F<\+VD^+B R,# T+B \02!H<F5F/2)H='1P.B\O=W=W+FAP9G-C M+F1E+V)O;W-T=&5S="\B/@T**PD)"0D)"0EW=W<N:'!F<V,N9&4O8F]O<W1T M97-T+SPO03X\+U ^#0HK"0D)"3PO5$0^#0HK"0D)/"]44CX-"B )"3PO=&%B M;&4^#0H@"0D\:#(^2&]W('1O(#QA(&YA;64](G5P9&%T92(^=7!D871E/"]A M/B!T:&ES('!A9V4\+V@R/@T*( D)/' ^4&QE87-E(&AE;' @=7,@:V5E<"!T M:&ES('!A9V4@=7!D871E9" M('5S97)S(&-A;B!P;W-T(&YE=R!C:71A=&EO M;G,@=&\@=&AE( T*0$ @+3,R,BPQ,R K,S0Y+#$U($! #0H@"0D)/"]L:3X- M"B )"3PO=6P^#0H@"0D\:#(^/&$@;F%M93TB06-K;F]W;&5D9V5M96YT<R(^ M06-K;F]W;&5D9V5M96YT<SPO83X\+V@R/@T*+2 @(" @(" @/' ^1G)E9')I M:R!";&]M<79I<W0@<')O=FED960@;6%N>2!O9B!T:&4@:6YI=&EA;"!C:71A M=&EO;G,N/"]P/@T**PD)/' ^1G)E9')I:R!";&]M<79I<W0@<')O=FED960@ M;6%N>2!O9B!T:&4@:6YI=&EA;"!C:71A=&EO;G,N/"]P/@T*( D)/&AR/@T* M+0D)/' ^4F5V:7-E9 T*+2 @(" @(" @/"$M+7=E8F)O="!B;W0](E1I;65S M=&%M<"(@4RU4>7!E/2)%1$E4140B(%,M1F]R;6%T/2(E9" E0BP@)5DB('-T M87)T<W!A;B M+3XR-2!&96)R=6%R>2P@,C P-#PA+2UW96)B;W0@8F]T/2)4 M:6UE<W1A;7 B(&5N9'-P86X@:2UC:&5C:W-U;3TB-# T,#DB("TM/CPO<#X- M"BT)"3QP/JD@0V]P>7)I9VAT($)E;6%N($1A=V5S(#(P,#,\+W ^#0HK"0D\ M<#Y2979I<V5D( T**PD)"3PA+2UW96)B;W0@8F]T/2)4:6UE<W1A;7 B(%,M M5'EP93TB141)5$5$(B!3+49O<FUA=#TB)60@)4(L("59(B!S=&%R='-P86X@ M+2T^( T**PD)"3$U($IU;'DL(#(P,#0\(2TM=V5B8F]T(&)O=#TB5&EM97-T M86UP(B!E;F1S<&%N(&DM8VAE8VMS=6T](C0P-# Y(B M+3X\+W ^#0HK"0D\ M<#X-"BL)"0E#;W!Y<FEG:'0@0F5M86X@1&%W97,@,C P,SPO<#X-"B )"3QP M/E5S92P@;6]D:69I8V%T:6]N+"!A;F0@9&ES=')I8G5T:6]N(&%R92!S=6)J M96-T('1O('1H92!";V]S="!3;V9T=V%R92!,:6-E;G-E+" -"B )"0E697)S M:6]N(#$N,"X@*%-E92!A8V-O;7!A;GEI;F<@9FEL92 \02!H<F5F/2(N+B], M24-%3E-%7S%?,"YT>'0B/DQ)0T5.4T5?,5\P+G1X=#PO03X-"B )"0EO<B!C M;W!Y(&%T(#QA(&AR968](FAT=' Z+R]W=W<N8F]O<W0N;W)G+TQ)0T5.4T5? M,5\P+G1X="(^=W=W+F)O;W-T+F]R9R],24-%3E-%7S%?,"YT>'0\+V$^*3PO M<#X-"B )/"]B;V1Y/@T*+3PO:'1M;#X-"EP@3F\@;F5W;&EN92!A="!E;F0@ 3;V8@9FEL90T**SPO:'1M;#X-"@`` ` end

2 6

Re:Re: [boost] Regression Tests, Boost.Serialization
by Robert Ramey 16 Jul '04

16 Jul '04

>It might also be beneficial to allow finer grained results within a test >file. Let's say I have a test file stl_containers.cpp that tests >std::vector, std::list, etc. Now, if a compiler has a problem with one of >these (e.g. std::map) - if I understand the regression test system >correctly - it will mark this test as failed in the regression results and > a user >would assume that all the stl_containers would be unusable! That's the way it is now. That's why there are so many (too many) tests. About 20 tests for base services, void_cast, iterators, iteratorbase64, demo, etc. About 35 test for serialization facilities e.g. tracking, exporting, registering, stl::list, stl::vector, etc. These later are built/run for each archive type xml, wide xml, text, wide text and native binary. So this works out to about 20 + 35 * 5 = 190 (actually 209) * 5 compilers about 1000 test run/builds. Robert Ramey

1 0

Re:Re: [boost] Re: Serialization Menu
by Robert Ramey 16 Jul '04

16 Jul '04

>Robert Ramey wrote: >> I've just modified contents.html slightly so that the expand/collapse >> functionality is only enabled all of the following are true: >> >> a) scripting is supported by the browser >> b) scripting is not turned off >> c) the browser is either IE or Netscape >Please don't. As I've said, Konqueror has no problems whatsoever with your >JavaScript. Can't you make just special case for IE, and and single code >path for all other browsers? My concern was to address the issue raised by those such as yourself who felt that the javescript should be removed to be sure that its will work in all browsers. I feel this addresses that concern but still permits browsers on which the scripting has been test to use the collapse/expand functionality. What I have now is special case for IE and Netscape and no javascript for all other browsers. As far as I can tell, this should work for all browsers that support frames. If you've verified that Konqueror works well with the javascript then add it to the list in the javascript code. Then we can still have what we want and still maintain guaranteed compatibility on all browsers. Robert Ramey

1 0

RE: [boost] [config] _WIN32 question
by Ferdinand Prantl 16 Jul '04

16 Jul '04

Hi Volodya, > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Vladimir Prus [snip] > > Borland: __WIN32__ _WIN32 > > Digital Mars: _WIN32 > > GCC (MinG/W and Cygwin with -mno-cygwin): __MINGW32__ WIN32 _WIN32 > > __WIN32 __WIN32__ > > Metrowerks: _WIN32 > > Microsoft: _WIN32 > > It seems that _WIN32 is defined by all of them.... Yep, _WIN32 is enough from the hard-wired switches to be sure about the Win32 platform, at least for what have done all the time. I forgot Watcom, which defines _WIN32 __WINDOWS_386__ :-) but they have still a long way to compile boost.org... > > The macro WIN32 is meant to be a user-definable option how > to enforce > > a WIN32 code if a compiler does not define _WIN32. > > Ok. When is it needed, BTW? Well, you have caught me. Actually, I did not need to use it yet. I have it in my configuration just to be flexible waiting for such code or compiler... AFAIK, MSVS from some interesting reasons keeps to generate new wizards-made projects and makefiles with the macro WIN32, dunno why. They may have some old sources with both #ifdef _WIN32 #endif and #ifdef WIN32 #endif and it does not pay off to them to correct it, I do not know. I use -DWIN32 as well in my makefiles and PLATFORM_WIN32 = _WIN32 || WIN32 in headers even if _WIN32 alone should be always enough. > > And if you like, it is possible to do something like this > to be complete: > > > > BOOST_WIN32 : _WIN32 || WIN32 > > BOOST_WIN64 : _WIN64| WIN64 > > BOOST_WINDOWS : BOOST_WIN32 || BOOST_WIN64 > > Yea, I think this makes sense. Though _WIN64 is not used > anywhere in config yet. It will start shortly, as soon as someone with a fresh new x86-64 from AMD starts to play with the boost::filesystem :-) Today one should be careful with BOOST_WINDOWS and check the 64-bit compatibility, if the macro will mark general Windows platform. Ferda > - Volodya

1 0

RE: [boost] lexical_cast reviewed
by Michiel Salters 16 Jul '04

16 Jul '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org]On Behalf Of Jason > Sent: vrijdag 16 juli 2004 11:03 > To: boost(a)lists.boost.org > Subject: [boost] lexical_cast reviewed > > SOURCE CODE: > #include <sstream> > using namespace std; > class lexical_cast { > public: > template <typename Source> lexical_cast( const Source & source ) { > ss << source; > } > > template <typename Target> operator Target() { > Target target; > ss >> target; > return target; > } > private: > stringstream ss; > }; Not really lexical_cast, but useful nevertheless. Perhaps we could call it lexical_auto_cast. It could be more efficient to store a string instead, but I'm not sure. Regards, Michiel Salters This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

2 1

[1.32 release] Branch for release postponed -- Plea for help
by Aleksey Gurtovoy 16 Jul '04

16 Jul '04

Branch for release scheduled for today, July 16, will NOT be performed. The two main showstoppers are an unsatisfactory state of the main trunk (http://tinyurl.com/25ar3) and a further delayed MPL check-in. It's going to take at least a couple more days for me to deal with the latter, and it would be really appreciated if during that time somebody would volunteer to work on clearing up the regression picture; the more volunteers, the better! Many library maintainers are already doing a good job at it, but the previous experience shows that whole thing can be made significantly more efficient if people who have local access to particular compilers failing on particular libraries [of their interest] took a look at those failures and reported back the results of their finding/posted patches/ checked in fixes. If each of us with a little bit of familiarity with the codebase/free time on their hands would take care of only a single failure, it would already make an enormous difference. Needless to say, everyone who contributes to this is going to be acknowledged when the release is out. (And a warm "thank you" to everybody who is already investing their time and energy into this!) -- Aleksey Gurtovoy MetaCommunications Engineering

4 4

Optional patch
by Hugo Duncan 16 Jul '04

16 Jul '04

The following clears the unexpected failure for optional on borland-5.6.4 Index: optional.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/optional/optional.hpp,v retrieving revision 1.1 diff -w -u -r1.1 optional.hpp --- optional.hpp 7 Jul 2004 15:10:03 -0000 1.1 +++ optional.hpp 16 Jul 2004 13:11:36 -0000 @@ -347,7 +347,7 @@ reference_const_type dereference( internal_type const* p, is_reference_tag ) const { return p->get() ; } reference_type dereference( internal_type* p, is_reference_tag ) { return p->get() ; } - void destroy_impl ( is_not_reference_tag ) { get_ptr_impl()->T::~T() ; m_initialized = false ; } + void destroy_impl ( is_not_reference_tag ) { get_ptr_impl()->internal_type::~internal_type() ; m_initialized = false ; } void destroy_impl ( is_reference_tag ) { m_initialized = false ; } // If T is of reference type, trying to get a pointer to the held value must result in a compile-time error.

2 1

[multi_array] problems with metacomm reports?
by Joaquín Mª López Muñoz 16 Jul '04

16 Jul '04

Please see http://tinyurl.com/57s3l If you click on most of the red-marked tests, you'll find that the output seems to show that they actually pass!! Is there something wrong with the report generation tool? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

RE: [boost] [config] _WIN32 question
by Ferdinand Prantl 16 Jul '04

16 Jul '04

Hi Volodya, > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Vladimir Prus > [snip] > Does it mean I have to use the same conditional? Which > compilers define __WIN32__ or WIN32, but don't define _WIN32? > Shouldn't there be a single BOOST_WINDOWS macros to help in > this cases? The macro _WIN32 was originally hard-coded into the Microsoft compiler to recognize the platform. The other vendors took it the same way, but maybe because of rapid development in the early ages there are more underscored versions available... Here we are macros *32*, as they are defined: Borland: __WIN32__ _WIN32 Digital Mars: _WIN32 GCC (MinG/W and Cygwin with -mno-cygwin): __MINGW32__ WIN32 _WIN32 __WIN32 __WIN32__ Metrowerks: _WIN32 Microsoft: _WIN32 The macro WIN32 is meant to be a user-definable option how to enforce a WIN32 code if a compiler does not define _WIN32. Cygwin platform in POSIX mode is not a WIN32-compatible platform (no headers, no libraries), and thus their macros should mark a POSIX code, not Windows: GCC (Cygwin in POSIX mode): __CYGWIN__ __CYGWIN32__ > FWIW, filesystem defines such macro internally: > > # if !defined( BOOST_WINDOWS ) && !defined( BOOST_POSIX ) > # if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) > || defined(__CYGWIN__) > # define BOOST_WINDOWS > # else > # define BOOST_POSIX > # endif > # endif I like the single BOOST_XXX macro idea for all libraries, I would only delete __CYGWIN__, which defines POSIX compatibility. And if you like, it is possible to do something like this to be complete: BOOST_WIN32 : _WIN32 || WIN32 BOOST_WIN64 : _WIN64| WIN64 BOOST_WINDOWS : BOOST_WIN32 || BOOST_WIN64 Ferda > - Volodya

2 1

[1.32 release] TODO list synchronization
by Aleksey Gurtovoy 16 Jul '04

16 Jul '04

As we are coming closer to the branch-for-release date, I'd like to inquire developers working towards the release about the current status of their corresponding TODO items below. Simply replying to this message and saying "Done", "Not done, will be done by date X", "Abandoned" or whatever you wish to say on each of the items would be more than fine. > Circular Buffer > /////////////// > > Pavel Vozenilek writes: > > I asked Jan Galdun and he will try to make circular_buffer available > for 1.32. > > > Date-Time > ///////// > > Jeff Garland writes: > > And while I'm on the subject date-time plans for release, the only 'major > issue' for this release is whether we are switching to boost-book for this > release. We would like to, but if we don't make it we will do it for the next > release. > > > Iterators > ///////// > > David Abrahams writes: > > There are a couple of things that ideally I would like to handle, but > which I am not promising (yet): > > 1. Minor adjustments to code in the iterators library > 2. Iterators library doc fixes > > > MPL > /// > > New version of the library will be checked in the main trunk before July 11. Not done yet; July 15 is the new target. > > > Multi-Index > /////////// > > Joaquín Mª López Muñoz writes: > > Current status: commited in the CVS since 6 weeks or > so. Regression tests are OK for all the compilers that > I intend to support. If someone is interested in some > other compiler being supported, please contact me. > > Pending issues: > #1 Minor updates to the docs. No big deal. > #2 Some changes related to the new defect macro > BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS > > These issues will be resolved way before the branching > date, I hope. > > > Numeric Conversions > /////////////////// > > Fernando Cacciola writes: > > In preparation for the upcoming 1.32 release I added this library to CVS. > The code and docs have been changed according to the extensive review > results. > I still need to extend the documentation adding examples and motivating > cases though, which I plan to do before the release. > > I haven't yet changed "boost/cast.hpp" to use the new stuff, I will as soon > as I see the code stablilized among different compilers. > > In the meantime, new users can use "boost/numeric/conversion/cast.hpp" which > contains the new version of numeric_cast<> > > > Program Options > /////////////// > > Vladimir Prus writes: > > 1. Add markup for the current failures on Windows. I've done all workarounds I > planned. > 2. Finally get some results on gcc2.95-stlport. I expect that the library > should work there, but due to Boost.Test failure I don't have any results. > 3. Try to make Sun compiler happy. I'm comitted a workaround some time ago, > but tests on Solaris were not run since then. > 4. Check dynamic linking on Windows. > > > Serialization > ///////////// > > Robert Ramey writes: > > I would very much like to see the serialization library in the 1.32 Release. > However, I'm not sure it will be possible to make the posted schedule. > > I have made all changes to address issues raised in the review. On my > personal machine I have passed tests for the compilers VC 7.1 VC 6, gcc 3.3. > Borland compiles (almost everything but requires some debug - it will pass > most tests) Comeau- compiles everthing - accept for a show stopping problem > I've been unable to resolve. My intention has been: > > a) post version compatible with 1.31 next week. > > b) build and test against the CVS tree on my computer > > c) check in > > In order to do this I need: > > a) authority to check in > > b) information on how to mark tests/compilers known to fail. > > c) I have a couple of questions that I need an expert opinion on. > > i) the first one is that in order to work, versions for vc 6.0 and > borland need to be compiled with spirit 1.61. So the a special > environmental variable indicating the directory path where this version of > spirit is located on the testing machine. SPIRIT_ROOT. This variable has > to be set when serialization libraries are built for these compilers. > > I should say I'm more than a little bit concerned about changes to mpl and > iterators. I'm very much aware of the delays and difficulties associated > with the 1.31 release - and it didn't even include this package. > > So I would like to continue on the path I've established above and we'll see > where things stand July 16 when/if you are ready to branch for release. > > > String Algorithms > ///////////////// > > Pavol Droba writes: > > I have few outstanding issues to fix, but they are mostly related to > the documentation. I think, I can manage it. > > As it seems, that the Range library will not make it to this release, > I will use the internal versions of facilities that are currently in the string_algo lib. > > So my todo list is as follows: > > 1) Finish the documentation > - Add functions list > - Add exception specifications > - Cleanup > > 2) Fix examples > 3) If there will be time, improve find_iterator > 4) Fix possible regressions. > > > Questions: > - I have posted some requestes/bugs on the boost-doc list. What is the status > of this. Will they be fixed before release? > > - According to metacom's tables regex is failing on comeau a so string_algo regex > test. Is this a setup or regex problem? > > - There is an problem with Intel compiler, split tests are failing and I cannot figureout > why. The message is very vague. Could somebody with an access to this platform, > try to debug the cause of the problem? > > - In regards to the older compiler support. I cannot resonably support compilers, that I > don't have an access to. Therefor if somebody is interested to use string_algo library > with one of such compilers, I will need an active help with porting. > > > uBLAS > ///// > > Michael Stevens writes: > > The current status of uBLAS is that it has been relatively untouched in the > Boost CVS single 1.30.0. The active development takes place on a separate > CVS. > > Therefore now would be a good time to bring in the latest code which as some > quite significant improvements. The code is relatively stable and tested on > core compilers. > > Issues: > On exotic (old) compiler the code is relatively untested and expected to fail. > Therefore the real need with regard to 1.32 is to get feedback from extensive > regression testing results in good time. > > As ever the documentation could do with further work to bring it up to date > with the to be release version. Thanks in advance, -- Aleksey Gurtovoy MetaCommunications Engineering

10 26

lexical_cast reviewed
by Jason 16 Jul '04

16 Jul '04

after fidling around with template functions i discovered you could write lexical_cast without any template arguments _required_. Also I neat little C-Style cast although no one is probably interested in using that. Anyways the syntax is as followed for both: // lexical cast improved: string str = lexical_cast( 3.1415f ); int i = lexical_cast( "12345" ); // C-style cast fun! string str = (cstyle_cast)3.1415f; int i = (cstyle_cast)"12345"; I would say that anyone already using lexical_cast would'nt have a problem with the improved one. Let me know what you guys think and if we should implement that. -Jason SOURCE CODE: #include <sstream> using namespace std; class cstyle_cast { public: template <typename Source> cstyle_cast( const Source & source ) { ss << source; } template <typename Target> operator Target() { Target target; ss >> target; return target; } private: stringstream ss; }; class lexical_cast { public: template <typename Source> lexical_cast( const Source & source ) { ss << source; } template <typename Target> operator Target() { Target target; ss >> target; return target; } private: stringstream ss; }; int main() { string str1 = (cstyle_cast)3.141592f; string str2 = lexical_cast(3.141592f); }

2 1

RE: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 16 Jul '04

16 Jul '04

Guys, Could we please resist complicating interfaces when we do not have to? I personally consider an additional blocking parameter for something like try_lock excessive because it distorts try_lock into becoming scoped_lock. Let's keep different concepts different. Blocking in try_lock is an oxymoron -- try_lock cannot block because it is "try". The basic usages (covering about 80%) are: scoped_lock l(m); // Block until it locks. scoped_try_lock l(m); // Try (!) to lock. I'll check the result. scoped_timed_lock l(m, time); // Block until it locks or time runs out. I'll check the result. Simple and clean. The only functionality that I can see beyond that is when I have to only declare a lock but apply it later. Like: Void Foo() { scoped_lock l(m, do_not_lock); if (something) { l.lock(); // Can't declare here. ... } } For that purpose we'll need something like scoped_lock(mutex&, nolock_t); That's it. Isn't it? Alternatively we might consider making timed_lock our basic lock as scoped_lock and try_lock are merely border-cases (time=infinite and time=0 respectively). Then, scoped_lock and try_lock would be real refinements (convenience interfaces) of that general concept. V. Christopher Currie wrote: > Michael Glassford wrote: > > > To address these problems, I would like to redefine the lock concept > > constructors as follows (changes indicated with "^"): > > > > Definitions > > ----------- > > L: lock type > > l: lock variable (type L) > > m: mutex variable (appropriate Mutex type) > > s: initial lock state (enum type {NO_LOCK=0, LOCK=1}) > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > b: block? (enum type blocking_state {NON_BLOCKING=0, BLOCKING=1}) > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > Lock Concept > > ------------ > > L l(m,s) //Blocking lock if s > > L l(m) //Blocking lock > > > > > > TryLock Concept > > --------------- > > L l(m,s,b) //Lock if s; blocking if b > > ^ ^^^^^^^^^^^^^ > > L l(m,b) //Lock; blocking if b > > ^ ^^^^^^^^^^^^^ > > > > TimedLock Concept > > ----------------- > > L l(m,s,b) //Lock if s; blocking if b > > ^ ^^^^^^^^^^^^^ > > L l(m,t) //Blocking lock, failing if not obtained by time t > > > > I like this proposal, if for no other reason than the move to enums > makes the arguments clearer. A couple of points: Yes, I like LOCK and NO_LOCK better than true and false for the same reason. > TryLock: What would be the semantics of l(m, NO_LOCK, b)? In other > words, if you're not going to lock on construction, why specify a > blocking policy? The only reason is so that if you write l(m, LOCK, ...) you could also specify the blocking parameter. An expansion of Vladimir Batov's of using structs rather than enums could help here: struct nolock_t {}; nolock_t nolock; struct lock_t {}; lock_t lock; class TryLock { TryLock(TryMutex m, no_lock_t s) {...} TryLock(TryMutex m, lock_t s, blocking_t b) {...} } > L l(m, b) and L l(m, s) seem to cover the two > scenarios: either I don't want to lock, or I do and I need to specify > the blocking policy. > > TimedLock: I'm not sure I follow the reasons why TimedMutex refines > TryMutex. (This is a comment on the original design, not your specific > changed, but bear with me.) I think a timeout of zero seconds achieves > the same goal, even if TimedLock/TimedMutex don't implement the same > operations. > So I don't think that TimedLock needs a constructor that > takes a blocking argument, and ultimately I think TimedLock/TimedMutex > should refine Mutex/Lock, and not TryMutex/TryLock. > Also, the current implementation of TimedLock doesn't support a single > argument constructor, even though it is supposedly a refinement of > TryLock, which does. I'd like to see TimedLock implemented in such a way > that I could use it as if it were a simple Lock, which I currently cannot. > In summary, this is what I'd like to see: > > Lock Concept > --------------- > L l(m) //Blocking lock > L l(m,s) //Blocking lock if s > > TryLock Concept > --------------- > As Lock, *plus:* > L l(m,b) //Lock; blocking if b > > TimedLock Concept > ----------------- > As Lock (not TryLock), *plus:* > L l(m,t) //Blocking lock, failing if not obtained by time t > //If t == 0, acts as TryLock. > As I said in another post, I'll think about this some more. Thanks for taking the time to comment. Mike

15 169

ublas/traits.hpp not standalone
by Neal D. Becker 16 Jul '04

16 Jul '04

ublas/traits.hpp forgot to include some headers. Here is what happens: g++ -c -x c++ /usr/include/boost/numeric/ublas/traits.hpp /usr/include/boost/numeric/ublas/traits.hpp:1428: error: ISO C++ forbids declaration of `forward_iterator_base' with no type /usr/include/boost/numeric/ublas/traits.hpp:1428: error: template-id ` forward_iterator_base<std::forward_iterator_tag, I, T>' used as a declarator /usr/include/boost/numeric/ublas/traits.hpp:1428: error: syntax error before `; ' token /usr/include/boost/numeric/ublas/traits.hpp:1436: error: ISO C++ forbids declaration of `bidirectional_iterator_base' with no type /usr/include/boost/numeric/ublas/traits.hpp:1436: error: template-id ` bidirectional_iterator_base<std::bidirectional_iterator_tag, I, T>' used as a declarator /usr/include/boost/numeric/ublas/traits.hpp:1436: error: syntax error before `; ' token /usr/include/boost/numeric/ublas/traits.hpp:1443: error: ISO C++ forbids declaration of `bidirectional_iterator_base' with no type /usr/include/boost/numeric/ublas/traits.hpp:1443: error: template-id ` bidirectional_iterator_base<boost::numeric::ublas::sparse_bidirectional_iterator_tag, I, T>' used as a declarator /usr/include/boost/numeric/ublas/traits.hpp:1443: error: syntax error before `; ' token /usr/include/boost/numeric/ublas/traits.hpp:1451: error: ISO C++ forbids declaration of `random_access_iterator_base' with no type /usr/include/boost/numeric/ublas/traits.hpp:1451: error: template-id ` random_access_iterator_base<std::bidirectional_iterator_tag, I, T>' used as a declarator /usr/include/boost/numeric/ublas/traits.hpp:1451: error: syntax error before `; ' token /usr/include/boost/numeric/ublas/traits.hpp:1458: error: ISO C++ forbids declaration of `random_access_iterator_base' with no type /usr/include/boost/numeric/ublas/traits.hpp:1458: error: template-id ` random_access_iterator_base<boost::numeric::ublas::packed_random_access_iterator_tag, I, T>' used as a declarator /usr/include/boost/numeric/ublas/traits.hpp:1458: error: syntax error before `; ' token /usr/include/boost/numeric/ublas/traits.hpp:1465: error: ISO C++ forbids declaration of `random_access_iterator_base' with no type /usr/include/boost/numeric/ublas/traits.hpp:1465: error: template-id ` random_access_iterator_base<boost::numeric::ublas::dense_random_access_iterator_tag, I, T>' used as a declarator /usr/include/boost/numeric/ublas/traits.hpp:1465: error: syntax error before `; ' token

1 1

Re: [boost] Regression Tests, Boost.Serialization
by Reece Dunn 16 Jul '04

16 Jul '04

Martin Wille wrote: >Robert Ramey wrote: >>Jeff Garland wrote: >>>>Houston, we have a problem. >>[snip] >>It's a fact - running the bjam serialization test is going to consume 20 >>GB. > >The disk requirements can be changed. Stripping the test binaries >and removing the .o files already has been mentioned. Another >chance lies in merging similar (in terms of instantiated templates) >tests into one binary. It might also be beneficial to allow finer grained results within a test file. Let's say I have a test file stl_containers.cpp that tests std::vector, std::list, etc. Now, if a compiler has a problem with one of these (e.g. std::map) - if I understand the regression test system correctly - it will mark this test as failed in the regression results and a user would assume that all the stl_containers would be unusable! What I would like is to be able to group sets of tests (like in the unit tests), but to show a breakdown of those tests (e.g. for std::vector, std::deque, etc.) so that if one of these groups fail, the user can see that specific container doesn't work for a perticular compiler/platform. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

1 0

Boost.Test problem
by Joel de Guzman 16 Jul '04

16 Jul '04

Hi, I'm having some minor problems with Boost.Test. Using g++3.2, MinGW, I get: In file included from ../../../boost/test/included/unit_test_framework.hpp:20, from ../../../libs/spirit/test/actor/unit_test.cpp:9: ../../../libs/test/src/test_tools.cpp: In function `bool boost::test_tools::tt_detail::equal_and_continue_impl(const wchar_t*, const wchar_t*, boost::wrap_stringstream&, boost::unit_test::basic_cstring<const char>, unsigned int, boost::unit_test::log_level)': ../../../libs/test/src/test_tools.cpp:188: `wcscmp' undeclared in namespace ` std' unit_test.cpp is just: #include <boost/test/included/unit_test_framework.hpp> Any hints? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

6 24

Re:Re: [boost] Re: Serialization Menu
by Robert Ramey 16 Jul '04

16 Jul '04

Robert Ramey wrote: >Mattias Flodin wrote: >>> (ii) Requiring all documentation to support a no-script option. >>In think (ii) is an absolute requirement. I find myself using >>text-based browsers from time to time, especially when working across >>an SSH connection, and I get quite annoyed by some documentation sites >>that navigation exclusively though Javascript. I would hate for boost >>to go the same way. >>In addition to some text browsers not supporting Javascript at all, >>the CERT has on numerous occasions advised that Javascript be disabled >>in browsers such as IE for security reasons, and some companies make >>that a policy decision. > Actually I agree with this. I will change the serialization navigation > pane so that it works on browsers that don't support scripting. This > would leave the navigation pane but it would always be maximally expanded > for browsers that don't support it. I think that would fulfill the > requirement of making the documentation universally useable and still > permit us to use the facility we like most of the time. I've just modified contents.html slightly so that the expand/collapse functionality is only enabled all of the following are true: a) scripting is supported by the browser b) scripting is not turned off c) the browser is either IE or Netscape Under all other conditions, the navigator pane is displayed fully expanded with no graphic +/-/o buttons. The links to the actual doc pages work the same in all cases. I have tested this with Netscape with scripting enabled and disabled. I've tested with IE only with scripting enabled as I was unable to discover where to turn javascript off (or perhaps I did find it but it didn't work). If anyone wants to tweak this to enable this functionality for their favorite browser - be my guest. I would hope that almost everyone could find this solution satisfactory. Robert Ramey

2 1

Re:Re: [boost] Re: Serialization Menu
by Robert Ramey 16 Jul '04

16 Jul '04

Vladimir Prus wrote: >Jonathan Turkanis wrote: >> I think Robert's menu is very effective, and was hoping it represented >> a de facto relaxation of the no-script policy. >>I have some reservation >>1. It does not work very nice when image loading is turned off (as it is for me). >>2. It takes qutie a lot of screen space. Hmm - on IE and Navigator I can slide the frame all the way to the right and make the navigation window disappear. This also raise the question about browsers that don't support frames. It would be my understanding that usage of frames would also make documentation un-displayable on some browsers. >I think it's probably better to somehow make all new libraries use >Boost.Book. >If that's done, any presentation issues can be solved in one place. For >example, I think there were already discussion about expandable TOC on the >boost-doc failings list. I would like to see one package done in boost book before we impose such a requirement. When I go to the NightlyCVS link in the main boost page it shows what looks like boost book generated main page (whose aesthetics I'm not crazy about). When I click on one of the items it's a dead link. This gives me the impression that boost.book is still in development and that there are still too many pending issues to impose such a requirement. > At all events, I'd prefer constistent look of all Boost library docs (and > the ability to print them), to every author introducing something they > like. I think the boost documentation information www.boost.org is pretty good and helps promote this idea. I think it should used as a starting point. Robert Ramey

2 1

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 16 Jul '04

16 Jul '04

Mike, > > And I feel that the interface (representing convenience, > > flexibility, usability, etc.) is the first thing that a library will be > > judged by. > > Perhaps, but the next thing it will be judged by is efficiency and > speed. Ultimately, many C++ programmers won't use even the cleanest and > most elegant designs if they result in code that isn't fast enough or > efficient enough--especially in something like a multi-threading library. > > Peter Dimov's argument, if I understand correctly, is that the "cleaner" > design could be made as fast/efficient as the current one, not that we > should choose a cleaner design at the expense of speed or efficiency. [Batov, Vladimir] I never advocated forgetting efficiency. Only that the first thing needs to be addressed/settled on first. Then, we move on to the second within the constraints of the first choice. > > I feel that for the user having different types of mutexes is > > inconvenient and unnecessary restricting. > > Inconvenient I can see, but how is having more choices restricting? [Batov, Vladimir] It is restricting because I presume that different types of mutexes will have different functionality. Therefore, the plain mutex will not have something I need for try_lock. If that assumption of mine is not correct and, say, try_mutex is complimentary -- an efficient implementation of the generic mutex (with efficiency vs. functionality trade-offs), then I am fine with it. > > Having additional (and maybe unused) data in a mutex does not seem like > > a huge problem > > Not for you, perhaps, but I can guarantee that there are others who > don't feel that way. [Batov, Vladimir] True. I am fine if we address the mainstream use first (that is, a generic mutex represents an access serialization to the relevant data with the *kind* of serialization (timed, try, etc.) refined by locks). Then, mutex refinements will be just that -- refinements for a particular purpose. Like generic mem. allocation mechanism (kinda OK for everyone) vs. optimized (extremely good for some). > > (as long as it does not impose performance penalties) --s > > memory is cheap and mutexes are not usually created in huge numbers. > > Memory isn't cheap for everybody: there are still some (many?) who are > forced to work in more constrained environments. For instance, > programmer's of handheld devices often deal with insufficient memory > problems. [Batov, Vladimir] True. That falls into the same specialization category. I simply do not want that specialization at the expense of the mainstream users/applications.

1 0

Re:[boost] Regression Tests, Boost.Serialization
by Robert Ramey 15 Jul '04

15 Jul '04

Martin Wille wrote: > Houston, we have a problem. I am sorry about this. A couple of weeks ago I did raise the issue about testing resources regarding Boost Serialization. I was mainly concerned more about execution time. After a short back and forth I was left with the impression that no one thought testing this would be a problem. I'm open to suggestions. Again I apologize for not giving a more specific warning on this - I guess having a 100MB on my home system just skewed my perspective. Robert Ramey

1 0

RE: [boost] Re: Lock unification [was: Boost.Threads: Do we need all those mutexes?]
by Batov, Vladimir 15 Jul '04

15 Jul '04

> Christopher Currie wrote: > > I can infer that the apparent justification for unification would be to > > allow a single lock to be used in different ways, but I have a hard time > > imagining a use case where this would be as clear and as error-resistant > > as separate scopes with separate locks. If anyone has one, or any other > > rationale, please respond. > > The main motivation behind the idea of unifying the lock types (and > mutex types) is simplification of concepts, I believe. > > Mike [Batov, Vladimir] I would not call it 'simplification' as it can send a wrong message but rather 'streamlining'. It's because conceptually (and in implementation) try_lock = timed_lock(time=0) scoped_lock = timed_lock(time=infinite) Although I have to agree that from user perspective those locks are distinct and it makes sense to me to provide thin timed_lock, try_lock, blocking_lock interfaces for the majority of mainstream uses.

1 0

RE: [boost] Re: Lock unification
by Batov, Vladimir 15 Jul '04

15 Jul '04

I like the suggestion of constructing an appropriate lock via the appropriate constructor rather than a function (after all, that's what constructors are for :-) ). Although I'd probably try being more explicit typedef scoped_lock Lock; Lock l(m); // block Lock l(m, Lock::try); // try Lock l(m, Lock::time(33)); // timed Lock l(m, Lock::deferred); // deferred BTW, I love 'deferred'. IMHO it is very good and descriptive name for a parameter. Much better than we had before (was it block/non-block?). > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of David Abrahams > Sent: Friday, 16 July 2004 7:24 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: Lock unification > > "Eric Niebler" <eric(a)boost-consulting.com> writes: > > > David Abrahams wrote: > >> "Eric Niebler" <eric(a)boost-consulting.com> writes: > >> > >>>I continue to believe that a better interface for a unified lock > >>>involves descriptively named helper functions: > >>> > >>>scoped_lock l1( m ); // lock unconditionally > >>>scoped_lock l1 = defer_lock( m ); // don't lock > >>>scoped_lock l2 = try_lock( m ); // try lock > >>>scoped_lock l3 = timed_lock( m, t ); // timed lock > >>> > >>> It's just as clear as you could hope for, > >> I'm not convinced it is. It potentially puts information about the > >> kind of locking being done very far from the actual call that does > >> locking. > > > > > > True, but the other design under consideration doesn't help with > > that. It requires two-step construction for some constructs which > > could result in code like: > > > > scoped_lock l( m, false ); > > maybe_takes_the_lock_i_dont_know( l ); > > I don't know what you're referring to. I don't see any two-step > construction going on there. Links or examples, please? > > >>>and it's extensible. I feel that the single lock c'tor with a bool > >>>arg is less readable and rather inflexible. > >> Inflexible how? > >> > > > > User's can't add more constructors if they want a different locking > > strategy, but they can add as many helper function as they like. For > > instance, they could define a function that tried to take a timed_lock > > and logs failures. Or throws an exception. Or they could write a > > lock_if helper that takes a predicate. And they can do all that with > > simple one-step construction syntax. It's more concise and it permits > > the lock declaration to appear in the condition of if statements. > > Sorry, I missed the "single lock ctor" part. I think I agree with > you there. > > BTW, it just occurred to me that > > timed_lock(m, 0) > > could potentially generate different code from > > timed_lock(m, some_int) > > If we can detect literal zero... which I think is possible. > > What about: > > scoped_lock l(m); // block > scoped_lock l(m, 0); // try > scoped_lock l(m, 33); // timed > > scoped_lock l(m, deferred); // deferred > scoped_lock l(deferred(m)); // alternate > > ?? > > -- > Dave Abrahams > Boost Consulting > http://www.boost-consulting.com > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: Boost.Threads: Do we need all those mutexes?
by Iggy Veresov 15 Jul '04

15 Jul '04

While reading a discussion concerning different types of mutexes and guards in Boost, I thought it would be pertinent to highlight another possible approach to implement a multithreading library. In libMAGE (http://libmage.sourceforge.net/) we have a universal lock (unilock) abstraction, that provides a common way for construction of different lock managers (exclusive, read/write and even more complicated ones) with replaceable scheduling strategies. Furthermore, they can be easily adapted to mutex interface and used, for example, in methods of condition objects. /Igor Veresov

1 0

explicit-failures-markup.xml validating
by Bart Garst 15 Jul '04

15 Jul '04

I noticed a URL in boost/status/explicit-failures-markup.xml that can be used for validating. I made a couple changes to that file and ran it through the validator. My changes validate ok but there were other errors with the algorithm/string entries. Will these errors cause all entries in this file to not make it into the regression output? Thx, Bart

3 2

Re:Re: [boost] Re: Serialization Menu
by Robert Ramey 15 Jul '04

15 Jul '04

Mattias Flodin wrote: >> (ii) Requiring all documentation to support a no-script option. >In think (ii) is an absolute requirement. I find myself using >text-based browsers from time to time, especially when working across >an SSH connection, and I get quite annoyed by some documentation sites >that navigation exclusively though Javascript. I would hate for boost >to go the same way. >In addition to some text browsers not supporting Javascript at all, >the CERT has on numerous occasions advised that Javascript be disabled >in browsers such as IE for security reasons, and some companies make >that a policy decision. Actually I agree with this. I will change the serialization navigation pain so that it works on browsers that don't support scripting. This would leave the navigation pane but it would always be maximally expanded for browsers that don't support it. I think that would fulfill the requirement of making the documentation universally useable and still permit us to use the facility we like most of the time. A real problem with this collapsible tree navigation is that I generated it by hand. OK for a one time deal but not a great long term idea. As I understand it - the boost.book idea is the long term solution. I don't know if it now has the capability to generate such a navigation pane from the source documentation - but it should. Also if the formatting were all in the cascaded style sheet it would go a long way to avoiding disputes about things like aesthetics. It would be practical as well. For example one using a text based browser might use a different CSS. Feel free to take this with a grain of salt because I've barely looked at it. Robert Ramey

1 0

multi_array: a patch for SGI MIPSpro
by Synge Todo 15 Jul '04

15 Jul '04

Dear Boosters, About two days ago, the following lines are added in boost/multi_array.hpp (in order to increase the overload resolution of the constructor???). *************** *** 93,98 **** --- 93,102 ---- #ifdef BOOST_NO_FUNCTION_TEMPLATE_ORDERING , typename detail::multi_array::disable_non_sub_array<ExtentList>::type* = 0 #endif + , typename + boost::disable_if_c< + boost::is_same<ExtentList,multi_array>::value + >::type* = 0 ) : super_type((T*)initial_base_,extents) { boost::function_requires< However, it breaks e.g. SGI MIPSpro, since it does not support SFINAE. (boost/config/compiler/common_edg.hpp defines BOOST_NO_SFINAE.) I'm very happy, as a workaround, if the lines could be wrapped "#ifndef BOOST_NO_SFINAE", like #ifndef BOOST_NO_SFINAE , typename boost::disable_if_c< boost::is_same<ExtentList,multi_array>::value >::type* = 0 #endif Any better idea? Synge

2 1

RE: [boost] Re: method deduction (on vc?)
by Max Khesin 15 Jul '04

15 Jul '04

> Max Khesin <MKhesin(a)liquidnet.com> writes: > > > But not (from your phrasing) function members? > > I don't know about those; I haven't tried to find workarounds > for that. > > FWIW, designs that depend on member detection are often flawed from a > generic programming POV. You can get accidental conformance, and > especially if there's no way to explicitly say what the member means > (e.g. with a traits specialization), you'll be out-of-luck. Well, this is my intent, just for the record, (perhaps there are other techniques that apply): I want a generic dispatch function that accepts some "Message", makes it into a concrete class and dispatches it to the overloaded handler function: // A, B, C, ... derived from some Base template<class HandlerT> void dispatchMsg(HandlerT& h, Msg m) { if(m.getName()=="A") { h.onMsg(A(m)); }else if(m.getName()=="B") { h.onMsg(B(m)); } // etc } the handler class has to implement overloaded handler functions for the the classes it is interested in and (right now) a 'catch-all' handler for the Base& (to insure that the thing compiles). Ideally I would like to eliminate this requirement by detecting whether HandlerT has a onMsg(T&) and providing a no-op for that (via another level of indirection), some thing like: template<class HandlerT> void dispatchMsg(HandlerT& h, Msg m) { if(m.getName()=="A") { dispatcher<HAS_METH(h, void, onMsg, A&)>::dispatch(A(m)); }else if(m.getName()=="B") { dispatcher<HAS_METH(h, void, onMsg, B&)>::dispatch(A(m)); } // etc } This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

1 0

[preprocessor] Sun Studio 9 Early Access regressions
by Christopher Currie 15 Jul '04

15 Jul '04

Can anyone lend assistance in debugging the Sun regressions for Boost Preprocessor? The early access edition of the Studio 9 compiler is failing on BOOST_PP code that compiles just fine under earlier versions. The code that's failing appears to relate to the expansion (or lack thereof) of the macros that implement BOOST_PP_WHILE. I'm continuing to investigate, but since I'm unfamiliar with what the macros are *supposed* to do, I'm hoping someone can spot the trouble more quickly than I can. I've attached the preprocessed code from libs/preprocessor/test/control.cpp. Thanks in advance, Christopher -- Christopher Currie <codemonkey(a)gmail.com> #1 "/home/ccurrie/src/boost/libs/preprocessor/test/control.cpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/arithmetic/add.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/arithmetic/dec.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/config/config.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/arithmetic/inc.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control/while.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/cat.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/debug/error.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/detail/auto_rec.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control/iif.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/list/fold_left.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control/while.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/list/detail/fold_left.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control/expr_iif.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/list/adt.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/detail/is_binary.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/detail/check.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/logical/compl.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/tuple/eat.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/list/fold_right.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control/while.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/list/detail/fold_right.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/list/reverse.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/logical/bitand.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control/detail/while.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/logical/bool.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/tuple/elem.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control/deduce_d.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control/expr_if.hpp" #1 "/home/ccurrie/src/boost/boost/preprocessor/control/if.hpp" #1 "/home/ccurrie/src/boost/libs/preprocessor/test/test.h" #1 "/opt/SUNWspro/prod/include/CC/std/cstdio" #1 "/usr/include/sys/feature_tests.h" #13 "/usr/include/sys/feature_tests.h" #pragma ident "@(#)feature_tests.h 1.18 99/07/26 SMI" #1 "/usr/include/sys/isa_defs.h" #9 "/usr/include/sys/isa_defs.h" #pragma ident "@(#)isa_defs.h 1.20 99/05/04 SMI" #158 extern "C" { #380 } #18 "/usr/include/sys/feature_tests.h" extern "C" { #181 } #1 "/usr/include/iso/stdio_iso.h" #32 "/usr/include/iso/stdio_iso.h" #pragma ident "@(#)stdio_iso.h 1.2 99/10/25 SMI" #1 "/usr/include/sys/va_list.h" #9 "/usr/include/sys/va_list.h" #pragma ident "@(#)va_list.h 1.12 99/05/04 SMI" #22 extern "C" { typedef void * __va_list ; } #1 "/usr/include/stdio_tag.h" #9 "/usr/include/stdio_tag.h" #pragma ident "@(#)stdio_tag.h 1.3 98/04/20 SMI" extern "C" { #21 typedef struct __FILE __FILE ; } #1 "/usr/include/stdio_impl.h" #9 "/usr/include/stdio_impl.h" #pragma ident "@(#)stdio_impl.h 1.8 99/06/10 SMI" #14 extern "C" { #22 typedef int ssize_t ; #38 struct __FILE { ssize_t _cnt ; unsigned char * _ptr ; unsigned char * _base ; unsigned char _flag ; unsigned char _file ; unsigned __orientation : 2 ; unsigned __ionolock : 1 ; unsigned __filler : 5 ; } ; } #49 "/usr/include/iso/stdio_iso.h" extern "C" { #59 typedef long long __longlong_t ; #70 namespace std { typedef __FILE FILE ; #83 typedef unsigned int size_t ; typedef long fpos_t ; } #147 extern __FILE __iob [ 20 ] ; #159 namespace std { extern int remove ( const char * ) ; extern int rename ( const char * , const char * ) ; extern FILE * tmpfile ( void ) ; extern char * tmpnam ( char * ) ; extern int fclose ( FILE * ) ; extern int fflush ( FILE * ) ; extern FILE * fopen ( const char * , const char * ) ; extern FILE * freopen ( const char * , const char * , FILE * ) ; extern void setbuf ( FILE * , char * ) ; extern int setvbuf ( FILE * , char * , int , size_t ) ; extern int fprintf ( FILE * , const char * , ... ) ; extern int fscanf ( FILE * , const char * , ... ) ; extern int printf ( const char * , ... ) ; extern int scanf ( const char * , ... ) ; extern int sprintf ( char * , const char * , ... ) ; extern int sscanf ( const char * , const char * , ... ) ; extern int vfprintf ( FILE * , const char * , __va_list ) ; extern int vprintf ( const char * , __va_list ) ; extern int vsprintf ( char * , const char * , __va_list ) ; extern int fgetc ( FILE * ) ; extern char * fgets ( char * , int , FILE * ) ; extern int fputc ( int , FILE * ) ; extern int fputs ( const char * , FILE * ) ; #203 extern char * gets ( char * ) ; extern int puts ( const char * ) ; extern int ungetc ( int , FILE * ) ; extern size_t fread ( void * , size_t , size_t , FILE * ) ; extern size_t fwrite ( const void * , size_t , size_t , FILE * ) ; extern int fgetpos ( FILE * , fpos_t * ) ; extern int fseek ( FILE * , long , int ) ; extern int fsetpos ( FILE * , const fpos_t * ) ; extern long ftell ( FILE * ) ; extern void rewind ( FILE * ) ; #219 extern void perror ( const char * ) ; extern int __filbuf ( FILE * ) ; extern int __flsbuf ( int , FILE * ) ; #278 } #288 namespace std { inline int getc ( FILE * _p ) { return ( -- _p -> _cnt < 0 ? __filbuf ( _p ) : ( int ) * _p -> _ptr ++ ) ; } inline int putc ( int _x , FILE * _p ) { return ( -- _p -> _cnt < 0 ? __flsbuf ( _x , _p ) : ( int ) ( * _p -> _ptr ++ = ( unsigned char ) _x ) ) ; } } #308 namespace std { inline int getchar ( ) { return getc ( ( & __iob [ 0 ] ) ) ; } inline int putchar ( int _x ) { return putc ( _x , ( & __iob [ 1 ] ) ) ; } } #319 namespace std { inline void clearerr ( FILE * _p ) { _p -> _flag &= ~ ( 0040 | 0020 ) ; } inline int feof ( FILE * _p ) { return _p -> _flag & 0020 ; } inline int ferror ( FILE * _p ) { return _p -> _flag & 0040 ; } } #336 } #25 "/home/ccurrie/src/boost/libs/preprocessor/test/test.h" namespace std { } using namespace std ; int main ( void ) { printf ( "pass " "11:06:52" ) ; return 0 ; } #20 "/home/ccurrie/src/boost/libs/preprocessor/test/control.cpp" typedef int test_20 [ ( ( ( 0 ) == 0 ) == 1 ) ? 1 : - 1 ] ; typedef int test_21 [ ( ( 1 == 1 ) == 1 ) ? 1 : - 1 ] ; typedef int test_23 [ ( ( 1 == 1 ) == 1 ) ? 1 : - 1 ] ; typedef int test_24 [ ( ( ( 0 ) == 0 ) == 1 ) ? 1 : - 1 ] ; typedef int test_26 [ ( ( 0 == 0 ) == 1 ) ? 1 : - 1 ] ; typedef int test_27 [ ( ( 1 == 1 ) == 1 ) ? 1 : - 1 ] ; typedef int test_29 [ ( ( 0 == 0 ) == 1 ) ? 1 : - 1 ] ; typedef int test_30 [ ( ( 1 == 1 ) == 1 ) ? 1 : - 1 ] ; typedef int test_35 [ ( ( BOOST_PP_WHILE_BOOST_PP_IIF_BOOST_PP_BITAND_1 1 ( BOOST_PP_NODE_64 , BOOST_PP_NODE_192 ) ( BOOST_PP_WHILE_P #35 ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P #35 ) ( PRED , OP_1 , 50 ) == 0 ) == 1 ) ? 1 : - 1 ] ; typedef int test_40 [ ( ( BOOST_PP_WHILE_BOOST_PP_IIF_BOOST_PP_BITAND_1 1 ( BOOST_PP_NODE_64 , BOOST_PP_NODE_192 ) ( BOOST_PP_WHILE_P #40 ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P #40 ) ( PRED , OP_3 , 10 ) == 0 ) == 1 ) ? 1 : - 1 ] ; typedef int test_41 [ ( ( BOOST_PP_WHILE_BOOST_PP_IIF_BOOST_PP_BITAND_1 1 ( BOOST_PP_NODE_64 , BOOST_PP_NODE_192 ) ( BOOST_PP_WHILE_P #41 ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P ) ( BOOST_PP_WHILE_P #41 ) ( PRED , OP_3 , 10 ) == 0 ) == 1 ) ? 1 : - 1 ] ;

3 5

Re:Re: [boost] serialization test failure on darwin
by Robert Ramey 15 Jul '04

15 Jul '04

Marshall Clow wrote: > What I see is that the serialization library defines "std::wcslen" in > "wcslen.h", > even though there's a perfectly good one already available. This is > conditionalized > off of BOOST_NO_CWCHAR, which leads me to think that this flag is > wrong in the darwin config. > So, I moved it so that it is only set when building on GCC 2.95.x. Interesting. I examined the config files for macos and was left confused. It seemed to me that gcc 3.3 left BOOST_NO_CWHAR undefined while macos overrode that with a define. But then the regex test runs a config test whose results suggest that BOOST_NO_CWCHAR is not defined so I'm left absolutely and totally confused. On top of this I now have some doubts about my inclusion of my own definition of wcslen which I now suspect may have been the wrong response to some other question. I'm not sure if Darwin and macos are the same thing. So your observations and experiments are very opportune. I want to take a little time to check my usage/definition of wcslen ('til tomorrow). If you want to double check the config for gcc/macos/Darwin that would be good as well. I will also check the test results and make any other indicated corrections as these issues are orthogonal to this current wcslen one. Thanks for all your help. Robert Ramey

2 1

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 15 Jul '04

15 Jul '04

Mike, IMHO your comments below justifying different mutex types make sense. However, I feel that you look at the problem from the *implementor* point of view that is drastically different from the view of the library *user*. And I feel that the interface (representing convenience, flexibility, usability, etc.) is the first thing that a library will be judged by. I feel that for the user having different types of mutexes is inconvenient and unnecessary restricting. It is because when I create a mutex, I identify a resource that I want to serialize access to (it's a strategic decision in military terms :-) ). However, *how* I serialize the access (via blocking lock or try/timed locks) is not generally known at the time and will be defined on the case-by-case basis (when I'll be actually creating appropriate locks -- it's a tactical decision). A typical and very basic application I am working on discriminates two threads (and, therefore the appropriate mutex) -- the first always applies a blocking lock (scoped_lock) and the other thread only steps in through the successful try-lock. Having additional (and maybe unused) data in a mutex does not seem like a huge problem (as long as it does not impose performance penalties) -- memory is cheap and mutexes are not usually created in huge numbers. More so, I believe in boost there are techniques/classes minimizing waste. Best, V. > > Now that we got rid of the excess locks, how about doing the same with > the > > mutexes? > > I had considered this, but there does seem to be some benefit in having > separate mutex types, which is what I assume led to there being three > mutex types and three lock types in the original design. You've noted > these reasons below, but I'll reiterate: > > * On pthreads, the timed mutex requires an additional data member, > (condition variable) to handle cases when pthreads_timedlock isn't > supported. > > * On WinNT, the timed mutex operations require a win32 mutex object, > while the mutex and try mutex can use a win32 critical section. > > * On Win9x, the timed mutex and try mutex operations require a win32 > mutex object, while the mutex can use a win32 critical section. > > In other words, on the most widely-used platforms, collapsing the mutex > types into one imposes some penalty (larger mutex object or more limited > implementation options) on users. Also (I ask, not as a hypothetical > question, but as a request for information): is there another platform > where combining the mutex types incurs a similar or worse penalty?

2 1

Is serialization going to be in 1.32?
by Jeff Garland 15 Jul '04

15 Jul '04

Awhile back we added code and tests in date_time for serialization of dates, times, durations, etc. The tests have been disabled since serialization wasn't in CVS. However, if serialization is going to be part of 1.32 I'd like to go ahead and turn on these date_time tests. Thoughts? Jeff

1 0

Program Options failures (and fixes)
by John Maddock 15 Jul '04

15 Jul '04

Vladimir, I have some fixes for the program_options library on Win32 for you, first off here's the problem: On Win32 you must use the a dynamic runtime if you are building or using a dll: if you don't do this then separate runtimes/memory managers etc get linked to each module and the result is almost always a runtime crash some point. However you are also using std::locale and so have added std::facet-support std::locale-support to your build requirements. Doing so however, causes the static runtime to be used, so you're in a bit of a catch-22 situation here I'm afraid. You've also failed to define BOOST_ALL_DYN_LINK when *using* your dll - this is causing the mscv link failures. The patches below address both of these issues, tested with: VC7.1: everything passes. VC7.0: everything passes except the tests that use \u (unsupported). Intel 8 on vc7.1: everything passes. Intel 7.1 on vc7.1 everything pases except the tests that use \u (unsupported). Borland 5.6.4: all tests pass. Borland 5.5.1: Internal compiler error in function from_8bit, haven't investigated further yet. The fact that these tests do pass with Intel, possibly means that std::facet-support could be deprecated - it looks like Intel have fixed that problem with their recent patches. However, you may still experience problems with Metrowerks - I think there is any way around this - the dll version of the library is going to be unusable with that compiler. One final thing: you declare the environ variable in your sources, which is leading to warnings from MSVC and Intel about conflicting dll-specifications for that variable, perhaps you should include the header required rather than defining the variable yourself (unistd.h when BOOST_HAS_UNISTD_H is defined, or stdlib.h on WIN32)? John Index: build/Jamfile =================================================================== RCS file: /cvsroot/boost/boost/libs/program_options/build/Jamfile,v retrieving revision 1.2 diff -u -r1.2 Jamfile --- build/Jamfile 18 May 2004 06:38:17 -0000 1.2 +++ build/Jamfile 14 Jul 2004 10:32:56 -0000 @@ -21,7 +21,7 @@ <define>BOOST_ALL_DYN_LINK=1 # tell source we're building dll's <runtime-link>dynamic # build only for dynamic runtimes <include>$(BOOST_ROOT) <sysinclude>$(BOOST_ROOT) - std::facet-support std::locale-support + #std::facet-support std::locale-support : debug release # build variants ; cvs diff: Diffing doc cvs diff: Diffing example cvs diff: Diffing src cvs diff: Diffing test Index: test/Jamfile =================================================================== RCS file: /cvsroot/boost/boost/libs/program_options/test/Jamfile,v retrieving revision 1.4 diff -u -r1.4 Jamfile --- test/Jamfile 28 Jun 2004 09:31:28 -0000 1.4 +++ test/Jamfile 14 Jul 2004 10:32:56 -0000 @@ -19,7 +19,9 @@ run $(name).cpp <dll>../build/boost_program_options <lib>../../test/build/boost_test_exec_monitor : : : <include>$(BOOST_ROOT) - std::facet-support std::locale-support + #std::facet-support std::locale-support + <define>BOOST_ALL_DYN_LINK=1 + <runtime-link>dynamic : $(name)_dll ] ; }

2 6

STLPort linking error
by Ian McCarty 15 Jul '04

15 Jul '04

Hi, I am in the middle of moving our development from the std STL to STLPort and I am having a problem with two Athlon boxes. SuSE Linux 9.0 gcc 3.3.1 STLPort 4.6.2 Boost 1.31 I am changing an existing application to use STLPort and I have successfully completed the transition on a number of Intel boxes. When I try to build on an Athlon box I get the following error message: undefined reference to `boost::thread::thread[in-charge](boost::function0<void, std::allocator<boost::function_base> > const&)' I'm linking against libboost_thread-gcc-mt-p-1_31 and libboost_date_time-gcc-mt-p-1_31. I can't see an obvious solution so I'm hoping someone has solved this problem already. Thanks in advance, Ian. __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

3 2

FW: [boost] Re: "memory access violation" in boost::serialization
by Dirk Griffioen 15 Jul '04

15 Jul '04

Hi Robert, We'll see what we can do - but sadly there's no bjam port for AS400 or MVS. On both we use the unix-like environment (something like 'qshell' and the mvs version I keep forgetting), so it might be doable. The mac-version (not too much) or the unix version of the bjam sources ("file*.c", "exec*.c" "path*.c" etc) could be used as a base - on the other hand, the gnu tools like 'make' on AS400 map their calls to the 'local' calls - which is not fopen :) - so it might be tricky. We'll let you know (If anoynone has ported bjam to AS400 or MVS - I'd lve to know) Dirk Robert Ramey wrote: Dirk Griffioen wrote: I also outcommented line 125. We will, however, upgrade to #20 as soon as possible. Note that #20 and subsequent versions do not have boost/serialization/shared_count.hpp but rather use a very crude hack to gain access to private variables within shared_count. Hopefully this will be addressed in a better way in the near future. You might want to wait just a tiny bit. It looks like serialization may be included in the upcoming boost release. If the release works out soon you might want to move right to boost 1.32. If the release boggs down or for some reason its inconvenient for you do move to 1.32 - you can use to #20. #20 is the last draft. I've tested it extensively with 1.31. We have a lot of platforms here (HP, AIX, SUN, VMS, AS400 and Mainframe - with different versions of native compilers and/or gcc) and it is likely we will port to those platforms. If there's an interest, it might be possible to gather some figures. Hmmm - embarrassment of riches. It is possible you might be able to run - at least occasionally the bjam test suite for some of the less common platforms? I would love to know how boost (and of course serialization) work with AS400 and Mainframe(?). I believe the others are already covered. If you're willing to run the tests, developers might be more willing the help with the porting. Robert Ramey _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

regression tests not update
by Pavol Droba 15 Jul '04

15 Jul '04

Hi, I don't know what is wrong, but it seems, that regression test are not updated. I have commited markups for failuers two days ago and they are still not used in the regression test. (Specificaly not in the metacomm tables) Also some bugfixes seems to be not applied. Can anybody check this out? Thanks, Pavol

2 1

Re:[boost] Serialization Menu
by Robert Ramey 15 Jul '04

15 Jul '04

This is an interesting question. It seems I spend half my time bouncing back and forth between boost documentation pages. When this started to happen with my own boost serialization documentation I added a navigation frame with with a static index which would let be jump right to the part that I was interested in. Eventually as I added more pages to the documentation, the scrolling started to annoy me and I implemented the current scheme. I was inspired by the boost pre-processor documentation and I don't remember whether or not I was aware of the "kind of policy" against. I've been very, very pleased with the utility of the result. I made it and checked with both IE and netscape. I haven't checked with other browsers but have no received no reports that it doesn't work. I love this system. I think it should be adopted for all boost documentation. In this way I have a collapsible navigation pane which would let me navigate all of boost rather than just the serialization library. There are a couple of issues a) I had to make it "by hand" for the serialization library. OK for a prototype - but unsatisfactory in general. Ideally it should be generated automagically by Boost.Book. After all it's just an index which I would presume Boost.Book should be generating anyway. I haven't studied boost book so I don't really know anything about it. But if it doesn't include something like this I would consider it a glaring oversight. b) I believe that with a little effort the browser portability issues could be addressed. Basically there could be two index pages - a dynamic as well as a static one. All the "documentation pages" would be unchanged. I didn't really go into this because no one seemed to have a problem with the dynamic one. Of course the above doesn't raise the key issue that Dave raises. Should it be removed now? Should it be replaced with anything? - if so what? I would prefer to leave as it is. A final point regarding boost book. When I go to the main boost page and select nightly CVS I get a page which seems to have the look/feel that of the pages the boost.book is going to produce. I don't want to start a religious argument about aesthetics, but... I prefer the previous look and feel which was supported by the original documentation guidelines. Its just one man's opinion. Dave Abrahams wrote: >We have a kind of policy against using scripting in our library doc >pages, mostly because in the past scripts have caused major >portability or usability problems. I personally love the menu on the >left of the serialization lib docs page, but if it uses scripts and we >can't really be assured that they'll work everywhere, it probably >ought to be removed. >There are alternatives that might actually be more usable: >http://article.gmane.org/gmane.comp.lib.boost.documentation/389

3 2

Re:Re: [boost] serialization test failure on darwin
by Robert Ramey 15 Jul '04

15 Jul '04

Marshall Clow wrote: >So, I moved it so that it is only set when building on GCC 2.95.x. >Index: boost/boost/config/platform/macos.hpp >=================================================================== >RCS file: /cvsroot/boost/boost/boost/config/platform/macos.hpp,v >retrieving revision 1.13 >diff -r1.13 macos.hpp >19d18 >< # define BOOST_NO_CWCHAR >41a41,42 >> # define BOOST_NO_CWCHAR >> >This did not break any other tests, and made some (many) of the >serialization tests pass. There are still many failures, which I am still >investigating. >Could someone vet this change, and commit it to CVS? Thanks! When I look at this I conclude that define BOOST_NO_CWCHAR ( and BOOST_NO_CWTYPE) should just be removed from this file. Its not clear to me why its there. The MacOS compiled with GCC includes the file library configuration file that sets/doesn't set these macros according to the platform. And the gcc version isn't enough to do it right. E.G. Cygwin gcc doesn't support wchar_t etc even though its version 3.3. I would like to a) hear from someone who knows why that code was put in there in the first place. b) take it out and run the tests. If b) looks ok and we don't hear from anyone shortly, then I'll make the change in CVS. Robert Ramey

1 0

RE: [boost] BOOST_PP_REPEAT with internal macro problem
by Yossi.Itzkovich＠ecitele.com 15 Jul '04

15 Jul '04

Thanks all for your fast (and good) answers. Yossi "Paul Mensonides" <pmenso57@comcast. To: <boost(a)lists.boost.org> net> cc: Sent by: Subject: RE: [boost] BOOST_PP_REPEAT with internal macro problem boost-bounces@list s.boost.org 07/15/2004 07:00 Please respond to boost > -----Original Message----- > [mailto:boost-bounces@lists.boost.org] On Behalf Of > BOOST_PP_REPEAT works great for me when used like: > > #define MAX 5 > #define CODE my_code_goes_here > BOOST_PP_REPEAT(MAX, CODE, ) ^^ Passing nothing as a macro argument is undefined in C++. You should use a dummie argument instead--preferably not an identifier. I usually use ~ or ?. > > But it gets confused when used like: > > #define MAX (4+1) Arkadiy is correct. The library cannot understand the expression (4+1). It can only understand unadorned integer literals (such as 1, 2, 3, etc.) from 0 to 256. If you need to do arithmetic, you have to use the arithmetic primitives of the library, such as BOOST_PP_ADD or, in this case, BOOST_PP_INC (which is more efficient). Thus, if you want to do a repetition of MAX + 1, you need to say: BOOST_PP_REPEAT(BOOST_PP_INC(MAX), CODE, ~) Regards, Paul Mensonides _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

BOOST_PP_REPEAT with internal macro problem
by Yossi.Itzkovich＠ecitele.com 15 Jul '04

15 Jul '04

Hi, BOOST_PP_REPEAT works great for me when used like: #define MAX 5 #define CODE my_code_goes_here BOOST_PP_REPEAT(MAX, CODE, ) But it gets confused when used like: #define MAX (4+1) Is ther a work around ? I even tried: #define MAX (4+1) const int myMax=MAX; BOOST_PP_REPEAT(myMax, CODE , ) but still no luck. Any help ? Thanks Yossi

4 3

Serialization needs a redirect
by David Abrahams 14 Jul '04

14 Jul '04

Someone needs to add libs/serialization/index.html that redirects to the library's front page. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 1

serialization test failure on darwin
by Robert Ramey 14 Jul '04

14 Jul '04

In reviewing the failure of the serialization library build on Darwin - it seems that none of the include file can be found. This sounds like some sort of Jamfile or build setup issue. Can anyone give me any insight here? Robert Ramey

5 6

Re: numeric_cast
by John Kalucki 14 Jul '04

14 Jul '04

On Tuesday, April 20th, Fernando Cacciola wrote: >Indeed. The accepted numeric conversions library handles this case properly >(throwing). >Right now I'm technically on vacation until next Monday. I'll start working >with the review comments right next week. I'll check it in on CVS after I >made the neccesary changes. > >Anyway, users can download the review version from here: > >http://personales.ciudad.com.ar/fernando_cacciola/numeric_conversions.zip > >or > >http://groups.yahoo.com/group/boost/files/numeric_conversions.zip > > >Fernando Cacciola >SciSoft Is this fix in a released version of Boost? If so, which version? -John Kalucki

1 0

erroneous use of BOOST_STATIC_CONSTANT ?
by Toon Knapen 14 Jul '04

14 Jul '04

When using BOOST_STATIC_CONSTANT, the member still need to be _defined_ in a .cpp file (IIUC 9.4.2 par 4 of the standard), unless the enum-trick is used, right? However gcc, intel-linux and the mipspro compiler (and probably others) do not require a seperate definition. OTOH IBM/VisualAge does really _need_ the definition (otherwise the symbols are undefined when linking). Would'nt it be better to advise library-developers to use an enum instead of BOOST_STATIC_CONSTANT if their library does not contain a definition? toon

5 15

Re:Re: [boost] serialization test failure on darwin
by Robert Ramey 14 Jul '04

14 Jul '04

> Ok, I've completed that, and the test results are (more or less) the same. > The error messages are different, though. > Suggestions? Relax - your test setup is fine. The library fails to build so all the tests are marked as faile. Its my problem now. I'll be making a couple of small changes and we can try again. Robert Ramey

1 0

Re: [boost] Re: Suggestion for iterator_adaptor
by JOAQUIN LOPEZ MU?Z 14 Jul '04

14 Jul '04

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> [...] > I'm soliciting suggestions for the name of the member. All names with > suffixes like "_t" will be rejected, and be aware that base is > already taken for other purposes. Currently my thoughts are > > super // super > crtp // ugly > I'd vote for super, which has an established reputation in Java. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[preprocessor] sequence->initializer
by Vladimir Prus 14 Jul '04

14 Jul '04

Hello, support I have some Boost.Preprocessor data structure, say a sequence: #define SEQ ("1")("2")("3") how can I convert it into initalizer {"1", "2", "3"}? E.g: #define MY_TEST(SEQ) char* var = { SOMEHOW_GET_LIST_OF_VALUES(SEQ) } I've tried to look at preprocessor docs, but it's rather hard to find the answer. TIA, Volodya

3 3

Re:[boost] Serialization needs a redirect
by Robert Ramey 14 Jul '04

14 Jul '04

Dave Abrahams wrote: >Someone needs to add libs/serialization/index.html that redirects to >the library's front page. I added this yesterday and it shows on the cvs directory browse. Is there something wrong with it? Robert Ramey

2 1

question generated by serialization library build on Visual Age C++
by Robert Ramey 14 Jul '04

14 Jul '04

I'm getting a problem with serialization library build on IBM Visual Age compiler. It report that boost::iterator_difference<const char *> isn't complete. In perusing the code, it would seem to me that iterator_adaptor is including all it needs to resolve this and FWIW it works everywhere else. Can anyone give me a suggestion here? Robert Ramey "/home/tk/boost_regression/boost/boost/mpl/apply_if.hpp", line 39.5: 1540-0062 (S) The incomplete class "iterator_difference<const char *>" must not be used as a qualifier. "/home/tk/boost_regression/boost/boost/iterator/iterator_adaptor.hpp", line 149.14: 1540-0700 (I) The previous message was produced while processing "struct boost::mpl::apply_if<boost::is_same<boost::use_default,boost::use_default>,b oost::iterator_difference<const char *>,boost::mpl::identity<boost::use_default> >". "/home/tk/boost_regression/boost/boost/iterator/iterator_adaptor.hpp", line 148.12: 1540-0700 (I) The previous message was produced while processing "struct boost::detail::ia_dflt_help<boost::use_default,boost::iterator_difference<co nst char *> >". "/home/tk/boost_regression/boost/boost/iterator/iterator_adaptor.hpp", line 167.12: 1540-0700 (I) The previous message was produced while processing "struct boost::detail::iterator_adaptor_base<boost::archive::iterators::transform_wi dth<const char *,6,8,char>,const char *,char,boost::single_pass_traversal_tag,char,boost::use_default>". "/home/tk/boost_regression/boost/boost/iterator/iterator_adaptor.hpp", line 243.9: 1540-0700 (I) The previous message was produced while processing "class boost::iterator_adaptor<boost::archive::iterators::transform_width<const char *,6,8,char>,const char *,char,boost::single_pass_traversal_tag,char,boost::use_default>". "/home/tk/boost_regression/boost/boost/archive/iterators/transform_width.hpp ", line 46.7: 1540-0700 (I) The previous message was produced while processing "class boost::archive::iterators::transform_width<const char *,6,8,char>".

2 1

libs/iterator/doc/iterator_concepts.pdf not marked as binary
by Peter Dimov 14 Jul '04

14 Jul '04

libs/iterator/doc/iterator_concepts.pdf is not marked as binary in the CVS. The result is that it apparently has been scrambled at commit time, as neither a Windows nor a Linux check out a readable PDF. In addition, Windows always shows it as locally modified; my cvs commit just committed a new revision of iterator_concepts, but I didn't touch the file. I can't fix it because I don't have the original PDF, and cvs can't check out a working version. -- Peter Dimov http://www.pdimov.com

2 1

method deduction (on vc?)
by Max Khesin 14 Jul '04

14 Jul '04

I am working on some generic code that could use a method deduction trick of some sort. One mentioned by J.Maddock (http://lists.boost.org/MailArchives/boost/msg52178.php) does not work on vc6 - is there anything in boost (MPL?) that can help? Thanks, Max. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

4 5

RE: [boost] Compatibility between boost versions
by Klaus Nowikow 14 Jul '04

14 Jul '04

Doug Gregor wrote: > On Jul 14, 2004, at 9:06 AM, Klaus Nowikow wrote: > > This leads to the question: are different versions of the boost > > libraries compatible with each other? Can I use a newer version of > > boost > > in future additions to our system and expect them to work > together or > > will > > we have to rebuild the whole system when we decide to use a > new version > > of boost? > > We typically try to retain source-level compatibility between Boost > versions, but make little or no effort to retain the binary > compatibility that you would need. The basic problem is that merely > breathing on a template metaprogram breaks binary compatibility, and > nearly every Boost library requires some form of metaprogramming. You > will probably have to standardize on a particular Boost version, > compiler, and standard library :( I thought so. I will have to discuss this with my co-workers, but I think we will be able to deal with this -- by staying with one version for several boost release cycles. The real problem is that every new boost version brings interesting new features, and it's terribly hard to keep my hands off them ;-) -- Klaus

1 0

RE: [boost] Re: method deduction (on vc?)
by Max Khesin 14 Jul '04

14 Jul '04

But not (from your phrasing) function members? thanks. > > You can detect type members on vc6. See mpl/aux_/has_xxx.hpp. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

2 1

Compatibility between boost versions
by Klaus Nowikow 14 Jul '04

14 Jul '04

My company is currently developing a new set of software packages (applications, static and dynamic libraries) that are all expected to work together (i.e., the libraries will be linked to more than one of the applications, and the libraries will interoperate and depend on one another). In addition, the system has to be extensible, i.e. new DLLs will be added in the future without requiring to rebuild the other components. I use many parts of the boost libraries, not only for the implementation details, but also in the interfaces of the libraries (e.g. the iterator adaptors, type_traits, call_traits, variant, mpl...). This leads to the question: are different versions of the boost libraries compatible with each other? Can I use a newer version of boost in future additions to our system and expect them to work together or will we have to rebuild the whole system when we decide to use a new version of boost? I don't expect a definite answer to this complex question, but is it possible to estimate how likely it is that newer versions of boost will require us to rebuild all? Best regards, Klaus

3 2

Re:[boost] [1.32 release] TODO list synchronization
by Robert Ramey 14 Jul '04

14 Jul '04

Aleksey Gurtovoy wrote: >As we are coming closer to the branch-for-release date, I'd like to inquire >developers working towards the release about the current status of their >corresponding TODO items below. Simply replying to this message and saying >"Done", "Not done, will be done by date X", "Abandoned" or whatever you >wish to say on each of the items would be more than fine. >> Serialization >> ///////////// > >> Robert Ramey writes: > > a) post version compatible with 1.31 next week. Done > b) build and test against the CVS tree on my computer. Done > c) check in Done I've tested against the latest CVS on my own machine with satisfactory results. The compilers I've tested are: 1) MSVC 7.1 2) MSVC 6.0 3) Borland 5.51 4) Borland 5.60 5) gcc 3.3 under cygwin 6) gcc 3.4 on linux (draft #20) has been tested on linux with good results I haven't seen any test results from boost test servers for the serialization library - I expect to see some soon. If past experience is any guide - any platform NOT on the above list will have at least a few issues. d)? marking platforms to skip. I expect to mark Commeau as not useable due to a problem I have pending. I might revisit it if I have time. I would also expect to mark gcc 2.95 as not worth the effort as 3.3+ is a free upgrade. I'm still undecided about this - I'm a little burned out on this sort of stuff after addressing MSVC 6.0 and Borland. As to whether or not you want to include it in the branch, I would withhold judgment pending outcome of the first rounds of "official" test. The you can decide whether or not it should be included. There are no new features to add or document for this release. Anything not in there now would be slated for a subsequent release. This includes autolib, boost.book among other things. Robert Ramey

4 4

RE: [boost] Compatibility between boost versions
by Klaus Nowikow 14 Jul '04

14 Jul '04

Michiel Salters wrote: > > -----Original Message----- > > From: boost-bounces(a)lists.boost.org > > [mailto:boost-bounces@lists.boost.org]On Behalf Of Klaus Nowikow > > Sent: woensdag 14 juli 2004 16:07 > > To: boost(a)lists.boost.org > > Subject: [boost] Compatibility between boost versions > [SNIP] > > > I don't expect a definite answer to this complex question, but is it > > possible to estimate how likely it is that newer versions of boost > > will require us to rebuild all? > > It's in the FAQ: D'oh! Thank you. -- Klaus

1 0

RE: [boost] Compatibility between boost versions
by Michiel Salters 14 Jul '04

14 Jul '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org]On Behalf Of Klaus Nowikow > Sent: woensdag 14 juli 2004 16:07 > To: boost(a)lists.boost.org > Subject: [boost] Compatibility between boost versions [SNIP] > I don't expect a definite answer to this complex question, but is it > possible to estimate how likely it is that newer versions of boost > will require us to rebuild all? Expect rebuilds. It's in the FAQ: --- How can the Boost libraries be used successfully for important projects? Many of the Boost libraries are actively maintained and improved, so backward compatibility with prior version isn't always possible. Deal with this by freezing the version of the Boost libraries used by your project. Only upgrade at points in your project's life cycle where a bit of change will not cause problems. Individual bug fixes can always be obtained from the CVS repository. --- Regards, -- Michiel Salters Consultant Software Engineering LogicaCMG RTSE1, the Netherlands Michiel.Salters(a)logicacmg.com This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

[1.32 release] Regressions clean-up
by Aleksey Gurtovoy 14 Jul '04

14 Jul '04

According to http://tinyurl.com/25ar3, the following libraries appear to be in a particularly untidy state: - Date/time, http://tinyurl.com/563b7 - Filesystem, http://tinyurl.com/4kshr - UBLAS, http://tinyurl.com/3vwcz - Thread, http://tinyurl.com/4s58j Also, most of the new libraries, namely - algorithm/string - numeric/conversion - range - program_options are either missing explicit markup, or unexpectedly failing. I'd appreciate if the corresponding library authors / maintainers (or simply volunteers) looked over these failures and cleaned things up a little, brigning us closer to the sacred "all green" field. Thank you, -- Aleksey Gurtovoy MetaCommunications Engineering

5 6

re [1.32 release] TODO list synchronization
by Michael Stevens 14 Jul '04

14 Jul '04

> uBLAS Done Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

4 4

Regression testing goes horribly wrong! (+ patch)
by Guillaume Melquiond 14 Jul '04

14 Jul '04

Hi, If you take a look at the regression logs [1], you will see a few problems. First, a lot of test types [2] are missing. The "bind" or "date-time" libraries don't have any value in the test type column. Other libraries like the "array" library do have values in this column, however. Second, the name of some "nested" libraries are wrong. For example, the "algorithm/string" is shown as "algorithm", the "numeric/conversion" and "numeric/interval" libraries are both mixed under "numeric". But the "numeric/ublas" is correctly named. Third, expected failures are not correctly shown in the advanced regression logs [3] since some library names are wrong. Fourth, some libraries are compiled in the wrong directories. Instead of being compiled in "bin/boost/libs/whatever/test/something.test", they are directly compiled in "bin/boost/status/something.test" [4]. If you run the regression tests, you will see what I mean. It's quite possible that the problems for the first three points are related to the fourth. Indeed, it seems only libraries wrongly compiled in "bin/boost/status/something.test" get to be correctly identified. It's the case for the "array" and "numeric/ublas" libraries for example. I don't understand how regression testing takes place into Boost. From my humble point of view, it is quite a mess. I didn't understand why some libraries were compiled in the wrong place; I suppose it has to do with bjam and their Jamfiles. I did however find a way to correct the first two bugs (and probably the third). The test_log.xml are indeed wrongly generated by process_jam_log. So here is a patch to process_jam_log.cpp so that it correctly generates the test_log.xml files. Unfortunately I don't understand at all some parts of this program, so I only corrected what seemed obviously wrong to me. But maybe the bugs were somewhere else and I only designed a lame workaround? Could the author of these lines shed some light on what their purpose was supposed to be? In the meantime, maybe the regression testers could clear their "bin" directory (so that all the test_log.xml are created from scratch) and apply the patch? Since Boost 1.31 is supposed to ship in less than 20 days, it would be great if the regression logs were correctly generated. Thanks. Best regards, Guillaume [1] For example, a small regression log: http://boost.sourceforge.net/regression-logs/cs-AIX.html All recent regression logs are affected. [2] "run", "compile", "compile_fail", etc [3] Some of the yellow cells should actually be gray in this log: http://boost.sourceforge.net/regression-logs/cs-win32_metacomm/developer/su… [4] For example, look at the compile line used for: http://boost.sourceforge.net/regression-logs/cs-AIX-links.html#lambda-bll_a… Index: process_jam_log.cpp =================================================================== RCS file: /cvsroot/boost/boost/tools/regression/process_jam_log.cpp,v retrieving revision 1.25 diff -u -r1.25 process_jam_log.cpp --- process_jam_log.cpp 28 Jun 2004 03:04:21 -0000 1.25 +++ process_jam_log.cpp 9 Jul 2004 17:38:59 -0000 @@ -241,11 +241,11 @@ } test_info info; - test2info_map::iterator itr( test2info.find( library_name + "/" + test_name ) ); + test2info_map::iterator itr( test2info.find( test_name ) ); if ( itr != test2info.end() ) info = itr->second; - if ( library_name.empty() ) + if ( !info.file_path.empty() ) library_name = test_path_to_library_name( info.file_path ); if ( info.type.empty() ) @@ -511,8 +511,6 @@ line.find( "\"", pos+3 )-pos-3 ); convert_path_separators( info.file_path ); if ( info.file_path.find( "libs/libs/" ) == 0 ) info.file_path.erase( 0, 5 ); - if ( test_name.find( "/" ) == string::npos ) - test_name = "/" + test_name; test2info.insert( std::make_pair( test_name, info ) ); // std::cout << test_name << ", " << info.type << ", " << info.file_path << "\n"; }

5 17

Functors and Boost::MPL
by Dan 14 Jul '04

14 Jul '04

It occurs to me that it should be possible to manage an mpl::vector of types which are actually functors. One could add functors to this list with compile time complexity and likewise call all the functors in the list with compile time complexity. Requiring none of the function pointers, class templates, or virtual functions typically used for this purpose. I think it should be easy to create the vector, but how does one construct an object of each type and call operator() on it? -Dan "The only impossible task is the task you never start"

2 1

[assign] not in status/Jamfile
by JOAQUIN LOPEZ MU?Z 14 Jul '04

14 Jul '04

Shouldn't be there an entry for this lib in status/Jamfile? The code is checked in since 2 weeks ago. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

Re:[boost] Re: serialization:question regarding test
by Robert Ramey 14 Jul '04

14 Jul '04

I don't see that this should be a problem. Just follow the instructions in the release notes: a) Download spirit 1.61 from SourceForge.net to a local directory. On my machine its c:/spirit161 b) Define (export) environmental variable SPIRIT_ROOT=c:/spirit161. The build/test jamfile set up is sensitive to the SPIRIT_ROOT variable and will put it in the include path for those systems that are known to require it. Right not that is msvc 6.0 and all tested borland compilers. Other compilers just work with the latest version of spirit from the CVS Tree. This works on my system without any other special adjustments other than the above. So I'm asking that the testers set up their environment as above before running the tests. I don't think that's an unreasonable request. In fact, I believe this should be seen as a vindication and demonstration of the power and flexibility of the bjam/jamfile system rather than an extra burden. Robert Ramey Dave Abrahams wrote: >"Robert Ramey" <ramey(a)rrsd.com> writes: >> It seems I've succeeded in getting my serialization project checked in. >> >> (I've held back the Jamfile in the test directory pending a tiny >> tweak) >> >> And I have a couple of questions regarding testing. > >> a) in order for libraries to be built for Borland and VC 6.0 which >> don't support Spirit 1.8 but do support spirit 1.6, the Jamfile checks >> for the environmental variable SPIRIT_ROOT and if found presumes it >> contains the root of the directory where Spirit 1.6 is located. This >> has worked well in my local environment. An environment which tests >> this library for these compilers will also need to have Spirit 1.6 >> installed and have the SPIRIT_ROOT variable set accordingly. I don't >> know who I should inform about this. >That's not going to work well in the Boost regression suite. >Tests get run against a current copy of the Boost tree, and we don't have >any provision to check out (say) an old branch of Spirit.

3 2

[1.32 release] Linux regressions
by Aleksey Gurtovoy 14 Jul '04

14 Jul '04

Everything seems to be broken due to an error in a system header -- http://tinyurl.com/5r2dh. -- Aleksey Gurtovoy MetaCommunications Engineering

2 2

Win32 regressions
by Stefan Slapeta 14 Jul '04

14 Jul '04

Is the current state of win32 regressions written down anywhere? The results on the boost site are of april! Thanks, Stefan

1 1

serialization:question regarding test
by Robert Ramey 14 Jul '04

14 Jul '04

It seems I've succeeded in getting my serialization project checked in. (I've held back the Jamfile in the test directory pending a tiny tweak) And I have a couple of questions regarding testing. a) in order for libraries to be built for Borland and VC 6.0 which don't support Spirit 1.8 but do support spirit 1.6, the Jamfile checks for the environmental variable SPIRIT_ROOT and if found presumes it contains the root of the directory where Spirit 1.6 is located. This has worked well in my local environment. An environment which tests this library for these compilers will also need to have Spirit 1.6 installed and have the SPIRIT_ROOT variable set accordingly. I don't know who I should inform about this. b) its unclear to me how to exclude certain platforms. I've been unable go get non-intrusive serialization with Commeau - much to my disappointement. This is pretty much a show-stopper for this compiler. (Other than this it seems to compile cleanly - though perhaps a tad picky with warnings). So I would like to know how to exclude Comeau from the tests. c) As currently loaded, the test programs create temporary files in the systems temporary directory. And leaves them there - I occasionally delete them in masse. It only just dawned on me that this would be very inconvenient for the test setup so I'm going to tweak the tests to remove their trash at the end. So in some case some trash may be left over but shouldn't accumulate at a large rate as before. I hope this is acceptable. Robert Ramey

4 5

Another spirit compile problem using HP aC++
by DY, JERRY U (SBCSI) 14 Jul '04

14 Jul '04

Here's another problem while compiling with aC++. This has been reported to the HP aC++ team, but in the meantime, I'm posting this fix to the list for review and for future users of Spirit for aC++. BTW, I'm a little afraid to commit changes to the repository, so quick question: If I end up committing changes that need to be backed out, can I delete that version that I committed easily? Thanks! boost/spirit/core/primitives/impl/match.ipp:101 ===old=== inline void match<nil_t>::swap(match& other) { std::swap(len, other.len); } ===new=== inline void match<nil_t>::swap(match<nil_t>& other) { std::swap(len, other.len); } -Jerry

3 2

uBLAS developers meeting ?
by Toon Knapen 14 Jul '04

14 Jul '04

I was discussing with Michael Stevens about organising a uBLAS developers meeting. And thus we decided to ask the community if 1) there would be any interest, 2) which topics people would like to discuss 3) what format would best fit, 4) and finally where and when. As for the topics (item 2), I think following list are certainly candidates: Evaluation of the design of uBLAS and discussion of future design Evaluation of the efficieny of uBLAS Syntax and ET engine Evaluation of the documentation and how to go from there. Restating the main goals of uBLAS Organisation of ublas project. overview of applications using uBLAS. As for the format I think most important are having intense discussions on the topics above. Presentations (by volunteers) could serve to initiate the dicussion on specific topics. Where and when to organise it probably depends on the interest from the developers. It seems like many active ublas-dev members are at most a few 100km from Cologne (Germany) so getting this group together could be easy in a small timeframe. But it is probably easier to discuss the 'where and when' once we have more information about 'who' would like to attend. toon

1 0

[Signals][Patch] test/ordering_test.cpp
by Juergen Hunold 14 Jul '04

14 Jul '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi ! the test in ordering_test.cpp does not use the BOOST_SIGNALS_NAMESPACE #define and therefore breaks if BOOST_SIGNALS_NAMESPACE is #defined to something else (for Qt-compatibilty, for example). The attached patch corrects this. 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA9C9gljbJ/LLrxrYRAm35AJ9nHAPPumz4xPnPa0ZjQLlfiCkaTACgx1ys o/5GVsumKIOkGkYYoeHjVco= =aTJg -----END PGP SIGNATURE-----

2 1

RE: [boost] Re: compiling spirit parser using aC++
by DY, JERRY U (SBCSI) 14 Jul '04

14 Jul '04

Just tried and it compiled past this. More errors though. Thanks! -Jerry -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Joel de Guzman Sent: Tuesday, July 13, 2004 5:16 PM To: boost(a)lists.boost.org Subject: Re: [boost] Re: compiling spirit parser using aC++ David Abrahams wrote: > Try this: > > typedef typename extract_int_<(MaxDigits >= 0)>::template > apply<Radix, MinDigits, MaxDigits, Accumulate> extractor; > extractor::f(scan,n,count); Forgot the return: return extractor::f(scan,n,count); Applied in the CVS. Thanks!

1 0

typeof
by Arkadiy Vertleyb 14 Jul '04

14 Jul '04

Hi everybody, Please find at http://groups.yahoo.com/group/boost/files/typeof.zip (and in the Spirit repository, TYPEOF_DEV branch) a new version of my typeof emulation library. This version has the documentation, as well as support for the following has been added: - arrays; - function pointers; - pointers to member functions; - pointers to data members. Any comments are welcome. I would also again greatly appreciate if anybody could try to compile the test with any compiler except VC7.1 (which I have), GCC and Metrowerks (which have native typeof support), or any compiler that does not support partial template specialization (which would not compile this anyway). Best regards, Arkadiy

6 35

compiling spirit parser using aC++
by DY, JERRY U (SBCSI) 14 Jul '04

14 Jul '04

I'm trying to get spirit parser to compile in aC++, but aC++ errors on the following line. The problem apparently is that aC++ is not recognizing extract_int_ as a type, so a preceding typename keyword is required for it to compile. Hoping to get instruction on how to change this so that it won't break other compilers? Thanks! boost/spirit/core/primitives/impl/numerics.ipp:305 return extract_int_<(MaxDigits >= 0)>::template apply<Radix, MinDigits, MaxDigits, Accumulate>:: f(scan, n, count); fixed for aC++ is as follows, but may break other compilers??: return typename extract_int_<(MaxDigits >= 0)>::template apply<Radix, MinDigits, MaxDigits, Accumulate>:: f(scan, n, count); -Jerry

3 2

Math functions for statistics - a draft TR2 proposal.
by Paul A Bristow 13 Jul '04

13 Jul '04

As promised recently, I am presenting a draft of proposals for math functions which are needed for even most elementary statistics. I have been encouraged to submit this to both the C and C++ Standard Library groups at the same time. (They seem to speaking more than in the past). These are additions to the list drawn up by Walter Brown accepted into TR-1. The style and format follows his closely even though there were some opposition to them from the C++ community. However I think we have to accept that C and C++ compatibility are valued more than C++ 'ideality', and not try to re-open this area of dissent. The draft has been uploaded to the files area in a new folder Math Functions as "More Mathematical Functions.pdf" 220 kb. I'd be grateful if some CVS whizz would copy it to the sandbox as I know that many are unable to access the fiels section. It would be useful to have comments on 1 Typographical mistakes. 2 Mathematical mistakes (prepared by someone with seriously rusty math!). 3 The choice of functions espcially if there are any your feel strongly are missing, or are not needed (say why). 4 The choice of names. Clarity is preferred to curtness. 5 The choice of names for derivatives like the inverse and complement. I have added suffixes _inc and _c (or _com?). ( for C there will be suffixes f and l for the float and long double versions). Thanks. Paul PS I am on holiday for two weeks and will not respond to your observations until July. Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow(a)hetp.u-net.com

2 3

making cvs change for the first time
by DY, JERRY U (SBCSI) 13 Jul '04

13 Jul '04

After several hours of trying, I finally got cvs to checkout the boost module into my server. I'm still reading the book on cvs, since I've never used that before (we use ClearCase here). I would like to starting "checking in" some changes I have made over the last coupleof months from my local copy of the boost source (mostly to get it to compile using aC++) so before I do anything that might break something, I wanted to advertise what I plan to do so the kind and knowledgeable folks of this list can guide me appropriately. I'll start with the simplest of changes: boost/config/compiler/hp_acc.hpp:45 =====old========== #if (__HP_aCC <= 53800 ) # define BOOST_NO_MEMBER_TEMPLATE_KEYWORD #endif =====new========= #if (__HP_aCC >= 50000 ) && (__HP_aCC <= 53800 ) || (__HP_aCC < 31300 ) # define BOOST_NO_MEMBER_TEMPLATE_KEYWORD #endif commit command to run: cvs commit -m "updated so template keyword is used for aC++ 3.13 & above" hp_acc.hpp Thanks! -Jerry

1 0

RE: [boost] Re: [iterator_facade] postfix ++/--
by Glen Knowles 13 Jul '04

13 Jul '04

> From: David Abrahams > > iterator_facade now has to choose between *r++ = o being > valid and being a conforming TR1 input iterator (which > requires *r++ is of type T -- we have since declared that a > defect and *r++ need only be convertible to T). It makes > that choice by looking at the CategoryOrTraversal parameter: > iff it's convertible to std::output_iterator_tag, *r++ = o > will be valid. > > I am thinking it might be more appropriate to detect that *r > is a proxy, and only make *r++ = o valid in that case. Can > anyone think of a reason that a non-writable iterator > implementation would need to return a proxy from its operator*? I may be confused as what qualifies as a proxy, but there is the vector<bool> case. OTOH, if you're talking about needing to reach back into the container its probably fine. I can imagine a caching scheme that returns a week_ptr and goes back to the container to recreate it if its gone, but I don't think I'd want to do it. :) Glen

2 1

[iterator_facade] postfix ++/--
by David Abrahams 13 Jul '04

13 Jul '04

I'm getting ready to fix the issues we've discussed with postfix ++ (and by extension, --) in iterator_facade. Basically, the current implementation works for forward iterators but not for some input iterators: { self x = *this; ++*this; // <== here return x; } The problem is that for many input iterators, all copies reference the same element. The marked line increments the iterator, which causes the current element of the sequence to be skipped, so *a++ yields the /next/ element. To fix that, a++ needs to return a proxy type. When considering this stuff, please look at n1640 and not C++98 or TC1, as n1640 contains fixes for outright bugs that survived to TC1 as well. In particular, *a++ was required to return an input iterator's value_type until recently. If we don't know for certain that the iterator is a forward iterator and if *a returns something convertible to T const& (where T is the iterator's value type) it seems to me that we *must* assume that all copies of the iterator reference the same element, so the result of postfix ++ must be a proxy that contains a copy of *a. The new iterator framework is intended to support iterators with bidirectional traversal that are not conforming forward iterators (e.g. their operator* may return by-value). If an iterator is incrementable it is also dereferenceable, but the same doesn't hold for decrementability, so I'm not sure what to do about the result of postfix --. The best solution I can think of is that the actual decrement is delayed, and the iterator being decremented contains a flag that says "do an extra decrement before the next operation other than postfix decrement". That's a really bad solution, though: you can't really do a decrement in the destructor because it might throw, and such an iterator could easily have side-effects, so it'd be easy to get the iterator out-of-synch with expectations. Thoughts? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

3 9

Re: Re:[boost] [1.32 release] TODO list synchronization
by JOAQUIN LOPEZ MU?Z 13 Jul '04

13 Jul '04

----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Martes, Julio 13, 2004 6:52 pm Asunto: Re:[boost] [1.32 release] TODO list synchronization [...] > >> Serialization > >> ///////////// > > > >> Robert Ramey writes: > > > > c) check in > [...] > I haven't seen any test results from boost test servers for the > serialization library - I expect to see some soon. Excuse me if I'm wrong, but seems to me you've forgotten to add an entry for your library in status/Jamfile to enable automatic testing. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

CVS error for boost/config/platform/win32.hpp
by Michael Glassford 13 Jul '04

13 Jul '04

cvs commit: [14:55:18] waiting for david_abrahams's lock in /cvsroot/boost/boost/boost/config/platform Mike

2 1

RE: [boost] Re: "memory access violation" in boost::serialization
by Robert Ramey 13 Jul '04

13 Jul '04

Dirk Griffioen wrote: > I also outcommented line 125. > We will, however, upgrade to #20 as soon as possible. Note that #20 and subsequent versions do not have boost/serialization/shared_count.hpp but rather use a very crude hack to gain access to private variables within shared_count. Hopefully this will be addressed in a better way in the near future. You might want to wait just a tiny bit. It looks like serialization may be included in the upcoming boost release. If the release works out soon you might want to move right to boost 1.32. If the release boggs down or for some reason its inconvenient for you do move to 1.32 - you can use to #20. #20 is the last draft. I've tested it extensively with 1.31. >We have a lot of platforms here (HP, AIX, SUN, VMS, AS400 and Mainframe >- with different versions of native compilers and/or gcc) and it is >likely we will port to those platforms. If there's an interest, it might >be possible to gather some figures. Hmmm - embarrassment of riches. It is possible you might be able to run - at least occasionally the bjam test suite for some of the less common platforms? I would love to know how boost (and of course serialization) work with AS400 and Mainframe(?). I believe the others are already covered. If you're willing to run the tests, developers might be more willing the help with the porting. Robert Ramey

1 0

[program_options] Comeau DLL failures
by Vladimir Prus 13 Jul '04

13 Jul '04

Hello, the program_options test results for Comeau (e.g. http://tinyurl.com/4zl6f) show that it does not understand __declspec. Anybody has ideas why? Maybe, we should pass "--windows" to that compiler, or somehow enable __declspec support? - Volodya

1 0

Sombody broke the build system?
by David Abrahams 13 Jul '04

13 Jul '04

This just started happening: cd c:/tmp/ myjam -sTOOLS=gcc foo.obj BD Software STL Message Decryptor v2.43 for gcc c:\tmp\../boost/tools/build/v1\testing.jam:51: in boost-test *** argument error * rule get-library-name ( path ) * called with: ( ) * missing argument path c:\tmp\../boost/tools/build/v1\testing.jam:21:see definition of rule 'get-library-name' being called c:\tmp\../boost/tools/build/v1\testing.jam:470: in run Jamfile:3: in load-jamfiles c:\tmp\..\boost\tools\build\v1\bootstrap.jam:22: in boost-build c:\tmp\boost-build.jam:6: in module scope Compilation finished at Tue Jul 13 08:46:09 -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0