February 2004 - Boost - lists.preview.boost.org

Re: win32.hpp and min/max macros
by Eric Niebler 02 Mar '04

02 Mar '04

John Maddock wrote: > Would you like to make and manage the change? Remove the workarounds from > win32.hpp, and then patch all occurrences of min and max throughout boost? > > John. <recap> We agreed to make boost work in the presence of the min/max macros by wrapping all min/max function identifiers in parens, like (std::min)(a,b); </recap> I have spent some time and made the 800 or so edits throughout boost required to make it play nice with the min/max macros. I'm running regressions now. I have a couple of questions about procedure before I can commit the changes. 1) Is this a good time? I know there's talk about a 1.31.1 release. Will this be done from the 1.31.0 branch or from main? I don't want to destabilize before a release. 2) I can't test with old compilers, which are the ones most likely to have a hard time with this change. Also, I'm not a CVS guru. If all hell breaks loose as a result of this change, is there someone willing to help me back it out? 3) Is there a boost developer style guide where we can document the fact that all calls to min/max functions must be wrapped in parens? 4) This is the sort of thing developers will forget to do even if it's in a style guide. A simple way of ensuring this stays fixed would be to run the regressions with min() and max() #defined to garbage, so that violations are detected and corrected early. Is this possible? Thanks. -- Eric Niebler Boost Consulting www.boost-consulting.com

13 37

FC++: formal review
by Gennadiy Rozental 02 Mar '04

02 Mar '04

Hi, It was quite difficult to review this submission for several reasons: mostly because (from POV) it has virtually no documentation, no structure, no testing and what is most important no clear defined problem domain, where this library provide a solution (here I mean not the function objects facilities, but namely FP part of the submission). What it does have, is a several interesting ideas. In summary it my opinion this submission is unacceptable and my vote is NO. Problem domain ------------------------------------------------------------------------- Unlike my usual review I would like to start with problem domain discussion. Library position itself as a library to do FP in C++. Namely in this order. Kind of like library for crazy Haskell programmer that for whatever reason decided to use C++. Docs (and papers) in details describe how to do things one could do in Haskell using FPC++ analogs. There is even comparison of performance with Haskell compilers: not to worry we almost as fast. For me as a C++ programmer more important is to see the comparison with the same algorithm implemented with other usual C++ techniques. I did one myself. I took an example used by authors for performance testing and modified it like this: .... here is what is already in test //////////////////////////////////////////////// inline bool is_prime( int i ) { for( int c = 2; c <= i/2; ++c ) { if( i % c == 0 ) return false; } return true; } inline int nth_prime( int N ) { int i = 1; while( N > 0 ) { i++; if( is_prime( i ) ) N--; } return i; } int main() { acc_timer timer; // acc_timer is my timer class based on gettimeoftheday int NUM; cout << "Num primes = "; cin >> NUM; timer.start(); list<int> l = primes(NUM); int i = at( l, NUM-1 ); timer.stop(); cout << i << endl << "took " << timer.elapsed() << " sec" << endl; timer.start(); i = nth_prime( NUM ); timer.stop(); cout << i << endl << "took " << timer.elapsed() << " sec" << endl; } The algorithm I am using similar to the one use by original code. The only difference is that I am not using FC++ abstraction. I was using gcc 3.3.1 under cygwin on my Athlon 2000+ PC. I was using following command for compilation: g++ -O4 -I [list of include directories] tw_primes.cpp Here is the result of several runs: Num primes = 500 3571 took 4.825 sec 3571 took 0.015 sec Num primes = 750 5693 took 11.703 sec 5693 took 0.036 sec In average FC++ solution is 320 times slower. For any practical usage price of an abstraction should not exceed 10-20%. With price as high as FC++ currently shows I wouldn't even start to think in this direction. In general from my experience usage of lazy evaluation quite limited (in FP sense - I do not mean binding the arguments, which is widespread). It may be used sometimes, but I know many more other neat tricks that are more or as useful. IMO authors need to justify need in lazy list as a generic reusable components in C++ (namely in C++ not for FP which says nothing to me), but for now I do not see a place for them. Some papers does try to justify need for FP to implement common design patters in C++. But actually they only shows need for use of polymorphic functors nothing more. Design ------------------------------------------------------------------------- I with almost everything authors says about need of polymorphic functors and the way they design support for result type deduction. But I believe it should be boost-wide solution. With support in both boost::function, boost::bind and boost::lambda. I don't think we need indirect functoids (with their virtual functions and smart_pointers inside). boost::function should be made result_of aware instead. I couldn't comment on design of lazy lists since it does not described in docs. But I still not convinced that there exist a problem to justify need for this construct. Lambda facilities design is also offsite and it's difficult to comment on it by itself and on comparison with boost::lambda. In my personal opinion there should not be two different facilities dedicated to the same cause within boost. If you have any issues with boost::lambda lets resolve them. In other case it would only source of confusion to the users and make them both less useful. Monads are not covered and not commented accordingly. Explicit built-in currying (I prefer term binding) looks like convenient idea and I would vote to include this info boost::function Implicit built-in currying on the other hand like more like a source of confusion than convenience and in my opinion should not be included. It not only may confuse inexperienced user, but also may cause a conflict If I have function polymorphic not only in regards to the type of the arguments but also in regards to their number. I do not understand need for separate notion of thunks. Why couldn't we just bind all function arguments using usual means? Library supply the collection of predefined function object. While I can blindly accept polymorphic counterparts to the STL functional ones, the rest should be documented and discussed one by one (the fact they belong to mythical "prelude" says nothing to me). Also from sources it looks like many of them operate on lazy lists. Why couldn't we have them as a member functions? They are not generic to be used for different kinds of lists (like STL list) and what is an advantage to length ( ll ) vs. ll.length(). Would I need to pass this method anywhere (rare case IMO) I could use an adaptor. Infix syntax: I do not think this feature useful enough to justify weird syntax. Most probably it wouldn't be use for anything other then several functors like plus, minus. Documentation ------------------------------------------------------------------------- There two major problems I have with docs: first they are very scarce on design of the component described and second they are written for Haskell programmer who is learning C++. I believe that at least 90% of C++ practitioners never heard about Haskell. Accordingly it should not be mention in docs AT ALL. The should not be ANY references to Haskell syntax, which instead of clarifying things make it worse and left me with feeling that I did not get something. There should be a short introduction to what is a functional programming paradigm. Comparison with existent C++ paradigms, advantages and disadvantages. I don't say it should be extensive multipage work, but just an introduction for C++ programmer not familiar with FP. There should be reference documentation for any functor supplied by the library. I am not sure there is a need for old (pre boost) references in docs. It absolutely unnecessary for new users. Why existent users may use some kind of transition guide in FC++ website. The rest of docs looks in most part as a "simple overview", while I expect to see a real full documentation. Implementation ------------------------------------------------------------------------- 0. It would be much easier if you would follow recommended boost directory structure 1. BOOST_FCPP_DEFER_DEFINITIONS This does not look like a good solution. What exactly did you try to achieve? 2. definition.cpp What is this? Does it gets compiled by any compiler? 3. All implementations needs to be rewritten using Boost PP to be extendable to more then 3 arguments. 4. Why fullN does not inherit from it's parameter, but keep it as a member instead? 5 What is konst vs. const? 6. When you will eliminate implicit currying implementation became more simple 7. binderNandK...ofM facility does not look extendable. Did you look how boost::bind is implemented? 8. There are still a lot of identifiers that does not follow recommended boost naming policy 9. Why infix syntax implementation is mixed with some library supplied functors? Testing/Examples ------------------------------------------------------------------------- There is a lot of staff in fcpp_clients directory. Since there is no test/examples separation and no Jamfiles I couldn't comment in details how it looks. Regards, Gennadiy.

7 9

[rational] why is int_type private?
by Jody Hagins 02 Mar '04

02 Mar '04

Converting to/from boost::rational I have occasion to need the underlying integer type. Why is this typedef private, and not accessible to users? I looked through the archives, but can only find a similar question from Jonathan Turkanis, with n reply. Thanks!

3 5

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

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

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

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