October 2004 - Boost - lists.preview.boost.org

RE: [boost] Re: Graph broken for vc7.1 after 1.31?
by Christian Wahlgren 05 Oct '04

05 Oct '04

Hi again, I still can't compile the graph library after the last change on the 29:th of Sept. Strangely I see regression tests been run on vc7.1 since then and I wonder how that could be possible? http://www.meta-comm.com/engineering/boost-regression/developer/graph.html Regards, Christian -----Original Message----- From: Christian Wahlgren on behalf of Christian Wahlgren Sent: Thu 2004-09-30 09:06 To: boost(a)lists.boost.org Cc: Subject: RE: [boost] Re: Graph broken for vc7.1 after 1.31? Hi, Perhaps my fault - It wasn't that easy to just define YY_NO_UNISTD_H to make graph compile with vc7.1. The problem is that two non-ANSI C functions is called: b->yy_is_interactive = file ? (isatty( fileno(file) ) > 0) : 0; A little documentation search on Win32 gives: <io.h> int _isatty(int); <stdio.h> int _fileno(FILE*); As for how to solve these non-portable stuff with perhaps some BOOST defines, I think you all know better than I do. Kindest Regards, Christian -----Original Message----- From: Doug Gregor [mailto:dgregor@cs.indiana.edu] Sent: Wed 2004-09-29 17:45 To: boost(a)lists.boost.org Cc: Subject: Re: [boost] Re: Graph broken for vc7.1 after 1.31? On Sep 29, 2004, at 9:25 AM, Vladimir Prus wrote: >> Were you able to check it on VC 7.1? > > No. I'd appreciate if you could try there. I'll try to do so later. > >>>> We'll deprecate it in 1.32.0 (when, hopefully, we will >>>> have a new GraphViz parser that works well) and remove it >>>> afterwards. >>> >>> How the new parser will be implemented? >> >> Spirit. > > Is it written yet? Would be interesting to see. I think the parser is written but the semantic actions are not, so it isn't functional yet. We're trying to unify on some kind of system for dynamic properties, so that we can deal with reading in arbitrary vertex/node attributes. I have a GraphML parser that handles dynamic properties, which hopefully will also work well in the new GraphViz parser. If I get some time post-1.32.0 (hah!), we'll try to get all those bits in. >> Granted, they've dropped support for older, broken compilers, >> so someone will still be getting hurt by this. > > Right. OTOH, I start to wonder if BGL should drop support for old > compilers > as well. (borland and vc6 are marked unusable already). There seem to > be a > lot of workaround inside BGL which means even reading the code hard. We promised to keep the parts of the BGL needed for the Python lib in working order. But I've marked borland and vc6 unusable because they've never really been usable and are a huge maintenance burden. Doug _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

3 2

[1.32 Release] Fixing long filenames (continued)
by Aleksey Gurtovoy 05 Oct '04

05 Oct '04

First of all, thanks to everybody who responded to my original request. Things are looking better now, but we still have some way to go -- http://www.meta-comm.com/engineering/boost/long_names.html. I'm reciting the issues below with some comments/requests. archive ------- boost/archive/polymorphic_binary_wiarchive.hpp: filename > 31 chars boost/archive/polymorphic_binary_woarchive.hpp: filename > 31 chars Robert, could you please fix these? build ----- tools/build/v1/como-win32-4.3.3-vc7.1-tools.jam: filename > 31 chars tools/build/v1/intel-win32-7.1-vc6-stlport-4.5.3-tools.jam: filename > 31 chars I'll take care of these two myself, but somebody from the Boost.Build camp needs to look/comment on these: tools/build/v2/test/railsys/libx/include/libx/test_libx.h: file's directory depth exceeds 8 levels tools/build/v2/test/startup/boost-root/tools/build/boost-build.jam: file's directory depth exceeds 8 levels tools/build/v2/test/startup/boost-root/tools/build/bootstrap.jam: file's directory depth exceeds 8 levels mpl --- libs/mpl/doc/ref/Extensible_Associative_Sequence.html: filename > 31 chars libs/mpl/doc/ref/Reference/BOOST_MPL_AUX_LAMBDA_SUPPORT.html: filename > 31 chars Obviously my department. property_map ------------ libs/property_map/const_associative_property_map.html: filename > 31 chars I can take care of it, but wouldn't mind delegating it either. Anybody? serialization ------------- libs/serialization/example/demo_portable_binary_archive.cpp: filename > 31 chars libs/serialization/test/test_demo_fast_binary_archive.cpp: filename > 31 chars libs/serialization/test/test_demo_portable_binary_archive.cpp: filename > 31 chars libs/serialization/test/test_polymorphic_archive_data.cpp: filename > 31 chars libs/serialization/test/test_polymorphic_archive_data.hpp: filename > 31 chars libs/serialization/vc6ide/demo_portable_binary_archive.dsp: filename > 31 chars libs/serialization/vc7ide/demo_portable_binary_archive.vcproj: filename > 31 chars libs/serialization/vc7ide/test_level_class_info_load.vcproj: filename > 31 chars libs/serialization/vc7ide/test_level_class_info_save.vcproj: filename > 31 chars libs/serialization/vc7ide/test_level_not_serializable.vcproj: filename > 31 chars libs/serialization/vc7ide/test_simple_derived_class.vcproj: filename > 31 chars Robert, again, this is your domain. spirit ------ libs/spirit/phoenix/doc/lazy_construction_and_conversions.html: filename > 31 chars Joel, Hartmut? test ---- libs/test/build/msvc71_proj/ifstream_line_iterator_test.vcproj: filename > 31 chars libs/test/build/msvc71_proj/test_case_template_example.vcproj: filename > 31 chars libs/test/doc/components/test_tools/reference/BOOST_CHECK_EQUAL_COLLECTIONS.html: filename > 31 chars libs/test/doc/components/unit_test_framework/components/test_case/abstract_interface.html: file path is > 100 chars libs/test/doc/components/unit_test_framework/components/test_case/auto_register_facility.html: file path is > 100 chars libs/test/doc/components/unit_test_framework/components/test_case/boost_function_test_case.html: file path is > 100 chars libs/test/doc/components/unit_test_framework/components/test_case/function_test_case.html: file path is > 100 chars libs/test/doc/components/unit_test_framework/components/test_case/parameterized_boost_function_test_case.html: file path is > 100 chars, filename > 31 chars libs/test/doc/components/unit_test_framework/components/test_case/parameterized_class_test_case.html: file path is > 100 chars, filename > 31 chars libs/test/doc/components/unit_test_framework/components/test_case/parameterized_function_test_case.html: file path is > 100 chars, filename > 31 chars libs/test/doc/components/unit_test_framework/components/test_case/test_case_template.html: file path is > 100 chars libs/test/doc/components/unit_test_framework/components/test_log/custom_log_formatter.html: file path is > 100 chars libs/test/test/test_files/errors_handling_test.pattern.gcc: filename > 31 chars Gennady, I realize this can be a bit of pain, but could you please take care of this? utility ------- libs/utility/enable_if_dummy_arg_disambiguation.cpp: filename > 31 chars libs/utility/enable_if_namespace_disambiguation.cpp: filename > 31 chars libs/utility/enable_if_partial_specializations.cpp: filename > 31 chars I'll deal with these myself. -- Aleksey Gurtovoy MetaCommunications Engineering

4 6

RE: [boost] RE: Re: Graph broken for vc7.1 after 1.31?
by Christian Wahlgren 05 Oct '04

05 Oct '04

Hi Vladimir, Thanks, it compiles now. Regression tests - yes, I see that now that the graphviz utility part isn't tested. Whish list: Since the graphviz utility code is part of the library it should preferably be tested also? Regards, Christian -----Original Message----- From: Vladimir Prus [mailto:ghost@cs.msu.su] Sent: Tue 2004-10-05 11:54 To: boost(a)lists.boost.org Cc: Subject: [boost] RE: Re: Graph broken for vc7.1 after 1.31? Hi Christian, > I still can't compile the graph library after the last change on the 29:th > of Sept. I've removed the calls to 'isatty', let me know if it works now. > Strangely I see regression tests been run on vc7.1 since then and > I wonder how that could be possible? > > http://www.meta-comm.com/engineering/boost-regression/developer/graph.html Because the regression tests do not build the graphviz parser? - Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: JavaScript index?
by Jonathan Turkanis 05 Oct '04

05 Oct '04

"David Abrahams" <dave(a)boost-consulting.com> wrote in message news:uvfdwx3pm.fsf@boost-consulting.com... > > As long as we're tweaking the BoostBook look-and-feel, I'd like to > know the status of the "portable JavaScript index tree" project we > were discussing recently. I've even forgotten who was working on it > (shame on me). That would be me. :-) The docs are here: http://tinyurl.com/6tdvy. It's essentially finished, except for two points: 1. If it's integrated into Boost.Book, the documentation can be self-synchronizing, eliminating most need for the [link to this page] button. I think Reece Dunne did some work in this direction. 2. I'm planning to write a perl script which will make documentation writtenwith the tree control self-synchronizing even if it's not generated by Boost.Book. To understand what I mean by synchronization, see http://tinyurl.com/49hwe. Also note that the docs look better when the boost logo appears directly over the table of contents, as it does here: http://tinyurl.com/3p79x. Best Regards, Jonathan

9 22

size_t*size_t is not size_t
by Kasper Peeters 05 Oct '04

05 Oct '04

Hi, I need to handle extremely large sparse matrices, of approximately half a million square elements (with, typically, on the order of 5 million non-zero entries). The following, however, fails on a machine where std::size_t is 4 bytes long: #include <boost/numeric/ublas/matrix_sparse.hpp> int main () { using namespace boost::numeric::ublas; sparse_matrix<double> m(400000, 400000); } It fails with Assertion failed in file boost/numeric/ublas/functional.hpp at line 1345: (size1 * size2) / size1 == size2 Obviously, while both size1 and size2 fit in a 4-byte integer, the product does not, the calculation overflows, and this check fails. Can this problem be circumvented without modifying boost? Kasper

1 0

[test] problem in boost/test/detail/class_properties.hpp?
by Joaquín Mª López Muñoz 05 Oct '04

05 Oct '04

A recent update in boost/test/detail/class_properties.hpp replaces line 163: #ifndef __IBMCPP__ with #if BOOST_WORKAROUND(__IBMCPP__, BOOST_TESTED_AT(600)) I guess this is an error, since the checks are just the opposite. BTW, this change seems to be producing many regressions in Visual Age, all of them reported for boost/test/test_tools.hpp. HTH, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[multi_index] volunteer needed for small test with VC 7.0
by Joaquín Mª López Muñoz 04 Oct '04

04 Oct '04

Hi, recent changes in the CVS result in failures in Boost.MultiIndex for MSVC 7.0, see for instance: http://tinyurl.com/5nqv7 The problem seems to be ETI-related, and maybe I can apply the same patch already in effect for MSVC 6.0. If anyone with local access to MSVC 7.0 could help me try this, I'd be eternally grateful: * Update the CVS (the whole tree, please) * Change line 35 of boost/multi_index/detail/node_type.hpp #if BOOST_WORKAROUND(BOOST_MSVC,<1300) to #if BOOST_WORKAROUND(BOOST_MSVC,<1310) (note the change in VC version) * Change line 36 of boost/multi_index/detail/base_type.hpp #if BOOST_WORKAROUND(BOOST_MSVC,<1300) to #if BOOST_WORKAROUND(BOOST_MSVC,<1310) * run the tests for multi_index and report the results. Thank you very much in advance. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

re: [Thread] The last step
by Michael Stevens 04 Oct '04

04 Oct '04

On Friday 01 October 2004 15:32, "Aleksey Gurtovoy" <agurtovoy(a)meta-comm.com> wrote: > You can probably guess what I'm about to ask -- can we do something > about Intel 8.0/Linux failures? Looking at the output below (from > http://tinyurl.com/6mnzn) it seems to me that the test was attempted > to be linked against *both* GCC and Intel runtimes: I think the problem is that the compiler is running on a platform where the version of glibc is unsupported (too recent). I have come across the same problem myself. After much research I found the only workaround was to rename strol in the compilers libcprts.a This is a big hack but gets things compiling. I have a already manipulated libcprts.a but it is 1M. I can post it to whoever needs it however. Michael

3 3

RE: [boost] Proper threading (Was: Formal review of "Output Forma tters" library beginstoday )
by Rozental, Gennadiy 04 Oct '04

04 Oct '04

> Rozental, Gennadiy wrote: > > Hi, > > > > I would like to start with resolution. I vote NOT to accept this > > submission. > > Gentlemen, may I ask that you use mailers which preserve > correct threading? In > particular, in review of the outfmt library, each message > from Reece, Robert > and Gennadiy is completely unrelated to the thread, missing > the "References" > and "In-reply-to" headers. > > This makes follow the thread a nightmare. Even web-based > mailers nowdays > support proper threading. What do you do to break it? I use Outlook. In some cases it preserve "threading". In some not. Gennadiy.

9 12

Re: [review] Formal review of the Smart Container library starts today]
by Pavol Droba 04 Oct '04

04 Oct '04

Hi, First of all, I'd like to thank Thorsten for bringing up this library. It implements a very common programming pattern that is currently missing in STL or Boost. > * What is your evaluation of the design? I find the design sufficient and reasonable for the purpose of the library. There is only one important issue, that I find problematic (I have already mentioned it in the other mail). The issue is about the direct write access to the contained pointers, via the ptr_iterator. Using this interface, all invariants of the underlying container can be broken. It is not even possible to validate the problem. Therefor I suggest to remove it, unless it can be fixed. Still this access can be usefull from time to time, but I simply don't think, that it is worth the problems, it can bring. Documentation is not very clear about the problems. It merely notes, that algorithms like std::remove should not be used with the ptr_iterator. There is no explanation which algorithms are 'safe' and why are the others unsafe. After small analysis I have found out that there is actualy a very narrow set of algorithms that can be used (I have explained this in detail in the other mail). All these algorithms can be provided as member functions (similary like current remove and unique algorithms) or can be reimplemented with a help of swap_element(size_type, size_type) function (or something similar). Other small issues: * CloneManager::operator(). I don't like this notation. I would prefer something more explicit. I see no clear connection between this operator and the operation it provides. Also I don't understand the asymetry between CloneManager::clone function and operator(). Former is static, while the later is member function. Why? * I would like to see explicit allocator specification for underlying container. There were good reasons to provide it in the STL and from the same reasons I'd like to see it here. * Current implementation is restricted to non-null values. Still I think, that null support could be useful. Few functions for checking like is_null(index) and iterator.is_null() could handle do job. > * What is your evaluation of the implementation? I find the implementation good enough to be included in the boost. > * What is your evaluation of the documentation? Documentation is sufficient for the understanding the library, but there are several posibilities for improvements. First, I agree with point that was already mentioned here, that several small examples are better a long one. Introductory example is too long to be easily comprehended in the first reading. There is lot of rules and guideling that are explained only in a few sentences. Some of them would greatly benefit from a small example and others (like the one about 'safe' algorithms) are very underspecified. I would presonaly prefer several smaller hyperlinked files to a one long document. Although it is easier to print it, I found it harder to read it in the browser. > * What is your evaluation of the potential usefulness of the library? I think, that the library is very usefull. As I said it implements very common pattern, that is not sufficiently solved otherwise. > * Did you try to use the library? With what compiler? Did you have any problems? I have not compiled the library. > * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Few hours of reading the documentation and code and thinking about the possible issues. Also I spend some time in discussion with the author. > * Are you knowledgeable about the problem domain? This library deals with a common problem. I consider myself knowledgeable in this domain. > * Do you think the library should be accepted as a Boost library? > Be sure to say this explicitly so that your other comments don't obscure your > overall opinion. Yes, I do think that the library should be ACCEPTED as a Boost library. However I would like to see the issues I have described to be solved, or at least explained in the documentation in the sufficient detail. Here are my answers for some questions asked in the documentation: > 1. The reference type, SmartContainer::reference is indirected. This has the unfortunate consequence that eg. > we cannot use eg. ptr_vector with std::stack. The question is if its worth adding another policy just to achieve this. Considering the library purpose, I think, that the current state is sufficient. > 2. Is the ptr_array class worth the trouble? I would like to see it. Especialy if the null-value can be supported. > 3. The clone manager effective removes allocators from the container template parameter interface. > Can people who want to use allocators still do what they want? Yes, I'd like to see it there. > 5. Should SmartContainer::auto_type expose itself as a move_ptr? Unless the move_ptr would became a self-contained utility, possibly as another library, I think it should stay like this. > 6. Should iterator range versions of assign() and insert be replaced by an Boost.Range version? Ie, should we have > template< class SinglePassRange > > void insert( const Range& r ); > > instead of > > template< class InputIterator > > void insert( InputIterator f, InputIterator l ); Boost.Range is already a part of boost. I think that the later interface is obsolete now. > 10. should transfer() return iterator or iterator/bool pair like erase()/insert() do. For map, transfer has similar semantics to insert. I think, that interfaces should be similar as well. > 12. should we provide member algorithms for unsafe standard algorithms like unique() and remove? Eithter provide them as member function, or provide a means for standalone implementation. In any case it is wise to provide some functional variant. Best Regards, Pavol

2 6

vc8.0 toolset (bjam)
by John Torjo 04 Oct '04

04 Oct '04

Hi all, I finally installed vc8 beta. It seems that vc8-tools.jam has the path to the binary MSVC tools wrong: It is: VC80_ROOT ?= $(ProgramFiles:J=" ")"\\Microsoft Visual Studio .NET Whidbey\\VC7" ; But I think it should be: VC80_ROOT ?= $(ProgramFiles:J=" ")"\\Microsoft Visual Studio 8\\VC" ; At least that's what's needed on my machine... As a side note, I got a lot of warnings: cl : Command line warning D9035 : option 'GX' has been deprecated and will be re moved in a future release cl : Command line warning D9036 : use 'EHsc' instead of 'GX' Best, John -- John Torjo -- john(a)torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)

9 20

Yet another ScopeGuard
by Konstantin Echenko 04 Oct '04

04 Oct '04

Hi All. Some time ago Maxim Yegorushkin suggested use boost/bind to implement lazy ScopeGuard. I evolved this parasitic idea and reused a lot of code from boost/bind by preprocessing to implement make_guard binders. The ScopeGuard can be used as usual: scope_guard g = make_guard( func, args ); What do you think about it? Is it possible to "legalize" such approach? ========= #ifndef SCOPE_GUARD_HPP_INCLUDED #define SCOPE_GUARD_HPP_INCLUDED // scope_guard.hpp #include <boost/bind.hpp> //////////////////////////////////////////////////////////////////////////////////////////////// namespace boost { //////////////////////////////////////////////////////////////////////////////////////////////// namespace _bi { //////////////////////////////////////////////////////////////////////////////////////////////// class scope_guard_base { public: void dismiss() const { do_rollback_ = false; } protected: scope_guard_base(const scope_guard_base& other) : do_rollback_(other.do_rollback_) { other.dismiss(); } scope_guard_base() : do_rollback_(true) {} mutable bool do_rollback_; }; //////////////////////////////////////////////////////////////////////////////////////////////// template<class R, class F, class A> class scope_guard_impl : public scope_guard_base { public: scope_guard_impl(F f, A const& a) : rollback_(f, a) {} ~scope_guard_impl() { if(do_rollback_) rollback_(); } private: bind_t<R,F,A> rollback_; }; //////////////////////////////////////////////////////////////////////////////////////////////// } // namespace _bi //////////////////////////////////////////////////////////////////////////////////////////////// typedef _bi::scope_guard_base const& scope_guard; //////////////////////////////////////////////////////////////////////////////////////////////// // create make_guard() definitions by preprocessing boost::bind() sources #undef BOOST_BIND // it seems like authors forgot about it #define BOOST_BIND make_guard #define bind_t scope_guard_impl //////////////////////////////////////////////////////////////////////////////////////////////// // quotation from boost/bind.hpp // Copyright (c) 2001, 2002 Peter Dimov and Multi Media Ltd. // Copyright (c) 2001 David Abrahams // function pointers #define BOOST_BIND_CC #define BOOST_BIND_ST #include <boost/bind/bind_cc.hpp> #undef BOOST_BIND_CC #undef BOOST_BIND_ST #ifdef BOOST_BIND_ENABLE_STDCALL #define BOOST_BIND_CC __stdcall #define BOOST_BIND_ST #include <boost/bind/bind_cc.hpp> #undef BOOST_BIND_CC #undef BOOST_BIND_ST #endif #ifdef BOOST_BIND_ENABLE_FASTCALL #define BOOST_BIND_CC __fastcall #define BOOST_BIND_ST #include <boost/bind/bind_cc.hpp> #undef BOOST_BIND_CC #undef BOOST_BIND_ST #endif #ifdef BOOST_BIND_ENABLE_PASCAL #define BOOST_BIND_ST pascal #define BOOST_BIND_CC #include <boost/bind/bind_cc.hpp> #undef BOOST_BIND_ST #undef BOOST_BIND_CC #endif // member function pointers #define BOOST_BIND_MF_NAME(X) X #define BOOST_BIND_MF_CC #include <boost/bind/bind_mf_cc.hpp> #undef BOOST_BIND_MF_NAME #undef BOOST_BIND_MF_CC #ifdef BOOST_MEM_FN_ENABLE_STDCALL #define BOOST_BIND_MF_NAME(X) X##_stdcall #define BOOST_BIND_MF_CC __stdcall #include <boost/bind/bind_mf_cc.hpp> #undef BOOST_BIND_MF_NAME #undef BOOST_BIND_MF_CC #endif #ifdef BOOST_MEM_FN_ENABLE_FASTCALL #define BOOST_BIND_MF_NAME(X) X##_fastcall #define BOOST_BIND_MF_CC __fastcall #include <boost/bind/bind_mf_cc.hpp> #undef BOOST_BIND_MF_NAME #undef BOOST_BIND_MF_CC #endif // end quotation boost/bind.hpp /////////////////////////////////////////////////////////////// #undef BOOST_BIND #undef bind_t //////////////////////////////////////////////////////////////////////////////////////////////// } // namespace boost //////////////////////////////////////////////////////////////////////////////////////////////// #endif // #ifndef SCOPE_GUARD_HPP_INCLUDED ============= Regards, Konstantin Echenko

5 9

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

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