- Boost - lists.boost.org

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