- Boost - lists.boost.org

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