October 2004 - Boost - lists.boost.org

Long toolset names
by Aleksey Gurtovoy 04 Oct '04

04 Oct '04

What should we do about the following Boost.Build toolsets which filename's length exceeds 31 characters: tools/build/v1/como-win32-4.3.3-vc7.1-tools.jam tools/build/v1/intel-win32-7.1-vc6-stlport-4.5.3-tools.jam ? -- Aleksey Gurtovoy MetaCommunications Engineering

7 12

New Linux regressions
by Aleksey Gurtovoy 04 Oct '04

04 Oct '04

We seem to have an alarming number of new regression with two Linux toolsets, "gcc-2.95.3-stlport-4.5.3-linux" and "intel-8.0-linux" -- http://tinyurl.com/5p5ru. Intel looks particularly bad, due to what seems to be a problem with system headers: /opt/intel_cc_80/include/c++/functional(132): error: identifier "_Tq" is undefined ?bool operator()(const _Ty& _Left, const _Tq& _Right) const ? ^ detected during instantiation of class "std::less<_Ty> [with _Ty=boost::detail::sp_counted_base *]" at line 432 of "/boost/head-regression/boost/boost/detail/shared_count.hpp" compilation aborted for /boost/head-regression/boost/libs/test/build/../src/test_tools.cpp (code 2) . /opt/intel_cc_80/bin/iccvars.sh icpc -c -w1 -DBOOST_TEST_NO_AUTO_LINK=1 -g -O0 -I"../bin/boost/libs/test/build" -I"/boost/head-regression/boost" -o "../bin/boost/libs/test/build/libboost_test_exec_monitor.a/intel-8.0-linux/debug/test_tools.o" "/boost/head-regression/boost/libs/test/build/../src/test_tools.cpp" The problems with GCC/STLPort are different: the linker cannot find a number of different _STL:: symbols that supposedly should be present in the library: Linker output [2004-10-02 04:30:36 UTC]: ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0x501): In function `boost::execution_monitor::execute(bool, int)': /boost/head-regression/boost/libs/test/src/execution_monitor.cpp:245: undefined reference to `_STL::domain_error type_info function' ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0x5c5):/boost/head-regression/boost/libs/test/src/execution_monitor.cpp:247: undefined reference to `_STL::invalid_argument type_info function' ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0x691):/boost/head-regression/boost/libs/test/src/execution_monitor.cpp:249: undefined reference to `_STL::length_error type_info function' ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0x765):/boost/head-regression/boost/libs/test/src/execution_monitor.cpp:251: undefined reference to `_STL::out_of_range type_info function' ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0x841):/boost/head-regression/boost/libs/test/src/execution_monitor.cpp:253: undefined reference to `_STL::range_error type_info function' ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0x915):/boost/head-regression/boost/libs/test/src/execution_monitor.cpp:255: undefined reference to `_STL::overflow_error type_info function' ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0x9f1):/boost/head-regression/boost/libs/test/src/execution_monitor.cpp:257: undefined reference to `_STL::underflow_error type_info function' ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0xac5):/boost/head-regression/boost/libs/test/src/execution_monitor.cpp:259: undefined reference to `_STL::logic_error type_info function' ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0xba1):/boost/head-regression/boost/libs/test/src/execution_monitor.cpp:261: undefined reference to `_STL::runtime_error type_info function' ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0x18d9): In function `main': /boost/head-regression/boost/boost/test/minimal.hpp:135: undefined reference to `_STL::cerr' ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0x1959):/boost/head-regression/boost/boost/test/minimal.hpp:141: undefined reference to `_STL::cout' ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0x1b2f):/boost/head-regression/boost/boost/test/minimal.hpp:130: undefined reference to `_STL::cerr' ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0x1cba): In function `__static_initialization_and_destruction_0': /usr/local/gcc-2.95.3/stlport-4.5.3/include/stlport/locale:145: undefined reference to `_STL::ios_base::_Loc_init::_Loc_init(void)' ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0x1cca): In function `__static_initialization_and_destruction_0': /usr/local/gcc-2.95.3/stlport-4.5.3/include/stlport/iostream:71: undefined reference to `_STL::ios_base::Init::Init(void)' ... It might be a problem with the toolset, but it's hard to say without seeing the linker's command line. Martin, would it be possible for you to modify your regression driver to always run with "-d2" flag? In any case, any help on timely resolution of the above issues would be highly appreciated. -- Aleksey Gurtovoy MetaCommunications Engineering

3 2

[ublas] Intel 8.1 failures
by Stefan Slapeta 04 Oct '04

04 Oct '04

An old Intel failure popped up here. I don't know why this doesn't occur on 8.0 anymore! A workaround is not using the shared runtime. Thoughts? Stefan

3 3

re: ublas / cw 8.3
by Michael Stevens 04 Oct '04

04 Oct '04

Stefan, > Is there a particular reason why ublas is marked unusable for cw 8.3? > > Stefan > It used to give a lot of nasty template errors of the form: # 678: :, value_type> (), cm, e, row_major_tag ()); # Error: ^ # illegal template argument dependent expression I say 'used to' because the results are now hidden behind the grey 'n/a'. I doubt there is much that can be done however. If you have better information and the compiler we could take a look! Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

4 5

Re:[boost] Re:Re: Output formatters: different approaches
by Robert Ramey 04 Oct '04

04 Oct '04

http://lists.boost.org/MailArchives/boost/msg71956.php Message: 2 Date: Fri, 01 Oct 2004 10:54:02 +0400 From: Vladimir Prus <ghost(a)cs.msu.su> Subject: Vladimir Prus wrote: >Robert, can I first of all ask you to use a mailer, or a news reader, which >preserves threading? Recently experiments have shown that Mozilla >Thunderbird, for example, works fine both with emails and with NTTP >gateway, and it's free. You can also try some other clients, but please do >something about the issue. Hmmm - I've been trying to configure my MS Outlook to do this and its driving me crazy. >>> The idea of the library, as I see it, is to provide object >>> serialization, > but >>> - without the overhead serialization library has >>> - with extra layout tweaks > >>Yes, it would be nice. > > For objects of the type being discussed, (i.e. no pointers, no class > versioning, no memory tracking of duplicates, etc) the serialization > library has no extra runtime overhead. >Basically, I want every call I define to have a 'dump' >method which can be called from debugger. So, I need output facilities >available in every translation unit. >> If function output formatters is helpful for making output more easily >> presentable, fine. Though G. Rozenthal's, experiment makes me doubt this. >Which experiment? I was referring to Rozenthals post: http://lists.boost.org/MailArchives/boost/msg71956.php [On the other hand, if output formatters is to be an alternative implementation of the functionality in the serialization library ] >> I believe the demos and documentation in the serialization package show >> that it to be much, much easier to use than the proposed library for this >> purpose. >Robert, while I agree that serialization is immensely useful, the point you >make above is a bit skewed. Which example in the serialization library >shows how to change start/end delimiter of a vector? That's what the xml_archive does for name-value pairs. The same method could be used for any user defined types. Robert Ramey

3 4

RE: [boost] Re: Call for Volunteers: the Synopsis project
by Stefan Seefeld 04 Oct '04

04 Oct '04

> From: David Abrahams [mailto:dave@boost-consulting.com] > Sent: September 30, 2004 08:21 > Stefan has recently been trying to get compile-time constants from > sizeof() into the parser. As he knows, this is going to mean handling > such things as template instantiation and overload resolution. This > is a great opportunity to learn more about how C++ works and to create > a compiler platform that's actually usable by C++ programmers for > prototyping new features -- one of the major obstacles in C++ > standardization is that the source for the only open-source C++ > compiler has a steep learning curve. I should mention that the design of the C++ parser allows to manipulate the generated parse tree in-memory and write it out into a file again in a non-lossy way, i.e. it could indeed be used as a source-to-source compiler. Regards, Stefan

3 2

BGL: BCBuilderX compiler error
by Kaled Ahmed 04 Oct '04

04 Oct '04

The following snippet from the BGL User Guide and Reference Manual, gives an error using Borland CBX: template <typename Graph, typename TransDelayMap, typename VertexNameMap> void print_trans_delay( typename graph_traits<Graph>::edge_descriptor e, const Graph& g,TransDelayMAp delay_map, VertexNameMap name_map) { std::cout << "trans_delay(" << get(name_map, source(e,g)) << "," << get(name_map, target(e,g)) << ")= " << get(delay_map, e); } The error is: "untitled.cpp": E2449 Size of 'print_trans_delay' is unknown or zero at line 27 Please advise. --------------------------------- Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage!

2 1

New multi_index failures (--> mpl??)
by Stefan Slapeta 04 Oct '04

04 Oct '04

http://tinyurl.com/4nrt9 Aleksey, could this be a side effect of the last mpl fix for boost.test? Stefan

3 2

Some questions on boost threads
by Parameswaran, Vinod 04 Oct '04

04 Oct '04

Hello list, My name is P. Vinod and I am currently debugging an application that was initially written using single thread but later ported to multithreads. The threading has been done using Boost library functions. I am new to Boost library and would like to clarify some of my doubts with you. Please reply to vparameswaran(a)fcg.com I have been studying William Kempf's documentation on Boost threads (http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/threads .html) and all my questions are based on the references therein: 1. <begin quote> The template thread_specific_ptr <http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/class.b oost.thread_specific_ptr.html> is useful in the following cases: * An interface was originally written assuming a single thread of control and it is being ported to a multithreaded environment. <end quote> Is there any other way by which you could port a single threaded interface to multithreaded interface using Boost threads? My debugging approach will be based on your answer to this question. 2. Does anyone have some examples of scenarios wherein each of these classes could be used (would even appreciate reference to relevant docs., if any): a. barrier b. condition c. thread_group d. thread_specific_ptr 3. Assumption: In the case of a condition object, ONLY THE FOLLOWING METHODS could be used to specify the wait condition: a. template<typename ScopedLock, typename Pred> void wait(ScopedLock& lock, Pred pred); b. template<typename ScopedLock> bool timed_wait(ScopedLock& lock, const bool::xtime& xt); c. template<typename ScopedLock, typename Pred>bool timed_wait(ScopedLock lock, Pred pred); Is this correct? 4. <begin quote> A thread object has an associated state which is either "joinable" or "non-joinable". <end quote> Is this state indicated using a type or is merely implied by whether the default or the parameterized constructor is called for the creation of the thread object? 5. Could anyone give examples of the use of void join() and void yield()? (Would even appreciate reference to relevant docs., if any) 6. <begin quote> Template thread_specific_ptr stores a pointer to an object obtained via new on a thread-by-thread basis and calls delete on the contained pointer when the thread terminates. Each thread initially stores the null pointer in each thread_specific_ptr instance. <end quote> Does each thread create its own 'object' referred to here and modify its thread_specific_ptr class by invoking void reset(T* p=0) ? 7. <begin quote> The template thread_specific_ptr is useful in the following cases: * Each thread of control invokes sequences of methods that share data that must be logically accessed through a globally visible access point, but are physically unique for each thread, instead of being explicitly passed. <end quote> <begin quote> Template thread_specific_ptr stores a pointer to an object obtained via new on a thread-by-thread basis and calls delete on the contained pointer when the thread terminates. Each thread initially stores the null pointer in each thread_specific_ptr instance. <end quote> >From the above statements, I could draw the inference that the thread_specific_ptr object stores the data that is shared amongst the various methods invoked from within a thread; however this data is not shared amongst threads and is unique for each thread. <begin quote> thread_specific_ptr construct/copy/destruct 1. thread_specific_ptr(); Requires: The expression delete get() is well formed. Effects: A thread-specific data key is allocated and visible to all threads in the process. Upon creation, the value NULL will be associated with the new key in all active threads. <end quote> <begin quote> 1. ~thread_specific_ptr(); ..... For this reason you should not destroy a thread_specific_ptr <http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/thread_ specific_ptr.html> object until you are certain there are no threads running that have made use of its thread specific storage. <end quote> The above statements seem to contradict the previous quotes, in that a thread-specific data key is visible to all the threads in the process and thread-specific storage is shared amongst multiple threads. Could anyone dispel the apparent ambiguity here? Also, what is the concept of "data key"? Gratefully appreciate your time and advice on the above. Vinod

1 0

White cells in regression tables?
by David Abrahams 04 Oct '04

04 Oct '04

I posted this yesterday, but got no reply. Can anyone explain the vast number of white cells in the Boost.Python regression log? In particular, the tests noted below don't look like they're reported correctly in the log. ------ Due to what appears to be an MPL problem, neither libs/python/test/polymorphism.cpp nor libs/python/test/polymorphism2.cpp are compiling on vc6. This fact is reflected only strangely by the posted regression log, as white cells. ------ -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

4 7