- Boost - lists.preview.boost.org

Boost.Test token_iterator_test failure
by Gennadiy Rozental 29 Sep '04

29 Sep '04

Hi, Looks like subject test fails at runtime on following line: std::list<char> l; // here I populate l; std::string s; s.assign( l.begin(), l.end() ); // <---------- HERE Funny things is that it start working if I change list to vector. Is this some kind of gcc STL bug? Gennadiy.

2 4

Suspicious warning message python/src/object/function.cpp
by Neal D. Becker 29 Sep '04

29 Sep '04

Current boost.cvs, gcc-3.4.2: /usr/local/src/boost.cvs/libs/python/build/../src/object/function.cpp:101: warning: right-handoperand of comma has no effect

6 7

most boost.python tests fail on Tru64
by Markus Schöpflin 29 Sep '04

29 Sep '04

After I finally got the regression tests running again on my machine, I would like to figure out, why most of the python tests are failing. For an example error message see http://tinyurl.com/46he3 . Has anybody any idea as to where I should start looking for this? Markus

2 3

RE: [boost] Re: [shared_ptr] Interlocked* - possible bug?
by Ben Hutchings 29 Sep '04

29 Sep '04

John Torjo <john.lists(a)torjo.com> wrote: > Ben Hutchings wrote: <snip> > > expired() may read the count as still being 1 and so return false, > > but I believe the wnd_shared_ptr constructor will catch the fact > > that the pointer really has expired. Unfortunately I can't yet > > see the code to confirm this! > > By looking at the code, I would think not. But I may be wrong. > Anyway, I've posted the code in my other post. Thanks for that. Supposing that expired() wrongly returns false because use_count is really 0 but it gets an old non-zero value. Then lock() attempts to construct a shared_ptr: calls shared_ptr<T>::shared_ptr<T>(weak_ptr<T> const &) calls detail::shared_count::shared_count(weak_count const &) calls detail::sp_counted_base::add_ref_lock() calls detail::atomic_conditional_increment( long volatile &) either reads the count as 0 or calls _InterlockedCompareExchange fails and returns 0 then loops around and reads the count as 0 returns 0 throws bad_weak_ptr catches bad_weak_ptr returns 0 OK?

3 2

[Date-Time] Regressions/failures with Intel 7.1/Linux
by Aleksey Gurtovoy 29 Sep '04

29 Sep '04

What should we do about these three: http://tinyurl.com/4hbok http://tinyurl.com/4vv64 http://tinyurl.com/4a2xs ? -- Aleksey Gurtovoy MetaCommunications Engineering

2 2

Re:[boost] serialization: buffers
by Robert Ramey 29 Sep '04

29 Sep '04

>I've a class like this: >class Example{ >int str[BSize]; >int *p; >}; >Where p points to next available element (p==str+BSize is possible when it >is full). I.e. str is like begin() and p is like end(). I want to add a >serialize() function, something like this: >template<class Archive> void serialize(Archive &ar,const unsigned int){ >ar & BOOST_SERIALIZATION_NVP(buf,p); >} >but there seems to be no support for buffers like this? Of course the following would work: ar & BOOST_SERIALIZATION_NVP(buf,str); but it would copy too many elements. Or you might try the following (non-portable) idea ar & BOOST_SERIALIZATION_NVP(buf, make_binary_object((p - str)* sizeof(int), str) ); But really, I think you might be best off replacing the class above with class Example { std::slist<int> str; // or maybe std::vector<int> str } For which serialization is already implemented. Robert Ramey

2 1

Re: [boost] [serialization] documentation for xml archive usage
by Robert Ramey 28 Sep '04

28 Sep '04

>> Oh - no. Use the variable name for the tag not the name of the type. >> This is encouraged by usage of the idiom >> >> ar & BOOST_SERIALIZATION_NVP(my_variable); >Might I also suggest a similar interface which allows the caller to specify >the name to go with the value: >BOOST_SERIALIZATION_NAME_VALUE ("variable", m_variable); The following already exists. make_nvp("variable", m_variable); The above macro was only created to avoid retyping the variable name in the Most common case. Robert Ramey

1 0

[Thread] GCC 2.95/STLPort/Linux static lib failures
by Aleksey Gurtovoy 28 Sep '04

28 Sep '04

Is it the test environment that is at failt here (from http://tinyurl.com/5t5mf) /usr/bin/ld: cannot find -lstlport_gcc_stldebug_static collect2: ld returned 1 exit status set -e LD_LIBRARY_PATH=/usr/local/gcc-2.95.3/stlport-4.5.3/lib:/usr/local/gcc-2.95.3/lib:$LD_LIBRARY_PATH export LD_LIBRARY_PATH "/usr/local/gcc-2.95.3/bin/g++" -static -g -pthread -pthread -o "../bin/boost/libs/thread/test/test_barrier_lib.test/gcc-2.95.3-stlport-4.5.3-linux/debug/runtime-link-static/threading-multi/test_barrier_lib" -L"../bin/boost/libs/thread/build/libboost_thread.a/gcc-2.95.3-stlport-4.5.3-linux/debug/runtime-link-static/threading-multi" -L"../bin/boost/libs/test/build/libboost_unit_test_framework.a/gcc-2.95.3-stlport-4.5.3-linux/debug/runtime-link-static/threading-multi" -L"/usr/local/gcc-2.95.3/stlport-4.5.3/lib" -L"/usr/local/gcc-2.95.3/lib" "../bin/boost/libs/thread/test/test_barrier_lib.test/gcc-2.95.3-stlport-4.5.3-linux/debug/runtime-link-static/threading-multi/test_barrier.o" "../bin/boost/libs/thread/test/test_barrier_lib.test/gcc-2.95.3-stlport-4.5.3-linux/debug/runtime-link-static/threading-multi/tss_null.o" "../bin/boost/libs/thread/build/libboost_thread.a/gcc-2.95.3-stlport-4.5.3-linux/debug/runtime-link-static/threading-multi/libboost_thread-gcc295-mt-sgdp-1_32.a" "../bin/boost/libs/test/build/libboost_unit_test_framework.a/gcc-2.95.3-stlport-4.5.3-linux/debug/runtime-link-static/threading-multi/libboost_unit_test_framework.a" "../bin/boost/libs/thread/build/libboost_thread.a/gcc-2.95.3-stlport-4.5.3-linux/debug/runtime-link-static/threading-multi/libboost_thread-gcc295-mt-sgdp-1_32.a" "../bin/boost/libs/test/build/libboost_unit_test_framework.a/gcc-2.95.3-stlport-4.5.3-linux/debug/runtime-link-static/threading-multi/libboost_unit_test_framework.a" -lrt -lstlport_gcc_stldebug_static -lrt -Wl,-rpath-link,. ? -- Aleksey Gurtovoy MetaCommunications Engineering

3 5

Re:[boost] [serialization] documentation for xml archive usage
by Robert Ramey 28 Sep '04

28 Sep '04

>However, this triggers a BOOST_STATIC_ASSERT in >basic_xml_oarchive<Archive>::save_override<T>(const T&, BOOST_PFTO int). >The implementation insists that all serialized types be wrapped in a >nvp<T>. That is the intent. >But I couldn't find an >explanation in the docs what special steps a user is supposed to take >if the data shall be serialized into an xml archive. (The only hint >that xml archives need special care that I found was the description >of the header file nvp.hpp libs/serialization/doc/headers.html: "To >associate a name tag with a serializable object. This is necessary to >properly render an xml archive which includes the object name." BTW, >this webpage claims nvp.hpp is in boost/archive, but in fact it is in >boost/serialization.) >Do I need to write > ar & nvp<MyMemberType>("my_member_tag", this->my_member); >in my serialization functions for every variable I want to > (de-)serialize? Can I choose an arbitrary tag for each variable or is >it supposed to be consistent for all variables of a specific type? Oh - no. Use the variable name for the tag not the name of the type. This is encouraged by usage of the idiom ar & BOOST_SERIALIZATION_NVP(my_variable); >Am I correct to assume that the code will still work if I serialize into >a "normal" text archive and the nvp will essentially be ignored? And all other archives as well - with no extra runtime overhead (assuming a decent optimizing compiler) There a section Reference:Class Serialization:Serialization Wrappers:Name-Value pairs where this is described. Perhaps this isn't obvious from contents. >May I suggest that a section explaining the issues with xml archives be >added to the docs before the 1.32 release? Yes you may.

4 3

The Smart Container library
by brangdon＠cix.compulink.co.uk 28 Sep '04

28 Sep '04

In-Reply-To: <1256163046.20040926162826(a)topmail.sk> I'm very dubious about using: vec.begin()->bar(); instead of: (*vec.begin())->bar(); It means that ptr_vector<T> is not syntactically a drop-in replacement for vector<T *> or vector<shared_ptr<T> >. Won't that make it unnecessarily difficult to "upgrade" existing classes, and harder to switch back again should the need arise? Doesn't it also obscure what is going on? It seems a fundamentally wrong notation to me. -- Dave Harris, Nottingham, UK

2 1