- Boost - lists.boost.org

Math constants - update & files removed
by Paul A Bristow 01 Mar '04

01 Mar '04

As requested by Beman, I have purged all my math constants proposals, except the latest version, from the files section. I have also updated the copyright notices on the macro (36 decimal digit) constants values, and posted these zipped. Until we can agree a better method of presenting math constants, these may save users surfing the net for individual values. (Since some people seem to find the files section inaccessible, should they be copied to the CVS sandbox too?) Since the two files (to #define and #undef) are quite short, they are also attached for your convenience. Please tell me of any mistakes you find. Paul PS If anyone has any suggestions on solving the presentation problem please say so. Daniel Frey seems close to a portable solution, but "a miss is a good as a mile" :-( Type deduction seems the nub of the problem: can anything from FC++ help? Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow(a)hetp.u-net.com

4 4

algorithms namespace
by Pavol Droba 01 Mar '04

01 Mar '04

Hi, During the review of the string algorithm library, an issue was raised about the namespaces for algorithmic libraries in the boost. The issue has not been sufficiently resolved, and I would like to bring it up to the discussion again. Current proposal looks like this: boost - algorithm - common algorithm related stuff - string - string algorithms - container - container algorithm etc. Although this seems clear enough, there are some open questions. 1.) Namespace path is quite long. It is not really reasonable to await from a user to always type boost::algorithm::string::trim. "using namespace" directive is not always a viable solution. And even if it would be, a user would have to specify several of them to use whole algorithm library (what could not so uncommon, in my opinion) Namespace aliasing is one of possible solutions, but again, one would have to alias every algorithm sub namespace. 2.) It is not clear if what should go into boost::algorithm namespace and what to more specific ones (like boost::algorithm::string). This is specificaly an issue of algorithms, that logicaly belong to various categories. An example would be "all" algorithm. It is generic enough to not be contained in the string library. But on the other hand, together with classification predicate, it is essencial for the string processing. Should it go to algorithm::string, algorithm::container, plain algorithm or somewhere else? Suggestions: 1.) One possibility would be to relieve the idea of algorithm subnamespace and put everything into boost::algorithm namespace. Benefit would be simplier namespace specification and less suprises about where is a particular algorithm. Disadvantage can be a possibility of nameclashes and poluted namespace. 2.) Another option would be to use subnamespaces, but to propagate user-level interface names to boost::algorithm using "using" directive. In this alternative, there is still an open question (2). (i.e. to define more precisely the policy for putting algorithms/classes into namespaces) 3.) Let everything in subnamespaces and identifying the problem(1) as irelevant. 4.) Some other idea, I don't know yet about. Your ideas/optinions are welcome. Regards, Pavol

17 41

shared_ptr: policy for usage_count lock
by Slawomir Lisznianski 01 Mar '04

01 Mar '04

I apologize if my observation has already been discussed and course agreed. When using Boost with multi-threaded programs, shared_ptr synchronizes access to internal usage count variable. I understand the rationale for guarding the shared resource as default behavior in MT environment, however I think users might appreciate the ability to override it. Currently, users either ignore, or are unaware of, performance cost imposed by locking, or choose, with all it's implications, an option of using non-owning observer of an object owned by shared_ptr. During tests involving manipulations of shared_ptr variables similar to those performed by algorithms on container elements – their copying and removal – a significant overhead was measured. During tests, care was taken to assure that timing did not include creation of new objects managed by shared_ptrs nor their destruction. One way to customize the shared_ptr without breaking existing code would be to introduce an optional template parameter stating locking policy. Attached you will find test code used on a win32 platform that produced the following results on Intel Pentium 4 2.66Mhz single processor machine. Each line represents separate testing iteration, so averages can be calculated: BOOST_HAS_THREADS is: TRUE Elapsed time: 845605 microseconds Elapsed time: 817763 microseconds Elapsed time: 802840 microseconds Elapsed time: 790676 microseconds Elapsed time: 790839 microseconds Elapsed time: 793012 microseconds Elapsed time: 790474 microseconds Elapsed time: 788396 microseconds Elapsed time: 794611 microseconds Elapsed time: 792640 microseconds Press any key BOOST_HAS_THREADS is: FALSE Elapsed time: 87914 microseconds Elapsed time: 87753 microseconds Elapsed time: 88958 microseconds Elapsed time: 86546 microseconds Elapsed time: 86437 microseconds Elapsed time: 86520 microseconds Elapsed time: 86433 microseconds Elapsed time: 88519 microseconds Elapsed time: 86420 microseconds Elapsed time: 87535 microseconds Press any key The time overhead mentioned above is meant to serve as an example from a particular win32 platform. Results will vary across platforms and hardware configurations. Regards, Slawomir Lisznianski; [ www.rhapsodia.org ] /* * Copyright (C) 2003-2004 * Slawomir Lisznianski <slisznianski(a)asyncnet.com> * * Permission to use, copy, modify, distribute and sell this software * and its documentation for any purpose is hereby granted without fee, * provided that the above copyright notice appear in all copies and * that both that copyright notice and this permission notice appear * in supporting documentation. Slawomir Lisznianski makes no * representations about the suitability of this software for any * purpose. It is provided "as is" without express or implied warranty. * */ #include <string> #include <iostream> #include <stdexcept> #include <boost/shared_ptr.hpp> #include <Windows.h> // VC++ 6 library doesn't define it. // std::ostream& operator<<(std::ostream& os, __int64 i ) { char buf[20]; sprintf(buf,"%I64d", i ); os << buf; return os; } struct Timer { Timer(std::ostream& out) : _M_out(out) { if (!::QueryPerformanceFrequency(&_M_frequency)) throw std::runtime_error("Unable to retrieve frequency of the high-resolution performance counter."); if (!::QueryPerformanceCounter(&_M_startEvent)) throw std::runtime_error("Unable to retrieve value of the high-resolution performance counter."); } ~Timer() { if (!::QueryPerformanceCounter(&_M_endEvent)) _M_out << "Unable to retrieve value of the high-resolution performance counter."; else { LONGLONG elapsedTicks__ = _M_endEvent.QuadPart - _M_startEvent.QuadPart; double elapsedTime__ = 0; _M_out << "Elapsed time: "; if (_M_frequency.QuadPart > 1000000) { elapsedTime__ = (elapsedTicks__ / (_M_frequency.QuadPart / 1000000)); _M_out << elapsedTime__ << " microseconds" << std::endl; } else if (_M_frequency.QuadPart > 1000) { elapsedTime__ = (elapsedTicks__ / (_M_frequency.QuadPart / 1000)); _M_out << elapsedTime__ << " miliseconds" << std::endl; } else { _M_out << elapsedTicks__ << " ticks (tick: 1/" << _M_frequency.QuadPart << " of second)" << std::endl; } } } std::ostream& _M_out; LARGE_INTEGER _M_startEvent; LARGE_INTEGER _M_endEvent; LARGE_INTEGER _M_frequency; }; void run() { boost::shared_ptr<int> ptrA__(new int(0)), ptrB__, ptrC__; Timer timer__(std::cout); for (int i=0; i<4000000; ++i) { ptrB__ = ptrA__; ptrC__ = ptrB__; } } int main(int, char**) { try{ std::cout << "BOOST_HAS_THREADS is: "; #if !defined(BOOST_HAS_THREADS) std::cout << "FALSE" << std::endl; #else std::cout << "TRUE" << std::endl; #endif for (int i=0; i<10; ++i) run(); } catch (std::exception& e) { std::cerr << e.what() << std::endl; } return 0; }

4 4

smart_ptr: missing documentation link
by Slawomir Lisznianski 01 Mar '04

01 Mar '04

Browser: Mozilla 1.6 When trying to access documentation for smart_ptr I'm getting: Not Found The requested URL /libs/smart_ptr/index.htm was not found on this server. Apache/1.3.26 Server at www.boost.org Port 80 The link came from (referring page): http://www.boost.org/libs/libraries.htm Target page: http://www.boost.org/libs/smart_ptr/index.htm Note: Problem occurs on IE as well, but after a very brief moment, browser redirects to http://www.boost.org/libs/smart_ptr/smart_ptr.htm where page is found. Regards, Slawomir Lisznianski; [ www.rhapsodia.org ]

2 1

mistake in "libs/libraries.htm"
by Li Lirong 01 Mar '04

01 Mar '04

"quaterion" should be "quaternion". Regards, Lirong

2 1

shared_array: how to get the number of elements in it?
by Roland Richter 01 Mar '04

01 Mar '04

Boosters, I want to write a function which compares two shared_array's element-wise (operator==() compares for pointer equality). How to get the number of elements a given shared_array contains? At first glance there seems to be no possibility; am I missing something? - Roland

2 1

RE: [boost] Re: algorithms namespace
by Powell, Gary 01 Mar '04

01 Mar '04

I'm siding with Dave A and the longer names. You can always shorten it in your code with an alias. For me it's a matter of future expansion, and maintenance, we have boost::bind, and boost::lambda::bind, and perhaps soon boost:fcpp::lambda which is the namespace which the function? If we use apprev. 4 everythg, thn, we lose contx. boost::fs =? "FileSystem", "FastSort", "FirstSearch", "FloatingSymbols".... yes these are a bit contrived but you can usually use "using namespace", or a namespace alias safely within a function scope. Then when you leave the company the next poor maintainer of your code has a chance. Also a global search is easier if the letters to be searched for are more or less a unique set. Yours, -Gary- -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: Monday, February 23, 2004 11:44 AM To: Boost mailing list Subject: Re: [boost] Re: algorithms namespace At 03:28 PM 2/18/2004, Peter Dimov wrote: >> I think it's a fuzzy line in the sand, so all I really know is that I do >> like "ref" and don't like "fs" :) > >Yes, is seems that it comes down to personal preference. Dave likes to say >filesystem, and you don't like fs... I never liked either. "filesystem" is too long and sounds affected. "fs" is too short and non-specific. Those names just escaped because nothing better surfaced. Maybe if the LWG likes the library enough to standardize it we can come up with a better name. --Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

9 15

Solution to Windows' min/max problem?
by Daryle Walker 01 Mar '04

01 Mar '04

I learned some new stuff from another post about the min/max macros given in the Windows headers. Can the following suppositions and solution work? 1. The MS Windows headers define "min" and "max" macros 2. But nothing in those headers _actually needs_ those macros 3. These macros prevent STL from working 4. A "NOMINMAX" #define can be created to turn off the macros 5. Using the #define will fix STL _without_ breaking the MS stuff 6. The #define would break user code that uses the macros, though 7. If an user with that breakage includes STL, they have an alternate "min" and "max" available! 8. Boost pretty much requires STL So why can't we add: #if defined(min) || defined(max) #error Define NOMINMAX and use the alternates in <algorithm> #endif -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

3 2

[config] [patch] Fix support for OpenBSD
by larsbj＠gullik.net 01 Mar '04

01 Mar '04

We just got a mail from a LyX user telling us that this patch is needed to compile on OpenBSD. Would be nice if this could be included in Boost (and in 1.31.1 when that is released.) TIA. --- boost/boost/config/platform/bsd.hpp.orig 2002-05-21 19:39:55.000000000 -0400 +++ boost/boost/config/platform/bsd.hpp 2004-02-22 02:24:05.000000000 -0500 @@ -44,7 +44,9 @@ // // The BSD <ctype.h> has macros only, no functions: // -#define BOOST_NO_CTYPE_FUNCTIONS +#if !defined(__OpenBSD__) +# define BOOST_NO_CTYPE_FUNCTIONS +#endif -- Lgb

2 2

[Boost-bugs] [ boost-Bugs-907299 ] Miss " = ParserT()"
by SourceForge.net 01 Mar '04

01 Mar '04

Bugs item #907299, was opened at 2004-02-29 21:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=907299&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Miss " = ParserT()" Initial Comment: \boost\spirit\core\scanner\skipper.hpp 101 skip_parser_iteration_policy( 102 ParserT const& skip_parser, 103 base_t const& base = base_t()) 104 : base_t(base), subject(skip_parser) {} "no_node_d" can't be used. Fixed: 101 skip_parser_iteration_policy( 102 ParserT const& skip_parser = ParserT(), 103 base_t const& base = base_t()) 104 : base_t(base), subject(skip_parser) {} All right! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=907299&group_i… ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0