- Boost - lists.boost.org

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

Re:[boost] Re: Re:Serialization17 - assert in basic_text_oarchive.hpp
by Robert Ramey 09 Mar '04

09 Mar '04

Jeff Flinn wrote: >Another data point. I've separated binary/text/xml serialization into three >.cpp files so that each of the three compilation units only deals with a >single archive type. No doubt that works around the issue but it doesn't make ME feel much better. The problem of "confused" template parameters was a big one with VC 6.0 . I had hoped all those issues had been resolved with VC 7.1. Now I'm not so sure. I did make a small example which included several archive types but I had no problem with it so I'm kind of stuck. >The following results: > Save Load ---- ---- >Bin Pass Pass >Txt Pass Pass >Xml Pass Fail >Where Fail is an assertion in basic_xml_archive.ipp Line: 29. >Attached is the offending xml archive, if it will offer any insight. This is most likely a bug of my own in generating/parsing xml archives. Again, I'm going to need a smaller test case. However, your example does illustrate the need to replace the assertions with exceptions in case the XML has been tampered with - I'll add these in. Robert Ramey

3 4

Re: boost::any: explicit constructor?
by Kevlin Henney 09 Mar '04

09 Mar '04

In message <uk727uuvv.fsf(a)boost-consulting.com>, David Abrahams <dave(a)boost-consulting.com> writes >>> >>>The conversion to boost::any isn't a widening conversion in the usual >>>sense, though, is it? Normally, a widening conversion preserves not >>>only the information but the *interface* of the original data -- you >>>wouldn't consider an implicit conversion from int to string a widening >>>conversion, would you? >> >> Your assumption is not quite correct: most widening conversions are >> not interface preserving. > >So you're saying it's not even a little correct, it sounds like. Can >you give some examples of non-interface-preserving widening >conversions? T * to void *, derived * to base *, int (32 bit) to double (64 bit), T * to const T *, etc. Widening conversions are in the direction of the supertype, hence they often have a subset of the interface of source type. The corresponding narrowing of the interface with the widening of the type is not always the case, eg an int to long is effectively interface preserving -- the same set of operators is supported for both types. Kevlin -- ____________________________________________________________ Kevlin Henney phone: +44 117 942 2990 mailto:kevlin@curbralan.com mobile: +44 7801 073 508 http://www.curbralan.com fax: +44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ____________________________________________________________

3 8

Re: std_min/std_max reference return value is problematic with boost::interval
by Michael Stevens 09 Mar '04

09 Mar '04

Eric, Guillaume, (sorry about the previously half send while I was composing) Thanks for the info, I think the solution is partly simple, partly complex. > Eric: What strikes me as odd with this overload, though, is that max(a,b) in > this case will return something that is not equal to either a or b. That > seems counter-intuitive. Is this right? Firstly it is now clear to me (as stated in the documentation) that max(interval_a,interval_b) is not std::max. The difference in semantics is however only represented by the difference in return value. > Me: Why gcc thinks it needs a temporary here is beyond me. I was confused here. I thought std_max would be choosing the std::max overload in this case and not the boost::numeric::interval::max overload. The later is however more specialised. > Guillaume: Consequently, since std_max has been defined so that it > returns a reference, it can't be used when one argument is an interval > and GCC is right to complain. GCC is correctly complain. The new std_max/ std_min should ONLY be used as a where we specifically require std::max/min. Therefore the committed changes to interval (particular utility.hpp) are incorrect. > Eric: The fix is to detect whether the unqualified call to max returns an > lvalue or not and define the return type of std_max appropriately. Easy > enough. > Given that std::max/min in the standard are defined to return a reference this fix would seem unnecessary/wrong. We don't want to use boost::std_max in this case. > However, in the particular case of uBLAS, the problem lies elsewhere > imho. At lines 620-621, 688-689, 753-754 of ublas/traits.hpp in the > equals function, uBLAS should not be using the norm_inf function. Indeed > norm_inf relies on abs(interval); and what is really needed is a > norm_inf_for_equals function that would rely on norm(interval). The same > problem will also appear later with complex intervals. Thanks for following this up and the info. The maths needs checking here. Lets see what Joerg thinks. For a Boost 1.31.x release we should change the mentioned lines in traits.hpp to use boost::numeric::interval::min/max so we at least do not have a regression. Michael -- ___________________________________ Michael Stevens Systems Engineering 34128 Kassel, Germany Phone/Fax: +49 561 5218038 Navigation Systems, Estimation and Bayesian Filtering http://www.sf.net/Bayes++ ___________________________________

2 1

Re: std_min/std_max reference return value is problematic with boost::interval
by Michael Stevens 09 Mar '04

09 Mar '04

Eric, Guillaume, Thanks for the info, I think the solution is partly simple, partly complex. Firstly it is now clear to me (as stated in the documentation) that max(interval_a,interval_b) is not std::max. The difference in semantics is however only represented by the difference in return value. The new std_max/ std_min should ONLY be used as a -- ___________________________________ Michael Stevens Systems Engineering 34128 Kassel, Germany Phone/Fax: +49 561 5218038 Navigation Systems, Estimation and Bayesian Filtering http://www.sf.net/Bayes++ ___________________________________

1 0

Boost.Iterator and const-qualification of value_type
by Joaquín Mª López Muñoz 09 Mar '04

09 Mar '04

A side note in iterator_facade docs says that the standard requires that an iterator's value_type not be const-qualified. I've skimmed through the std and, though this requirement seems reasonable enough, I haven't found any excplicit statement about it. Clues? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0