August 2008 - Boost - lists.preview.boost.org

svnmerge woes
by Eric Niebler 08 Aug '08

08 Aug '08

I'm trying to merge from trunk to my private branch (branches/proto/v4) using svnmerge.py, and it's failing with the following error: svn: File 'libs\wave\samples\waveidl\idllexer\idl.re' has inconsistent newlines svn: Inconsistent line ending style Does anybody know how I can work around this? -- Eric Niebler BoostPro Computing http://www.boostpro.com

6 9

FSM Review Reminder
by Martin Vuille 08 Aug '08

08 Aug '08

The formal review for Andrey Semashev's Finite State Machines (FSM) library is scheduled for August 11th to 20th. The documentation (overview and reference) is available online: http://boost-extension.redshoelace.com/docs/boost/fsm/doc/state_machine.html http://boost-extension.redshoelace.com/docs/boost/fsm/doc/reference.html Quoting from the documentation: "The main goals of the library are: * Simplicity. It should be very simple to create state machine using this library. * Performance. The state machine infrastructure should not be very time and memory-consuming in order to be applicable in more use cases. * Extensibility. A developer may want to add more states to the existing state machine, and this addition should be relatively safe since it shouldn't interfere with the existing states. The developer should also be able to specify additional transitions and events for the machine with minimum modifications to the existing code." "Boost.FSM vs. Boost.Statechart There is another library in Boost that provides similar functionality: Boost.Statechart. Although it currently covers almost all major Boost.FSM features and provides ones that are not supported in this library, Boost.Statechart is more targeted to creation of big and complex state machines with possibility of distributed development. But this does not come at no price and Statechart has little tools for compile-time programming and does not provide as much run-time performance as Boost.FSM does. So there are main guidelines for users to make a decision between Boost.FSM and Boost.Statechart: [...]" "The following compilers are known to have problems or most likely will have ones: * Microsoft Visual C++ 6.0 and 7.0. Most probably will fail to compile due to lack of partial template specialization support. * Borland C++ Builder 5.5.1 (free version). Fails to compile due to lack of partial template specialization and in-class using declarations support. Some other minor problems also have been noticed. Newer versions of the compiler have not been tested. * OpenWatcom 1.5. Fails to compile due to problems with Boost.MPL code. Newer versions of the compiler have not been tested. * SunPro C++ Compiler 5.5 for Solaris (SPARC). Most likely will show problems with function overload resolution. Newer versions of the compiler have not been tested." The current submission is available from the sandbox vault at http://tinyurl.com/yjozfn (or http://www.boostpro.com/vault/index.php?action=downloadfile&filename=FSM.zip &directory=&PHPSESSID=48493076c1ea60ae316f7b60f15b9ed1, if you prefer.) MV

3 2

Mini-proposal, simple boost/handle.hpp lib
by Emil Dotchevski 08 Aug '08

08 Aug '08

Does anyone besides me find this code useful: http://codepad.org/zK0iOLp2 It could go in boost/handle.hpp and could be used to manage any type of handle in a shared_ptr, for example one could do: shared_ptr<int> s; { int sockfd = socket(PF_INET,SOCK_STREAM,0); if( sockfd!=-1 ) make_handle(sockfd,close).swap(s); } It would also work with HWND, so you get a shared_ptr<HWND> (even without make_handle you could still use shared_ptr<HWND__> but strictly speaking you'd be exploiting implementation details with that.) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

4 7

Re: [boost] [Math] acosh implementation
by John Maddock 08 Aug '08

08 Aug '08

Hubert Holin wrote: > Paris (U.E.), le 08/08/2008 > > Bonjour > > This not only looks just plain wrong, it *IS* just plain wrong... or > at the very least badly suboptimal. Sorry! To fix it (as it is > correctly in asinh.hpp), one has to add: > > static T const upper_taylor_n_bound = one/ > taylor_n_bound; > > and replace "else if (x >= taylor_n_bound)" by "else if (x >= > upper_taylor_n_bound)" at the line you point out. Hmm, isn't the final else clause for x near 1? So the check would be else if(x - 1 > taylor_n_bound) > The reason this has not been detected by the unit tests is rather > unfortunate: due to a very poor QOI of GCC on 64 bits ppc (my platform > of choice at the time), the unit tests are rather lenient, and only > compare the functions to test with (user platform) library provided > functions, instead of also comparing with hand-computed special > values. Perhaps is it now time to change this? Nod, how about adding some tests along the lines of the newer special functions where we test both random values (with results computed at high precision), and a few specific sanity-check values generated by functions.wolfram.com ? That way we can get a much better handle on the accuracy, and any potential problem area of these older functions. I can try and work up some tests in week or so if that would help, or can you handle this? Cheers, John.

1 0

Boost license now, finally, OSI approved
by David Abrahams 08 Aug '08

08 Aug '08

-- Dave Abrahams BoostPro Computing http://www.boostpro.com

6 6

[BGL] why not breakup put_get_helper into three structs?
by Mostafa 08 Aug '08

08 Aug '08

Hello, I posted this in gmane.comp.lib.boost.user and got no response, so I thought of reposting it here: Link: http://thread.gmane.org/gmane.comp.lib.boost.user/37318 Repost: Helllo, I was wondering why put_get_helper shouldn't be three structs (put_helper, get_helper, put_get_helper, with the latter deriving from from the formers) instead of one? My rationale is outlined below along with the proposed code. //Begin Rationale Problem: want a helper method for readable property maps. Solution1: use exist boost::put_get_helper and just never use the put function. Problem with solution 1: 1) the put function will still be "callable", and 2) calling the put function will result in an invalid assignment to a read-only variable compiler error, which is cryptic to decipher, ie, that even though the put function does exist it should not be called. The only way to clarify this would be via documentation, which then brings about the problem of keeping code in sync with comments. Solution2: make a helper method for readable property maps that won't make the put companion function a valid function call, ie, break up boost::put_get_helper to put_helper, get_helper, and put_get_helper which derives from the latter two. Problems with solution 2: None that I can see. Advantages of solution 2: 1) It's self-documenting whether the put or get functions are intended to be called, ie if I derive from get_helper then it's self-evident that I shouldn't be calling the put function (vice versa); and 2) given the above scenario, even if by chance the put function get's called the compiler error message will be easier to decipher, ie, something along the lines of: <no matching function for call to ‘put(...)'>. 3) Not really an advantage, but ... backward compatibility is maintained. //End Rationale. //Proposed code adapted from boost/property_map.hpp // A helper class for constructing a property map // from a class that implements operator[] template <class RetVal, class RvaluePropertyMap> struct get_helper { }; template <class LvaluePropertyMap> struct put_helper { }; template <class RetVal, class LvaluePropertyMap> struct put_get_helper : public put_helper<LvaluePropertyMap>, public get_helper<RetVal, LvaluePropertyMap> { }; template <class PropertyMap, class RetVal, class K> inline RetVal get( get_helper<RetVal, PropertyMap> const & pa, K const & k) { RetVal v = static_cast<const PropertyMap&>(pa)[k]; return v; } template <class PropertyMap, class K, class V> inline void put( put_helper<PropertyMap> const & pa, K k, V const & v) { static_cast<const PropertyMap&>(pa)[k] = v; } Thanks in advance, -Mostafa

4 7

Library proposal: box
by Chris Jefferson 07 Aug '08

07 Aug '08

I wish to seek interest in generalising, extending and documenting a simple but useful library I use personally. 'box' is a simple class which provides an almost standard C++ container on top of a pre-allocated block of memory or range of iterators. For raw memory this container is a perfect implementation of vector, except for the constructors. It is possible for the underlying objects to be already constructed, or have the container handle construction and destruction. Simple usages: box<int> b1(malloc(sizeof(int) * 10), 10); // makes an empty container of size 10. assert(b1.size() = 0); assert(b1.max_size() == 10); b1.resize(10, 1); // Fills the container with 1s. b1.push_back(1); // throws std::length_error box<int> b2(alloca(sizeof(int) * 10), 10); // makes an empty container on the stack of size 10. void get_things(b2); // passing 'alloca'ed boxes to functions avoid heap allocation. A number of macros exist for automating the creation of containers with 'alloca'ed memory. Further, a simple alternative implementation of alloca which uses a parallel stack is provided. Common use cases: 1) Use 'alloca'ed memory to make a container on the stack. 2) In general allow the use of C++ container idioms (push_back, resize) while maintaining fully controlled, clear memory management. Design decisions: 1) Box has no copy constructor or assignment, and will have no move constructor either, as it seems difficult to give any definition without too many 'gotchas'. 2) Box does not attempt to implement complex memory management, 3) In general box aims to be as simple as possible, sticking with fixed size containers and no container copying. Possible Qs (with I hope correct answers) Q) Why is this not just boost::range? A) The container starts empty, and can be inserted into. Q) Why not implement this as an allocator to give to vector/list? A) Allocators are a complex and often misunderstood type, and it is not felt it makes things easier for users to give a different allocator to vector as opposed to defining a new class. In particular, getting correct behaviour for the copy constructors of the container is difficult, and it is not possible to give a correct definition of max_size, which is more important for small-sized containers. Current state: box is currently in usage in a number of projects, based on a heavily-hacked SGI vector implementation. As a library the code would probably be rewritten, and also of course carefully documented. Chris

4 6

Re: [boost] [1.36][ublas] VC8/SP1 with ADL problem?
by joel falcou 07 Aug '08

07 Aug '08

Le Jeu 7 août 2008 20:33, Thomas Klimpel a écrit : > I'm no expert on ADL, so I have no idea whether VC8 is allowed to fail > here. VC8 seems to fail as soon as I define any template function named > sqrt inside the boost or boost::numeric namespace. I have no idea how to > work around that. Perhaps I should investigate why "#define NDEBUG" works > around the problem. did you try #undef sqrt after including any headers like cmath or windows.h ? I had a similar problem with min/max and log2 for a while.

1 0

Re: [boost] [1.36][ublas] VC8/SP1 with ADL problem?
by joel falcou 07 Aug '08

07 Aug '08

Le Jeu 7 août 2008 20:33, Thomas Klimpel a écrit : > I'm no expert on ADL, so I have no idea whether VC8 is allowed to fail > here. VC8 seems to fail as soon as I define any template function named > sqrt inside the boost or boost::numeric namespace. I have no idea how to > work around that. Perhaps I should investigate why "#define NDEBUG" works > around the problem. did you try #undef sqrt after including any headers like cmath or windows.h ? I had a similar problem with min/max and log2 for a while.

1 0

Re: [boost] out of date release results?
by Eric Niebler 07 Aug '08

07 Aug '08

Beman Dawes wrote: >> Rene Rivera wrote: >>> Eric Niebler wrote: >>>> >>>> Oh whoa. Something really strange is going on with these pages. >>>> >>>> These results are old: >>>> http://www.boost.org/development/tests/release/developer/accumulators_relea… >>>> >>>> These results are new: >>>> http://www.boost.org/development/tests/release/developer/accumulators.html >>>> >>>> I can reach either page via different sequences of clicks. At first >>>> I thought that maybe one page represents results from 1.35, but >>>> that's not possible because accumulators wasn't in 1.35. >>>> >>>> What's going on? >>> >>> This sounds like the release view of the results is not getting >>> generated, on Beman's machine, and it's using some old set of >>> results. Hence only the developer view has the current results. > > No idea. That machine just runs the script from the web site; I haven't > done any customization, and haven't changed either hardware or software > setup in ages. Whatever the problem is, we need to sort this out now. It's not ok to be publishing stale tests results. Rene, thoughts? Can we just nuke the old test results? -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0