October 2004 - Boost - lists.boost.org

[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