March 2004 - Boost - lists.boost.org

Re: Re: [boost] Implementing WaitForMultipleObjects using boost
by M Shetty 10 Mar '04

10 Mar '04

Hi, I was checking out if I could use Boost to port code written for Windows to Unix. The code has calls to WaitForMultipleObject which I would need to replace. Thanks and Regards, M Shetty -----Original Message----- From: "Jeremy Maitin-Shepard"<jbms(a)attbi.com> To: boost(a)lists.boost.org Date: Tue Mar 09 17:57:04 PST 2004 Subject: Re: [boost] Implementing WaitForMultipleObjects using boost >No, but why would you want to simulate it? > >-- >Jeremy Maitin-Shepard >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___________________________________________________ Check-out GO.com GO get your free GO E-Mail account with expanded storage of 6 MB! http://mail.go.com

1 0

_POSIX_C_SOURCE redefinition warning with python 2.3 and boost-1.31.0
by Peter Hornby 10 Mar '04

10 Mar '04

Sorry if this has been mentioned before. the following patch against boost-1.31.0 silences the warnings on linux, but I have not tested that there are no side-effects on other compilers. --------------------------------START PATCH------------------------ Index: boost/python/detail/wrap_python.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/python/detail/wrap_python.hpp,v retrieving revision 1.17 diff -p -r1.17 wrap_python.hpp *** boost/python/detail/wrap_python.hpp 1 May 2003 05:19:47 -0000 1.17 --- boost/python/detail/wrap_python.hpp 1 Mar 2004 05:36:49 -0000 *************** *** 23,28 **** --- 23,29 ---- // // Python's LongObject.h helpfully #defines ULONGLONG_MAX for us, // which confuses Boost's config + // Also kill any definition of _POSIX_C_SOURCE so Python.h can determine it. // #include <limits.h> #ifndef ULONG_MAX *************** *** 34,39 **** --- 35,44 ---- #ifndef ULONGLONG_MAX # define BOOST_PYTHON_ULONGLONG_MAX_UNDEFINED #endif + #ifdef _POSIX_C_SOURCE + # undef _POSIX_C_SOURCE + #endif + // // Get ahold of Python's version number --------------------------------END PATCH------------------------ Index: boost/python/detail/wrap_python.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/python/detail/wrap_python.hpp,v retrieving revision 1.17 diff -p -r1.17 wrap_python.hpp *** boost/python/detail/wrap_python.hpp 1 May 2003 05:19:47 -0000 1.17 --- boost/python/detail/wrap_python.hpp 1 Mar 2004 05:36:49 -0000 *************** *** 23,28 **** --- 23,29 ---- // // Python's LongObject.h helpfully #defines ULONGLONG_MAX for us, // which confuses Boost's config + // Also kill any definition of _POSIX_C_SOURCE so Python.h can determine it. // #include <limits.h> #ifndef ULONG_MAX *************** *** 34,39 **** --- 35,44 ---- #ifndef ULONGLONG_MAX # define BOOST_PYTHON_ULONGLONG_MAX_UNDEFINED #endif + #ifdef _POSIX_C_SOURCE + # undef _POSIX_C_SOURCE + #endif + // // Get ahold of Python's version number

2 2

Re:Re: [boost]Re: Re: [serialization] non-conformance
by Robert Ramey 10 Mar '04

10 Mar '04

>Robert Ramey wrote: >> This exchange illustrates the problem rather nicely. Its not clear >> to me from the name "aligned_storage" that its meant to do the same >> job as "stack_allocate" and in fact is easily confused with other >> boost functions. I've been able to find no documentation nor test >> nor other information. The only place its used is in variant.hpp but >> its not mentioned in the documentation of that either. There is no >> statement in the header itself as to what it does and the code is >> sufficiently non-trivial that it's not obvious what its supposed to >> do. The fact that it has a parameter than stack_allocate doesn't >> need also suggests that it's intended purpose is different from that >> of stack_allocate. The previous post referred to alignment_of rather than aligned_storage which seems to me to unrelated. Are they related in some non-obvious (to me) way? What's incorrect about my statement above? >It doesn't, see aligned_storage's "Rationale" subsection in >http://tinyurl.com/39asx. Is this part of boost documentation and tests? Robert Ramey

4 3

RE: [boost] First lambda
by Powell, Gary 10 Mar '04

10 Mar '04

> std::vector<X> xs(10); > unsigned long n = std::accumulate( > xs.begin(), xs.end(), 0UL, > _1 + (&_2) ->* &X::count); >This program adds up the "count" members in a vector of X objects. >Now, no offense intended, but this is nasty. There's just too much >extra syntax required for something so simple, plus you have to make >the type into a pointer just so you can dereference it Before I >realized I needed to take the address of _2, I had: > unsigned long n = std::accumulate( > xs.begin(), xs.end(), 0UL, > _1 + _2 ->* &X::count); >which is only slightly better (but incorrect). I realize that I can >use bind: > unsigned long n = std::accumulate( > xs.begin(), xs.end(), 0UL, > _1 + bind(&X::count,_2)); >but that's slightly counter-intuitive since the order of the target >object and its member pointer are reversed. It'd be nice to allow >something like: > unsigned long n = std::accumulate( > xs.begin(), xs.end(), 0UL, > _1 + _2.at(&X::count)); >while if _2 were to refer to a pointer type, we could say: > unsigned long n = std::accumulate( > xs.begin(), xs.end(), 0UL, > _1 + _2->at(&X::count)); >Dave Abrahams I tried to overload operator->() for a lambda object, but the C++ rule is that it _Must_ return a pointer, in this case to an object which has a member fn "at". So you are toast, because I couldn't figure out how to hold a pointer to a lambda object and recognize it as a delayed object holding a member pointer to vector<X>::at. When we aren't given the information about the member pointer. I'm working on a paper to allow us to overload operator.(), but the last time it was discussed in committee it burned the hair off of nearby dogs and scared children. So I'm waiting until the Redmond meeting so I won't have far to drag my burnt carcass home. Meantime it again highlights that a core language change to allow anonymous fns is needed so this whole mechanism of BLL can go away. // PROPOSED CHANGE IN SOME FUTURE PAPER unsigned long n = std::accumulate( xs.begin(), xs.end(), 0UL, long (long lhs, X const &rhs) // inline fn with no name. { return lhs + rhs.count; } ); Yours, -Gary-

12 35

Re: RE: [boost] Re: Formal Review: Circular Buffer
by JOAQUIN LOPEZ MU?Z 09 Mar '04

09 Mar '04

----- Mensaje original ----- De: "Powell, Gary" <powellg(a)amazon.com> Fecha: Martes, Marzo 9, 2004 10:55 pm Asunto: RE: [boost] Re: Formal Review: Circular Buffer > > The VTL library does it IMO correctly, allowing that if there is > an operation > T1 F T2, then > > V1 F V2 compiles. Otherwise you just force the user to write what > should be library > code. > > (Obviously swap can't do this unless the Allocators are the same.) > I don't quite get you here. I think the two allocator types cannot be equal: the first allocator allocates T1's, the second T2's. I might be totally misinterpreting you, of course. > template<class T1, class T2, class Alloc> > void swap( circular_buffer<T1, Alloc> &lhs, circular_buffer<T2, > Alloc> &rhs) > { > // do an element by element swap. > // and insert for the leftover elements. > } > IMHO doing an elementwise swapping is very ill-behaved. It would reduce to repeatedly calling something like: template <typename T1,typename T2> void swap_different(T1& x,T1& y) { T1 tmp(y); x=y; y=x; } So, for swap to have *some* exception safety the assignment operators must not throw, which seems too restrictive (think types with dynamic allocation). Maybe things can be improved a bit with something along this line: template<class T1, class T2, class Alloc1, class Alloc2> void swap( circular_buffer<T1, Alloc1> &lhs, circular_buffer<T2, Alloc2> &rhs) { circular_buffer<T1, Alloc1> new_lhs; // copy rhs into new_lhs circular_buffer<T2, Alloc2> new_rhs; // copy lhs into new_rhs lhs.swap(new_lhs); // nothrow rhs.swap(new_rhs); // nothrow } There is a final annoyance, though: in many cases the code can emit a narrowing cast warning (if assigning an int to a short, for instance.) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

RE: [boost] Re: Formal Review: Circular Buffer
by Powell, Gary 09 Mar '04

09 Mar '04

No, but just because the standard libraries scr*wed up is no reason to perpetuate the mistake. It's the rule of unexpected consequences. Is circular_buffer<int> x = { 1, 2, 3}; circular_buffer<short> y = { 1, 2 ,3}; x == y ?? or not? Sure looks like it should work. The VTL library does it IMO correctly, allowing that if there is an operation T1 F T2, then V1 F V2 compiles. Otherwise you just force the user to write what should be library code. (Obviously swap can't do this unless the Allocators are the same.) template<class T1, class T2, class Alloc> void swap( circular_buffer<T1, Alloc> &lhs, circular_buffer<T2, Alloc> &rhs) { // do an element by element swap. // and insert for the leftover elements. } template<class T1, class Alloc> void swap<T1, T1, Alloc> ( circular_buffer<T1, Alloc> &lhs, circular_buffer<T1, Alloc> &rhs) { // swap the whole container. lhs.swap(rhs); } Yours, -Gary- -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Pavel Vozenilek Sent: Tuesday, March 09, 2004 11:52 AM To: boost(a)lists.boost.org Subject: [boost] Re: Formal Review: Circular Buffer "Powell, Gary" <powellg(a)amazon.com> wrote > Shouldn't the comparison functions allow the types to differ? > > circular_buffer<T, MyAlloc> x; > circular_buffer<S, YourAlloc> y; > > bool b = x == y; for where the operator T == S is valid? > And what does the allocator have to do with it? > Hmm, do you know a STL implementation/some container with this feature? It may be often bug to compare containers with different types. /Pavel _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

RE: [boost] Formal Review: Circular Buffer
by Powell, Gary 09 Mar '04

09 Mar '04

Shouldn't the comparison functions allow the types to differ? I mean don't they still lexigraphically compare as long as there is a comparison function F that a F b for each element exists circular_buffer<T, MyAlloc> x; circular_buffer<S, YourAlloc> y; bool b = x == y; for where the operator T == S is valid? And what does the allocator have to do with it? Therefore IMO, all of the comparison functions should change from template< typename T, typename Alloc> bool operator F ( circular_buffer<T, Alloc> &lhs, circular_buffer<T, Alloc> &rhs); to template< typename T1, typename Alloc1, typename T2, typename Alloc2> bool operator F ( circular_buffer<T1, Alloc1> &lhs, circular_buffer<T2, Alloc2> &rhs); Yours, -Gary- powellg(a)amazon.com

2 1

RE: [boost] Formal Review: Circular Buffer
by Powell, Gary 09 Mar '04

09 Mar '04

documentation bug: Definition of data() Shouldn't that be only in the doc for the circular buffer space optimized? It isn't part of the adaptor interface. Also this may be old ground, but any particular reason you are not using a std::vector as the underlying container, coupled with the iterator adaptors? On the positive side, I like the functionality. I use this sort of container all the time. I often have things for which I can only hold N and when I have N+1, I need to purge the oldest. Yours, -Gary-

2 1

more lambda woes
by David Abrahams 09 Mar '04

09 Mar '04

Lambda docs say: "When an actual argument is supplied for a placeholder, the parameter passing mode is always by reference" Yet when I changed the following code from using boost::bind to boost::lambda, I got complaints that Field is an abstract class and can't be copied. void (self_t::* insert_)(Field const&) = &self_t::insert; std::for_each(fields.begin(), fiends.end(), bind(insert_, this, _1)); What gives? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 3

RE: [boost] Formal Review: Circular Buffer
by Powell, Gary 09 Mar '04

09 Mar '04

I have reviewed Jan Gaspar's circular buffer. What is your evaluation of the design? It's a useful container. I've hacked up a couple in my coding career and this one is very nice. Although I've usually implemented them as an adaptor to a container. This separates the container that I've optimized for the problem from the circular nature of it. What is your evaluation of the implementation? I was able to run the sample code with gcc 3.2 no problem. What is your evaluation of the documentation? Doc's are fine. What is your evaluation of the potential usefulness of the library? Useful for both embedded systems and those with a stack that needs to be limited. With a smart destructor you can push objects into the circular buffer holding them until you are either "full", or have time to deal with them. How much effort did you put into your evaluation? Shallow-depth study? Shallow study. One evening. Are you knowledgeable about the problem domain? Somewhat. I used to program for embedded systems, games, where memory is limited. We used this sort of buffer to constrain the the art resources from taking over the available memory. Other comments: Do you think the library should be accepted as a Boost library? I vote for acceptance with or without the suggested change about adapting a container. The comparison operators do need to be fixed though to compare two types. i.e. circular_buffer<int> x = { 1, 2, 3 }; // pseudo code. circular_buffer<short> y = { 1, 2,3 }; x == y -> true However I would prefer that the underlying container be part of the interface. But that's not a fixed in stone opinion.

1 0