January 2007 - Boost - lists.preview.boost.org

Problem with MPL/GIL dynamic_image example on gcc-4.1.1
by Andreas Pokorny 08 Feb '07

08 Feb '07

Hi, GCC-4.1.1 gives me the attached error message while compiling dynamic_image. It boils down to: dynamic_image.cpp:14: instantiated from here boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:85: error: call of overloaded 'arity_helper( aux::type_wrapper< .... >,aux::arity_tag<1>)' is ambiguous boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:30: note: candidates are: char (&aux::arity_helper(...))[1] boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:37: note: char (&aux::arity_helper(::aux::type_wrapper<F<T1> >,aux::arity_tag<1>))[2] boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:37: note: char (&aux::arity_helper(::aux::type_wrapper<F<T1> >,aux::arity_tag<1>))[2] Is this a known mpl<->gcc-4.1.1 issue? Furthermore there are some odd warnings, and I am not sure what to think about these. The code there looks a bit fishy. I tried the example with gcc-3.4.4, gcc-4.2.0-alpha20060902 and gcc-4.3.0-alpha20061111. It compiled there, but the warning remained in the gcc-4 series. Regards Andreas Pokorny

4 3

Re: [boost] [Review] Review of the Accumulators library begins today Jan 29
by james.jones＠firstinvestors.com 08 Feb '07

08 Feb '07

From: Matthias Troyer <troyer(a)phys.ethz.ch> > These were easy, trickier are robust estimators of variance and > moments, even trickier will be median estimators where I currently > even do not see how this should be done without storing most of the > time series. Isn't this already a problem with sequences? Suppose you're storing the current median, and a new value comes along. What's the new median - without checking all the previous values? There are statistical estimates for this, but I don't know any exact way other than essentially resorting the data and checking the new median. - James Jones Administrative Data Mgmt. Webmaster 375 Raritan Center Pkwy, Suite A Data Architect Edison, NJ 08837

8 15

[Review] Review of the Accumulators library begins today, Jan 29
by John Phillips 08 Feb '07

08 Feb '07

The formal review of the Boost.Accumulators library, submitted by Eric Neibler begins today and ends on Wednesday, February 7. The library is available from http://boost-consulting.com/vault/index.php?directory=Math%20-%20Numerics From the documentation: Boost.Accumulators is both a library for incremental statistical computation as well as an extensible framework for incremental calculation in general. The library deals primarily with the concept of an accumulator, which is a primitive computational entity that accepts data one sample at a time and maintains some internal state. These accumulators may offload some of their computations on other accumulators, on which they depend. Accumulators are grouped within an accumulator set. Boost.Accumulators resolves the inter-dependencies between accumulators in a set and ensures that accumulators are processed in the proper order. Your comments may be brief or lengthy. If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might want to answer in your review: • What is your evaluation of the design? • What is your evaluation of the implementation? • What is your evaluation of the documentation? • What is your evaluation of the potential usefulness of the library? • Did you try to use the library? With what compiler? Did you have any problems? • How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? • Are you knowledgeable about the problem domain? And finally, every review should answer this question: • 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. All interested parties are encouraged to submit a review. These can be sent to the developer list, the user list, or if you don't want to share your review with the general public it can be sent directly to me. Thanks to all for the work you will do on this review. John Phillips Review Manager

8 16

asio failures on Borland compiler
by AlisdairM 08 Feb '07

08 Feb '07

I am only set up for testing with Borland compilers at the moment, and the test results aren't visible at the moment, but ... I am looking into two test cases, buffer.cpp and buffer_select.cpp. Both fail for the same reason - an attempt to instantiate array< const char, 1024 >. That looks like a genuine error to me, array does not support const PODs, instead you must declare a const array. However, I have not tracked down the source of this instantiation yet, so it might be a bad type deduction by the compiler as well. Any hints on where to look more closely appreciated. -- AlisdairM

2 5

Re: [boost] [FSM] Review library version update
by Steven Watanabe 05 Feb '07

05 Feb '07

AMDG Andrey Semashev wrote: > Hello, > > I've updated the Boost.FSM library in the Vault with the following > changes: > - Several threading issues pointed out by Steven Watanabe were fixed. > - Some minor optimizations added to reduce the amount of generated > code and possibly speed up compilation a little. > - Exception classes are now exposed with default visibility on GCC 4.0 > and later under Linux. I'm not sure if other compilers/platforms > need this and have support for similar feature. > - A new example "BitMachine" added. It is quite similar to same-named > example of Boost.Statechart and may be used as a performance test. > - The Performance section of the docs updated with some test results. First of all I think that the elapsed time is more useful than the number of iterations per second. I know that one is just the inverse of the other but the elapsed time has a linear correlation to the amount of work being done. Second, ~half the time taken for the benchmark is the overhead of the test itself rather than the actual state machine. Try this version. #include <boost/mpl/for_each.hpp> #include <boost/mpl/range_c.hpp> //! Function Object version for MPL for_each struct invoke_sm_func { typedef void result_type; invoke_sm_func(BitFSM_t& bfsm) : fsm(&bfsm) { } template<class Index> void operator()(Index) { invoke_sm<Index::value>(*fsm); } BitFSM_t* fsm; }; //! Performance test implementation void run_performance_test(BitFSM_t& fsm) { //... // Execute performance loop for (register unsigned long i = 0, end = (unsigned long)(NO_OF_PERFORMANCE_EVENTS / NO_OF_BITS); i < end; ++i) { boost::mpl::for_each<boost::mpl::range_c<int, 0, NO_OF_BITS> >(invoke_sm_func(fsm)); } //handle the remainder typedef boost::mpl::range_c<int, 0, (NO_OF_PERFORMANCE_EVENTS % NO_OF_BITS)> tail; boost::mpl::for_each<tail>(invoke_sm_func(fsm)); //... } Instead of using MPL vector/list you can create your own MPL sequence. struct StatesList_t { struct tag {}; template<unsigned int N> struct iterator { typedef BitState<N> type; typedef iterator<N + 1> next; }; typedef iterator<0> begin; typedef iterator<(1 << NO_OF_BITS)> end; }; enum { NO_OF_STATES = (1 << NO_OF_BITS) }; In this case trying to reuse code actually generates more work both for yourself and for the compiler. In Christ, Steven Watanabe

4 35

numeric_limits<Abstract> or how to fix 1358600?
by Alexander Nasonov 05 Feb '07

05 Feb '07

I commited the fix for 1358600 - lexical_cast & pure virtual functions & VC 8 STL (http://tinyurl.com/yvowz6) for VC++ only but later I found that Intel 8.1 and Comeau online don't compile as well. The problem appears in numeric_limits functions. In this usecase, they return an abstract class by value. Although lexical_cast never uses those functions, it seems that some compilers do more strick checking than I thought they should. For example, class A { public: virtual void foo() = 0; }; template<class T> struct limits { static int const value = true; static T declared_only(); }; int main() { limits<A>::value; } fails to compile on VC++ 8, Intel 8.1 and Comeau online at the point of the declared_only declaration. However, if I replace a body of A with a declaration (class A;), those compilers don't complain anymore. What is this, a compiler bug or my misunderstanding? I remember that some freedom compiling template code is allowed (and therefore, some compiler compiles while some others don't) but I don't know where to search in the standard. -- Alexander Nasonov http://nasonov.blogspot.com The wise man does at once what the fool does finally. -- Baltasar Gracian -- This quote is generated by: /usr/pkg/bin/curl -L http://tinyurl.com/veusy \ | sed -e 's/^document\.write(.//' -e 's/.);$/ --/' \ -e 's/<[^>]*>//g' -e 's/^More quotes from //' \ | fmt | tee ~/.signature-quote

5 14

boost::pool is there something like alloc(size_t size)
by Dmitry Ivankov 05 Feb '07

05 Feb '07

Can I use boost::pool to allocate arrays of different sizes? In particular char arrays.

3 2

Request for interest in new library : Bit Logic
by Art Stamness 03 Feb '07

03 Feb '07

I have been working on a library that is used for low level bit manipulation of integral types, and modeling of n-bit length types. I have written it as a template library, for inclusion with the Boost library ( hopefully). This is my public request for interest to see if anyone would be interested in such a library. This code runs under Visual Studio and g++ ( linux, and Mac ) . I have posted a web page with documentation ( still a work in progress ), of most all the functionality in the library. There is also a tar ball there, that has been tested with Boost 1.33.1 . Documentation and source tar-ball can be found here : http://www.emulogic.com/bit_logic Any feedback, positive, negative, suggestions is always appreciated. Also if there is a better suggestion for a name, I am open to it. I realize the Boost.Logic library has a very different purpose than this one, and don't want them to be confused. -Art

5 7

[timer]Behavior under MS Windows and documentation
by Yuriy Koblents-Mishke 02 Feb '07

02 Feb '07

Dear Mr. Dawes: First of all, I would like to thank you for the small, but very convenient class. I used it for timing my CPU-intensive codes. However, while using it on Windows machines, I encountered a problem not reflected in documentation: == Summary: == Boost Timer measures a conceptually different timing under Windows than under other operation systems. It is proposed to describe the difference in documentation. For modern versions of Windows the problem can be fixed easily, but with Windows 95/98/ME it is not so. == Description == Under most of operation systems, Boost Timer measures the CPU time consumed by a program. The timing does not include CPU cycles used by other programs running on the same computer, nor the time when the program is waiting for I/O. Under Windows, Boost Timer measures instead the whole wall-clock time elapsed. If other resource-hogging programs like Norton Antivirus, Norton Speed Disk defragmentor, or Skype are running simultaneously with a timed program, the timer will reflect it. If you are timing five copies of the same CPU-bound program, Boost Timer reports that the program became five times slower. If the timed program is waiting for an user input, the timer reports how long coffee break the user took. All of this makes Boost Timer, well, not very suitable for timing of CPU bound codes running under Windows. Even for a rough timing. == The reason == The underlying problem is in std::clock(). Under Windows, the function does not measure the amount of CPU time used by a process. It measures instead the "wall clock" time elapsed since the program started: http://msdn2.microsoft.com/en-us/library/4e2ess30(VS.80).aspx see also discussion here: http://www.cygwin.com/ml/cygwin/2004-07/msg00164.html http://www.cygwin.com/ml/cygwin/2004-07/msg00175.html The Microsoft documentation shows that it is true for all current and recent desktop versions of Windows, starting from year 1995. To my recollection, it was true for MS DOS as well. Hardly an ANSI behavior, but it is so. == Possible solutions == 1. Taking in account how many computers are running Windows, I would suggest to describe the difference in Boost Timer documentation. Currently the documentation discusses a relatively minor problem with low resolution of Boost Timer under Windows, but does not mention the much bigger issue. 2. It is more debatable is if it makes sense to fix the class. 2.1. Boost Timer was around for so many years already, that it probably makes sense to retain its old behavior for compatibility - like Microsoft did with clock() for compatibility with DOS. Personally, I would implement the fixes as a separate class cpu_timer. 2.2. As it was discussed in the Rationale section of documentation, different versions of Windows would require different fixes: On all modern desktop and server versions of MS Windows, starting from NT ver. 3.51 and including all versions of Windows 2000, Windows XP, Windows Server 2003, and Windows Vista the right behavior can be implemented using function GetThreadTimes described in Microsoft documentation: http://msdn2.microsoft.com/en-us/library/ms683237.aspx Windows CE, strating from versions 3.0 or even 2.12, also supports this function, but vendors can remove it from vendor-specific builds: http://msdn2.microsoft.com/en-us/library/ms908464.aspx For Intel Pentium 4 processors running in hyper-threading mode the solution will give distorted result, but it is probably unavoidable. See an useful discussion on the Microsoft forum: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=990282&SiteID=1 The solution is completely incompatible with Windows 95 / 98 / ME, because the OS do not support the GetThreadTimes function. Is there is still a need to support these quaint versions of Windows in the year 2007? == Additional question == You mentioned in the documentation a rejected Win32 implementation submitted by John Maddock. Where can I find it? I would like to compare it to my timing codes for Windows. Sincerely, Yura

2 3

[graph] leda_graph.hpp
by Jens Müller 01 Feb '07

01 Feb '07

Hi all, I looked at the leda_graph.hpp and made the following changes: * property map interface to the LEDA edge_array class nearly 1:1 copy of node_array stuff * adapter for non-templated 'graph' class added nearly 1:1 copy of code for GRAPH<vtype,etype> * fixed access functions (outside iterator code) to use member functions of the graph/GRAPH class see http://www.algorithmic-solutions.info/leda_manual/graph.html * replaced leda_something by leda::something (node, edge) * make iterators use 'public' LEDA interfaces see http://www.algorithmic-solutions.info/leda_manual/graph.html * implemented clear_vertex * implemented EdgeListGraph concept * edge_iterator class * edges function Still have to test them, though, and clarify copyright stuff with my boss. I have one question about leda_graph_id_map: Is the id() member function for nodes (and edges) officially defined somewhere? Jens

2 5