- Boost - lists.boost.org

Re: [ublas] Intel 8.1 failures
by Michael Stevens 04 Oct '04

04 Oct '04

Stefan wrote: > I've marked them as expected. Anyway, it's not clear to me why they > don't occur on Intel 8.0. It is because the test harness specifically avoids using std::complex for intel-windows 8.0 and earlier! 8.0 is also buggy. I know this is confusing, but without this special case to avoid link failures I cannot see if there are any runtime errors. This is more important to me then this annoying corner case. At the current pace Intel will never fix this bug! So I will probably extend the condition to 8.1 and remove the markups. For now I would rather the failures show up for the Intel compiler people to see!! Michael

1 0

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

04 Oct '04

Stefan wrote: > Anyway, as I could see in cvs, Micheal has now removed the markup. Results are in now. You can see cw-8.3-release has no problems. cw-8.3 has the old compile time errors. I not sure if there is a good reason if this is because the two are subtly different compiler versions or incidental compiler options. The compiler options are available for the failing run but not the pass runs. Unless a cw-8.3 guru see an obvious problem has a quick fix then I will look into modifying the source to avoid this compiler confusion. The error is always at the point of the following or similar instantiations indexing_matrix_assign (functor1_type::template make_debug_functor<typename matrix<value_type, row_major>::reference, value_type> (), cm, e, row_major_tag ()); I believe the 'template make_debug_functor<..> ()' is the source of the problem. This could be replaced by a static member template which deduces which functor type to return. Michael

1 0

RE: [boost] Re: Long toolset names
by Stefan Seefeld 04 Oct '04

04 Oct '04

> From: Tony Juricic [mailto:tonygeek@yahoo.com] > Sent: October 1, 2004 11:10 > As far as MS VS IDE is concerned, build directory names like "debug > runtime-static threading-multi" (with the space character) > would make life > easier than directory tree like the current > "...debug/runtime-static/threading-multi" because the string "debug > runtime-static threading-multi" can become > $(ConfigurationName) macro in > IDE. I'd strongly suggest not to use spaces in file / directory names, as that makes life unnecessarily hard for users of command-line tools. But I agree that collapsing some option sets into single directory names would be quite convenient. Regards, Stefan

5 4

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