- Boost - lists.boost.org

Re: Boost Digest, Vol 801, Issue 2
by Michael Stevens 27 Jul '04

27 Jul '04

On Tuesday 27 July 2004 12:18, "Victor A. Wagner Jr." <vawjr(a)rudbek.com> > >Maybe the problem is related to namespace handling in VC 8.0 > > > >Boost.numeric.interval library fails when included in uBLAS due to a curious > >namespace problem. > >http://www.meta-comm.com/engineering/boost-regression/developer/output/Rudb… > > > >The same problem effect VC 7.1 as well. Why the compilers think the 'lower' > >'upper' symbols are ambiguous I have no idea! > > because there are two different ones to choose from > Did I miss the :-) here? If only things were so simple. The error occurs in interval/io.hpp. Here a templated operator definition is being defined in the boost::numeric namespace. The definitions of lower/upper we are looking for are in this same boost::numeric namespace. The definitions which VC is getting confused with in the boost::numeric::ublas namespace can only be found by argument dependant (Konig) lookup. We could look this up in the ISO standard. Circumstantial evidence from several other compilers suggests VC 7.1 / 8.0beta is doing the wrong thing here. Which is why I suspect these compilers do not implement namespace perfectly. Michael

1 0

Unit test could usefully output more significant digits to log files?
by Paul A Bristow 27 Jul '04

27 Jul '04

In setting up a test for math function accuracy, I incorrectly coded thus: BOOST_CHECK_EQUAL(sin(0.5), 0.479426); and got the somewhat puzzling - apparently wrong - message error in "call_test_main": test sin(0.5) == 0.479426 failed [0.479426 != 0.479426] On most days of the week, one would expect [0.479426 == 0.479426]! I should of course have written BOOST_CHECK_EQUAL(sin(0.5), 0.47942553860420301); (or used BOOST_CHECK_CLOSE(sin(0.5), 0.47942553860420301, 1e-16);) But I wonder if the test program would be even more helpful if it output all possibly significant digits. In test_tools.hpp, I have added an increase to the ostream precision (default only 6 digits) int print_log_value thus template<typename T> struct print_log_value { void operator()( std::ostream& ostr, T const& t ) { if(std::numeric_limits<T>::is_specialized && std::numeric_limits<T>::radix == 2) { // Show all possibly significant digits (for example, 17 for 64-bit double). ostr.precision(2 + std::numeric_limits<T>::digits * 301/1000); } ostr << t; // by default print the value. } }; so that the message is no longer test sin(0.5) == 0.479426 failed [0.47942553860420301 != 0.47942600000000002] and my folly obvious. And after the original mistake is corrected BOOST_CHECK_EQUAL(sin(0.5), 0.47942553860420301); The log file reports: info: sin(0.5) == 0.47942553860420301 passed. Paul PS (It does not appear to possible to change the precision 'externally' by calling cout.precision(17); myTestLog.precision(17); probably because ostr in test is contructed with default precision). Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow(a)hetp.u-net.com

3 4

FW: pool cleanup
by Aviad Rozenhek 27 Jul '04

27 Jul '04

I am using the object_pool interface, Calling on the object_pool::free () function. On more scrutiny it came down to this: I am not freeing the objects in reverse order of their creation. When I explicitly change the design to make it so, The pool works fine. It also works fine when I wait for the ~object_pool () To clean it up. So these problems remain: 1. when deallocating objects only once in the running of the program (on ~object_pool) and avoiding the cleanup problem stating earlier the pool classes still actually cause a minor downgrade of peformance rather than boosting it. This is the case both in ms-windows port (using Doug Lee's malloc to circumvent microsoft terrible malloc) And on linux port. 2. when not deallocating objects in the reverse order The penalty is overwhelming. For isntance when I turn off all pooling In my application the cleanup make take 3 seconds. Turning on pooling causes cleanup to take an excess of 10 mins ( I give up after that) Possible causes: 1. its not thrashing, because I tested it on a large memory machine. 2. perhaps it's the simple_segragated_storage::find_prev function Because its run time is linear with the size of the chunk. ------------------------------ Message: 5 Date: Thu, 22 Jul 2004 23:48:53 -0700 From: Mark Deric <laguna(a)laguna1.com> Subject: Re: [boost] performance: pool cleanup takes too long To: boost(a)lists.boost.org Message-ID: <20040722234853.09879c08.laguna(a)laguna1.com> Content-Type: text/plain; charset=US-ASCII On Wed, 21 Jul 2004 17:59:40 +0200 "AviadR" <aviadr(a)pob.huji.ac.il> wrote: > the cleanup part (which consists only of calling the pool release > methods on allocated objects) > on the other hand, takes many minutes (I usually give up after 5 > minutes) Are you freeing each on the allocated chunks using pool.free(), or pool.release()? They would need simple_segregated_storage.nextof() Or are you calling ~pool()? The call to ~pool() doesn't use nextof() and should be pretty quick.

1 0

[License] Request for volunteers: converting to the Boost Software License
by Doug Gregor 27 Jul '04

27 Jul '04

The bcp tool is now capable of automatically converting files over to the Boost Software License. However, we need volunteers to verify that the transformation is correct. I have (locally) converted 1256 files that need to be verified, and am asking for volunteers to verify chunks of 100 files each (it won't take all that long...). If you would like to help, please send me e-mail _privately_ and I'll assign a chunk to you. Please tell me which file numbers in the chunk are fine (so I can commit them) and which file numbers are incorrect. To verify a particular file, go to: http://www.boost.org/all-report.html#bsl-converted (It's an 8MB file; you've been warned). Then locate your file numbers (e.g., 1-100) and look at the "before" (left) and "after" (right) chunks of the file. The changed parts are highlighted in bold. Two things need to be verified for a file to be correct (everything else is automatic and correct already): 1) The entirety of the original license must have been removed. 2) Copyrights, author names, etc. have not been destroyed by the transformation. For instance, look at file #1 (boost/assert.hpp): the old license (on the left) has been completely highlighted and replaced by the Boost Software License (on the right), so this transformation is fine. On the other hand, look at file #66 (boost/lambda/detail/bind_functions.hpp): the old license has a clause "This software is provided 'as is'..." that has not been highlighted on the left, and was retained by the transformation. That's a problem: this transformation is not correct. When sending back replies once you've finished a chunk, try to use this form if you could: Correct: 1-10 15-55 Incorrect: 11-14 56-70 We'll need to iterate the process a bit (as we fix up the heuristics to get everything right), but with a little work from everyone I'm sure we can get much of Boost converted over to the BSL in a relatively short time. Doug

2 3

Problems compiling program_options on vacpp
by Matthias Troyer 27 Jul '04

27 Jul '04

Dear Boosters, I have encountered the following problem compiling program_options on the IBM Visual Age compiler 6.0. There seems to be a problem with exception declarations: xlC -DHAVE_CONFIG_H -I../../src -I../../src -DNDEBUG -I/users/matroyer/boost -DNDEBUG -q32 -qlanglvl=extended -O2 -c -M /users/matroyer/boost/libs/program_options/src/convert.cpp -o convert.o "/users/matroyer/boost/boost/program_options/detail/ utf8_codecvt_facet.hpp", line 144.17: 1540-1163 (S) The exception-specification for "int boost::program_options::detail::utf8_codecvt_facet_wchar_t:: do_length(mbstate_t &, const char *, const char *, std::size_t) const" is less restrictive than the exception-specification for "int std::codecvt<wchar_t,char,char *>::do_length(_St &, const _To *, const _To *, size_t) const throw()". Can the throw() declaration be added to do_length()? Matthias

2 3

ANN: Synopsis 0.7 - a source code inspection tool
by Stefan Seefeld 26 Jul '04

26 Jul '04

Synopsis 0.7 released ===================== I'm happy to announce the release of Synopsis 0.7. This is a major feature enhancement and bug fix release. Among the more important new features: * refactored Cpp processor (now a stand-alone processor) * new C processor * feature enhancements and bug fixes in the C++ processor * cleanup and bug fixes in the HTML formatter (now generates valid XHTML) * new SXR cross referencer (see http://synopsis.fresco.org/sxr/files/ for an example) * new C++ API for easier C++ backend programming * Synopsis has been ported to (native) windows An ongoing efford is to produce correct (and useful) documentation for the boost libraries (http://boost.org) You may have a look at the current status of this efford at http://synopsis.fresco.org/boost, containing a reference manual for boost::python (this site is quite large !). For information, see http://synopsis.fresco.org For (developer) documentation, see http://synopsis.fresco.org/docs.html To contact the developers, see http://synopsis.fresco.org/mailinglists.html To report bugs, see http://synopsis.fresco.org/issues/bug About Synopsis ============== Synopsis is a source code inspection framework supporting a variety of languages (right now C++, C, IDL, and Python). Its main focus is source code documentation, but effords are being made to support other forms of introspection such as code generation. Synopsis provides a framework of processors that can (via a simple and straight-forward scripting interface) be used to construct sophisticated pipelines to process abstract syntax trees (ASTs). Regards, Stefan

3 3

[multi_index] mbergal tests
by JOAQUIN LOPEZ MU?Z 26 Jul '04

26 Jul '04

mbergal tests (see http://www.meta-comm.com/engineering/boost-regression/developer/multi_index…) fail for multi_index, but the error messages are not any helpful: a couple of warnings followed by Failure while executing 'cl' compiler ...email Comeau for advice. Any clue about what to about this? Thank you. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

RE: [boost] Mini-reviews
by Reece Dunn 26 Jul '04

26 Jul '04

Tom Brinkman wrote: >Mini-reviews would be very useful. Im shur that each >boost developer/user could contribute a few small, >useful algorithms. It would be a great way to >increase the level of participation by developers who >want to contribute but dont have the time to write a >complete library. I agree. What about small/simple classes, e.g. an object_counter class that keept track of the number of instances of all objects derived from it? This would also make it easier to extend existing libraries like mpl and filesystem (directory iterator). Is there a streamlined system for restructuring a library or changing its interface, e.g. Boost.Random and Boost.Iterator? >We should also discuss to where to place the >algorithms /code within the boost namespace. This would depend upon the type of functions. I can think of the reciprocal trigonometric functions: sec x = 1 / cos x csc x = 1 / sin x cot x = 1 / tan x = cos x / sin x These would best reside in boost::math. Others would fit in different places. I suggest that any mathematics-related algorithms be placed in boost::math, string manipulation algorithms boost::algorithm::string and the others in boost::algorithm. General classes would go in the boost namespace. If the algorithm/class is an extension of an existing library, that should reside in the library's namespace. If the developer wants the algorithm(s)/class to go into a different namespace, a rational should be given. >I could create a document that lists all the >algorithms under consideration with a small summary. >The boost members could than accept/reject each >algorithm and offer suggestions. It would also be worth considering where the algorithms/classes should reside (w.r.t. the files section and the boost-sandbox). It would also be useful to post the algorithms/classes and their descriptions in the review e-mail to facilitate discussion with a link to the code. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

1 0

[config] seems like VC 8.0 needs BOOST_NO_MEMBER_TEMPLATE_FRIENDS
by JOAQUIN LOPEZ MU?Z 26 Jul '04

26 Jul '04

Tests at RudbekAssociates for multi_index in VC 8.0 show this recurrent error: error C2888: 'void boost::multi_index::safe_mode::detach_equivalent_iterators(Iterator &)' : symbol cannot be defined within namespace 'detail' The code causing the problem has the following form: ***********BEGIN CODE*********** namespace boost{ namespace multi_index{ namespace safe_mode{ template<typename Iterator> inline void detach_equivalent_iterators(Iterator& it) { ... } }// namespace boost::multi_index::safe_mode namespace detail{ class safe_iterator_base { ... template<typename Iterator> friend void safe_mode::detach_equivalent_iterators(Iterator&); }; } // namespace boost::multi_index::detail } // namespace boost::multi_index } // namespace boost ***********END CODE*********** which AFACIS seems to indicate that VC 8.0 does *not* support member template friends (VC 7.1 didn't support them either) and thus BOOST_NO_MEMBER_TEMPLATE_FRIENDS should be defined for it (it isn't). I've searched through the VC 2005 beta docs and, allegedly, member template friends are supported, so this particular problem could be a bug rather than complete lack of support for this feature. Maybe someone with local access to VC 8.0 can test the above code and see what happens (I currently don't have the time and resources to try myself.) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: DLL library (Was: [boost] Re: additional boost libraries?)
by Reece Dunn 26 Jul '04

26 Jul '04

Vladimir Prus wrote: >Hi Mattias, > > On Fri, 23 Jul 2004 13:49:22 +0400, Vladimir Prus <ghost(a)cs.msu.su> >wrote: > > > static imported_function<void()> apiFunc( "ApiFunc", "OSLib" ); > > > > Couldn't find a nice point in the thread at which to insert this > > comment, so I'll just spit it out: Since we have both the name of the > > function and the function type, and given that a lib such as this > > should provide a platform-independent interface, would it be useful if > > the library automatically mangled the name according to the type? > >I think you've missed something ;-) Even my initial reply inthe "additional >boost libraries" thread mentioned the possibility of calling functions >which >are not "extern "C". At least two other persons seems to want this. I find >this would be nice, though not critical at all. Would it be possible to have a mangle function, then you could do something like: static imported_function<void()> apiFunc( mangle::mwcw( "ApiFunc" ), "OSLib" ); This would mean that imported_function need only know how to get the function (e.g. using GetProcAddress in Win32) and not worry about the name mangling scheme used. The name mangling could then be handled by a mangler/demangler library that would be useful in diagnostics, e.g.: template< typename T > inline void print_type( const T & t ) { std::cout << demangle::gcc3( typeid(t).name()); } Also, wouldn't it be better to have import as a function of shared_library, so you could do something like: boost::shared_library mylib( "user32.dll" ) typedef ... msgboxA_fn; msgboxA_fn mbA = mylib.import< msgboxA_fn >( "MessageBoxA" ); msgboxW_fn mbW = mylib.import< msgboxW_fn >( "MessageBoxW" ); With the possible Win32 implementation of, but using boost::function: namespace boost { class shared_library { private: HANDLE hDLL; public: template< typename Function > inline Function * import( const char * fn ) { if( hDLL == 0 ) return( 0 ); return( reinterpret_cast< Function * >( ::GetProcAddress( hDLL, fn ))); } public: inline shared_library( const char * fn ): hDLL( ::LoadLibrary( fn )) { } inline ~shared_library() { if( hDLL ) { ::FreeLibrary( hDLL ); hDLL = 0; } } }; } Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

3 2