March 2004 - Boost - lists.boost.org

boost::ublas and solver
by Loïc Joly 01 Mar '04

01 Mar '04

Dear boosters, I was recently trying to convince one of my colleagues that a vector (mathematical, not stl) and matrix library instead of raw C arrays could be usefull for his job. I naturally turned toward boost::ublas, but then I had one surprise: One thing I expected to find in such a library was a collection of solvers (LU, gaussian elimination...), but I found none. Is this because they exist, but I could not find them in the documentation (btw, I have some trouble to understand the doc, too much code, not enough english to my taste) ? Is is because there was a good design decision not to include them ? Is it because this is a very touchy domain and poeple could not agree on generic solutions ? Is is just an oversight ? -- Loïc

1 0

RE: [boost] Re: boost::any: explicit constructor?
by Glen Knowles 01 Mar '04

01 Mar '04

>I guess I don't understand the whole concept now. T* -> void* sounds >like "narrowing", since it loses information. int -> long never loses >information, so "widening" makes sense to me. What is the criterion? This is why I like C++'s choice of base and derived, there's never any confusion. You have the concepts of narrowing and widening correct but backwards. You narrow a type to a more specific derived type and widen one to a more general base type. Glen

3 4

Re: The art of naming namespaces [was: Re: algorithms namespace]
by Bjorn.Karlsson＠readsoft.com 01 Mar '04

01 Mar '04

> From: Thorsten Ottosen [mailto:nesotto@cs.auc.dk] > > I'd say that for boost::filesystem, Dave's suggestion > "files" would be a > > great compromise. > > Why plural? We seldom name class in plural. Good question, and I'm not really sure I can answer it very well (but I'll try): * It can be mentally expanded to files...ystem. * Some names work "best" in plural (like signals, type_traits, iterators, operators); this is of course very much IMHO. * Just "file" seems a bit restrictive to me, but when I think about the namespace "files" I read "files 'n other related stuff, too". (Come to think about it, that Boost.Thread uses the singular form is actually quite funny!) As this is a highly subjective matter, I don't consider these arguments/reasons to be anything else than personal opinions. Bjorn

7 16

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