July 2004 - Boost - lists.boost.org

[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 16 Jul '04

16 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