- Boost - lists.boost.org

Math functions for statistics - a draft TR2 proposal.
by Paul A Bristow 13 Jul '04

13 Jul '04

As promised recently, I am presenting a draft of proposals for math functions which are needed for even most elementary statistics. I have been encouraged to submit this to both the C and C++ Standard Library groups at the same time. (They seem to speaking more than in the past). These are additions to the list drawn up by Walter Brown accepted into TR-1. The style and format follows his closely even though there were some opposition to them from the C++ community. However I think we have to accept that C and C++ compatibility are valued more than C++ 'ideality', and not try to re-open this area of dissent. The draft has been uploaded to the files area in a new folder Math Functions as "More Mathematical Functions.pdf" 220 kb. I'd be grateful if some CVS whizz would copy it to the sandbox as I know that many are unable to access the fiels section. It would be useful to have comments on 1 Typographical mistakes. 2 Mathematical mistakes (prepared by someone with seriously rusty math!). 3 The choice of functions espcially if there are any your feel strongly are missing, or are not needed (say why). 4 The choice of names. Clarity is preferred to curtness. 5 The choice of names for derivatives like the inverse and complement. I have added suffixes _inc and _c (or _com?). ( for C there will be suffixes f and l for the float and long double versions). Thanks. Paul PS I am on holiday for two weeks and will not respond to your observations until July. Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow(a)hetp.u-net.com

2 3

making cvs change for the first time
by DY, JERRY U (SBCSI) 13 Jul '04

13 Jul '04

After several hours of trying, I finally got cvs to checkout the boost module into my server. I'm still reading the book on cvs, since I've never used that before (we use ClearCase here). I would like to starting "checking in" some changes I have made over the last coupleof months from my local copy of the boost source (mostly to get it to compile using aC++) so before I do anything that might break something, I wanted to advertise what I plan to do so the kind and knowledgeable folks of this list can guide me appropriately. I'll start with the simplest of changes: boost/config/compiler/hp_acc.hpp:45 =====old========== #if (__HP_aCC <= 53800 ) # define BOOST_NO_MEMBER_TEMPLATE_KEYWORD #endif =====new========= #if (__HP_aCC >= 50000 ) && (__HP_aCC <= 53800 ) || (__HP_aCC < 31300 ) # define BOOST_NO_MEMBER_TEMPLATE_KEYWORD #endif commit command to run: cvs commit -m "updated so template keyword is used for aC++ 3.13 & above" hp_acc.hpp Thanks! -Jerry

1 0

RE: [boost] Re: [iterator_facade] postfix ++/--
by Glen Knowles 13 Jul '04

13 Jul '04

> From: David Abrahams > > iterator_facade now has to choose between *r++ = o being > valid and being a conforming TR1 input iterator (which > requires *r++ is of type T -- we have since declared that a > defect and *r++ need only be convertible to T). It makes > that choice by looking at the CategoryOrTraversal parameter: > iff it's convertible to std::output_iterator_tag, *r++ = o > will be valid. > > I am thinking it might be more appropriate to detect that *r > is a proxy, and only make *r++ = o valid in that case. Can > anyone think of a reason that a non-writable iterator > implementation would need to return a proxy from its operator*? I may be confused as what qualifies as a proxy, but there is the vector<bool> case. OTOH, if you're talking about needing to reach back into the container its probably fine. I can imagine a caching scheme that returns a week_ptr and goes back to the container to recreate it if its gone, but I don't think I'd want to do it. :) Glen

2 1

[iterator_facade] postfix ++/--
by David Abrahams 13 Jul '04

13 Jul '04

I'm getting ready to fix the issues we've discussed with postfix ++ (and by extension, --) in iterator_facade. Basically, the current implementation works for forward iterators but not for some input iterators: { self x = *this; ++*this; // <== here return x; } The problem is that for many input iterators, all copies reference the same element. The marked line increments the iterator, which causes the current element of the sequence to be skipped, so *a++ yields the /next/ element. To fix that, a++ needs to return a proxy type. When considering this stuff, please look at n1640 and not C++98 or TC1, as n1640 contains fixes for outright bugs that survived to TC1 as well. In particular, *a++ was required to return an input iterator's value_type until recently. If we don't know for certain that the iterator is a forward iterator and if *a returns something convertible to T const& (where T is the iterator's value type) it seems to me that we *must* assume that all copies of the iterator reference the same element, so the result of postfix ++ must be a proxy that contains a copy of *a. The new iterator framework is intended to support iterators with bidirectional traversal that are not conforming forward iterators (e.g. their operator* may return by-value). If an iterator is incrementable it is also dereferenceable, but the same doesn't hold for decrementability, so I'm not sure what to do about the result of postfix --. The best solution I can think of is that the actual decrement is delayed, and the iterator being decremented contains a flag that says "do an extra decrement before the next operation other than postfix decrement". That's a really bad solution, though: you can't really do a decrement in the destructor because it might throw, and such an iterator could easily have side-effects, so it'd be easy to get the iterator out-of-synch with expectations. Thoughts? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

3 9

Re: Re:[boost] [1.32 release] TODO list synchronization
by JOAQUIN LOPEZ MU?Z 13 Jul '04

13 Jul '04

----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Martes, Julio 13, 2004 6:52 pm Asunto: Re:[boost] [1.32 release] TODO list synchronization [...] > >> Serialization > >> ///////////// > > > >> Robert Ramey writes: > > > > c) check in > [...] > I haven't seen any test results from boost test servers for the > serialization library - I expect to see some soon. Excuse me if I'm wrong, but seems to me you've forgotten to add an entry for your library in status/Jamfile to enable automatic testing. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

CVS error for boost/config/platform/win32.hpp
by Michael Glassford 13 Jul '04

13 Jul '04

cvs commit: [14:55:18] waiting for david_abrahams's lock in /cvsroot/boost/boost/boost/config/platform Mike

2 1

RE: [boost] Re: "memory access violation" in boost::serialization
by Robert Ramey 13 Jul '04

13 Jul '04

Dirk Griffioen wrote: > I also outcommented line 125. > We will, however, upgrade to #20 as soon as possible. Note that #20 and subsequent versions do not have boost/serialization/shared_count.hpp but rather use a very crude hack to gain access to private variables within shared_count. Hopefully this will be addressed in a better way in the near future. You might want to wait just a tiny bit. It looks like serialization may be included in the upcoming boost release. If the release works out soon you might want to move right to boost 1.32. If the release boggs down or for some reason its inconvenient for you do move to 1.32 - you can use to #20. #20 is the last draft. I've tested it extensively with 1.31. >We have a lot of platforms here (HP, AIX, SUN, VMS, AS400 and Mainframe >- with different versions of native compilers and/or gcc) and it is >likely we will port to those platforms. If there's an interest, it might >be possible to gather some figures. Hmmm - embarrassment of riches. It is possible you might be able to run - at least occasionally the bjam test suite for some of the less common platforms? I would love to know how boost (and of course serialization) work with AS400 and Mainframe(?). I believe the others are already covered. If you're willing to run the tests, developers might be more willing the help with the porting. Robert Ramey

1 0

[program_options] Comeau DLL failures
by Vladimir Prus 13 Jul '04

13 Jul '04

Hello, the program_options test results for Comeau (e.g. http://tinyurl.com/4zl6f) show that it does not understand __declspec. Anybody has ideas why? Maybe, we should pass "--windows" to that compiler, or somehow enable __declspec support? - Volodya

1 0

Sombody broke the build system?
by David Abrahams 13 Jul '04

13 Jul '04

This just started happening: cd c:/tmp/ myjam -sTOOLS=gcc foo.obj BD Software STL Message Decryptor v2.43 for gcc c:\tmp\../boost/tools/build/v1\testing.jam:51: in boost-test *** argument error * rule get-library-name ( path ) * called with: ( ) * missing argument path c:\tmp\../boost/tools/build/v1\testing.jam:21:see definition of rule 'get-library-name' being called c:\tmp\../boost/tools/build/v1\testing.jam:470: in run Jamfile:3: in load-jamfiles c:\tmp\..\boost\tools\build\v1\bootstrap.jam:22: in boost-build c:\tmp\boost-build.jam:6: in module scope Compilation finished at Tue Jul 13 08:46:09 -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

RE: [boost] Re: "memory access violation" in boost::serialization
by Dirk Griffioen 13 Jul '04

13 Jul '04

Thanks Jeff, Your solution works - with a little twist: I took the solution from #20 (thanks Robert!) and now it loooks like: if(NULL != t.pi_) t.pi_->add_ref_copy(); I also outcommented line 125. & now my app works fine! We will, however, upgrade to #20 as soon as possible. Regarding the little discussion: it might very well be the case that uses find the library very usefull, without too many a problem. We certainly do, for instance on windows 2k (vc71) and HP True64 (probably gcc but I'm not sure). We have a lot of platforms here (HP, AIX, SUN, VMS, AS400 and Mainframe - with different versions of native compilers and/or gcc) and it is likely we will port to those platforms. If there's an interest, it might be possible to gather some figures. Cheers, Dirk -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jeff Flinn Sent: maandag 12 juli 2004 17:07 To: boost(a)lists.boost.org Subject: [boost] Re: "memory access violation" in boost::serialization "Dirk Griffioen" <d.griffioen(a)HumanInference.com> wrote in message news:2505062E579A9B45888B70D9BCFB3C073BA8BD@ex03.hidomain... > Hi, > > I encountered the following little problem: > > I would like to use the following datastructures with boost::serialize: > > struct Match {}; > typedef std::string Key; > typedef tst< Match, Key > TernarySearchTree; //this one has a shared_ptr > > typedef std::vector< TernarySearchTree > Trees; > typedef std::map< std::string, Trees > Symbols; > > I have defined some serialize overloads so saving goes fine, but when > loading I get a "memory acces violation" inside the following code: > > { > boost::archive::text_iarchive ia(ifs); > ia >> symbols_; > } > > More specific, inside <boost/serializiton/shared_count.hpp> > > void add_ref_copy() > { > #if defined(BOOST_HAS_THREADS) > mutex_type::scoped_lock lock(mtx_); > #endif > ++use_count_; > } > > Which constructs a scoped_lock, and there, the "explicit > scoped_lock(lightweight_mutex & m): m_(m)" seems to go wrong. Actually you'll find that the this pointer is either NULL or invalid. > > What could be the reason? The more since all worked fine (saving and > loading) when I used a simple vector of tst's. The following changes to .../boost/serialization/shared_ptr.hpp should do it: change line 74: if(t) t->add_ref_copy(); and comment out line 125: // shared_ptr_access::weak_count(*t) = 0; IIRC, line 125 is the primary culprit. ----------------- Jeff Flinn Applied Dynamics, International _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0