- Boost - lists.boost.org

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