March 2004 - Boost - lists.boost.org

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

Updates to the Review Schedule/Upcoming Reviews
by Jeff Garland 09 Mar '04

09 Mar '04

I've recently checked in a new version of the review schedule. So you don't have to go to CVS and look, here is the set up upcoming reviews: Library Author Review Mgr Dates Circular Buffer Jan Gaspar Pavel Vozenilek 2004 Mar 5-15 Indexed Set Joaquín M López Muñoz Pavel Vozenilek 2004 Mar 20-30 Assignment Thorsten Ottosen Tom Brinkman 2004 Apr 1-11 Serialization Robert Ramey Jeff Garland 2004 Apr 13-20 Container Traits Thorsten Ottosen Hartmut Kaiser 2004 Apr 28-May 7 Tribool Douglas Gregor - - More IO Daryle Walker - - Iostreams Jonathan Turkanis - - Output Formatters Reece Dunn - - Pointer Containers Thorsten Ottosen - - Named Params David Abrahams & Daniel Wallin - - Wave Hartmut Kaiser - -

3 3

[Boost-bugs] [ boost-Bugs-912368 ] boost::tokenizer implicit typename
by SourceForge.net 09 Mar '04

09 Mar '04

Bugs item #912368, was opened at 2004-03-09 00:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=912368&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Ravnsgaard Riis (ravnsgaard) Assigned to: Nobody/Anonymous (nobody) Summary: boost::tokenizer implicit typename Initial Comment: boost::tokenizer gives warnings on gcc 3.3.1 (MinGW build) about implicit typenames in two typedefs in offset_separator::operator() and char_separator::operator(). Both typedefs look like: typedef tokenizer_detail::assign_or_plus_equal< tokenizer_detail::get_iterator_category< InputIterator>::iterator_category> assigner; I changed them to: typedef tokenizer_detail::assign_or_plus_equal< typename tokenizer_detail::get_iterator_category< InputIterator>::iterator_category> assigner; I.e. I added a "typename" keyword inside the typedef. g++ warned that "Implicit typename is deprecated". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=912368&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0