- Boost - lists.boost.org

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

09 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

Re: [math constants] C++ Language gurus views
by Krishna Achuthan (TT) 09 Mar '04

09 Mar '04

I was able to cut the code down to this and got an ICE in VC 7.1: struct Base { template <typename T> operator T() { return T(); } }; struct Derived : Base { /* template <typename T> operator T() { return T(); } */ }; int main() { float f = Derived(); //ICE here } Notice that once you uncomment the function in the Derived class and hide the function in Base class, the ICE goes away. - Krishna Achuthan > Message: 10 > Date: Mon, 8 Mar 2004 21:15:27 +0100 > From: Bronek Kozicki <brok(a)rubikon.pl> > Subject: [boost] Re: [math constants] C++ Language gurus views > neededandCodewarrior & Comeau testers > To: boost(a)lists.boost.org > Message-ID: <g2gf20rte3qn.tx7plyoud13i.dlg(a)40tude.net> > Content-Type: text/plain; charset="us-ascii" > > On Mon, 08 Mar 2004 10:47:49 +0100, Daniel Frey wrote: > > but that's just a wild guess. I just seem to remember that I read about > > the VC having a small problem there. If this is in fact the problem, we > > might be lucky as my newest version no longer uses this conversion, > > instead I use a get<T>-function. > > I can reproduce this ICE on following code: > > template<template <typename> class F> struct constant > { > template <typename T> operator T() const > { > return F <T>()(); > } > }; > > template <typename T> struct map_type; > > template <template<typename> class F, typename T> struct constant_value > { > T operator()() const > { > return F<typename ::map_type<T> ::type>()(); > } > }; > > template <typename T> struct pi_value : constant_value< ::pi_value, T > > {}; > template <> struct pi_value <float> {float operator()() const {return > 3.14;}}; > > struct pi_t : constant <pi_value> {} const pi = pi_t(); > > int main() > { > const float f2 = pi; // ICE here > } > > possibly it can be made smaller, I just finished cutting it at this > moment and sent to private MS newsgroup asking for support. Comeau and > GCC both happily accept this code, and it just looks OK. However it's > bit too complicated and I'm too tired to look into it deeper. I hope > someone from VC71 developers will now take a look. VC71 quite often > bulks on invalid code, but if this one is valid (I certainly think so) > then we have issue that have to be fixed . In the meantime if you can > come up with some variations of the above, just send an email and I will > test it. BTW: problem with operator() and VC71 is that it does not > always recognize operator() as function, in context of pointer to member > function. However it does not ICE on that problem. > > Regards > > > B.

1 0

regresion tests - library name
by Pavol Droba 09 Mar '04

09 Mar '04

Hi, Where does the name of the library in the regression test table come from? string_algo library is reported as "algorithm", yet it is not the name used in Jamfiles. I assume, that the name comes from the directory name. This is not the best solution, because there can be more libraries residing in one subdirectory. (Although string_algo is probably just the first example). Isn't is possible to extract the name from the test-suite specified in Jamfile? This would make more sense. Regards, Pavol

2 1

RE:RE: [boost] [serialization] shared_ptr and binary archives
by Robert Ramey 09 Mar '04

09 Mar '04

David, This has been reported before but I've been unable to track it down. My personal guess is that it's a bug with VC 7.1 . Now that you've got a small test which demonstrates the problem, it should be easy to verify by using your test case under gcc. The attachement didn't show up on the list so please send it to me directly. Robert Ramey David Tonge wrote: >Now let me introduce a new problem. I seem to have uncovered another bug. >Using the workaround above I can demonstrate expected behaviour with text >archives. However, if I try to serialize a shared_ptr<A> containing a B* >to a BINARY archive then I get an assertion failure (puzzlingly in >basic_text_oarchive.hpp - line 133). I don't have any problems serializing >shared_ptr<A>s containing A*s to binary archives, and I don't have any >problems at all with text archives. >The file I've attached is a heavily modified version of demo_shared_ptr.cpp >which performs four tests: > 1. Serialize shared_ptr<A>s containing A*s to and from text archives. > 2. Serialize shared_ptr<A>s containing B*s to and from text archives. > 3. Serialize shared_ptr<A>s containing A*s to and from binary archives. > 4. Serialize shared_ptr<A>s containing B*s to and from binary archives. >Tests 1-3 all work fine. Test 4 fails as described. >I'd appreciate it if others with an interest in the serialization library >could take a look. I can quite believe that it's an error on my part but I >haven't been able to spot it yet.

1 0