- Boost - lists.boost.org

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 08 Mar '04

08 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

Futures revisited
by Slawomir Lisznianski 08 Mar '04

08 Mar '04

Hello, During discussions on possible extensions to Boost.Threads, concept of Futures came up rather frequently. Below, I’d like to introduce a particular implementation available at www.rhapsodia.org of which requirements were defined as follows: 1. Provide means to register exception types with a "Future Registry". Rationale: I find it imperative that users should not have to define a list of exception types on each invocation yielding a Future object. Instead, provide the ability to register exception types with a Future Registry and bundle it with Future objects. I feel that compile time registration should be sufficient. 2. Work under the assumption that asynchronous invocations returning Futures and system threads are not coupled. In particular, Futures implementation should not relay on joining with a particular thread to perform synchronization for returning results. Rationale: Although most prevalent, the technique of joining with a particular thread to synchronize on returning result is too limiting. It implies that each task be run on a dedicated thread, specially created to handle it and destroyed to meet with a caller using a Future. Although this approach may be adequate under certain conditions, it generally tends to be expensive on system resources and disorganizes the application. For example, it’s impossible to control the number of concurrently running threads. It may also perform poorly if executed code happens to run shortly as the overhead of creating a thread and cleaning up after it may be significant. More robust approach is to use a queue and a thread pool for running tasks. This adds complexity on the synchronization side, as we can no longer rely on a lifetime of a thread to join with Future’s result. 3. Ability to utilize Futures with arbitrary code without explicit support for them. Rationale: For implementation to be widely adopted, it should be possible to turn just about any function call into a Future-armored asynchronous invocation. No explicit thread synchronization primitives should be used as well. 4. Implement using existing Boost.Threads facilities only. Rationale: Boost.Threads library provides enough support to implement Futures paradigm that meets requirements listed here. 5. STL and Boost compatible. For example, storing Futures in an STL container. Be strongly typed. Futures implementation and usage patterns must naturally coexist with STL and Boost code. Additionally, compile-time type validation is key to safer code. Attached is a sample file from Rhapsodia library showing the use of Futures. Regareds, Slawomir Lisznianski [ www.rhapsodia.org ]

2 1

Blipping back on the radar... hopefully.
by Hubert Holin 08 Mar '04

08 Mar '04

Somewhere in the E.U., le 08/03/2004 Bonjour After what seems like an eternity, I may perhaps be able to get back to work on the math libraries I contributed here. For the last year or so, I believe, I could not even find the time to lurk in the newsgroup, that following about a year in which I barely had time to just lurk. I also fear mail sent thru my bigfoot redirector may have been chewn up befor I got it (or else nobody compalined about these libraries ;-) ). I know I have a lot off "Cat Soup" to do (eat :-) ?), and to make things more interesting, I may have to move to Xcode (gcc) as a primary platform rather than CodeWarrior (I may no longer be able to personnaly afford the updates, and MetroWerks has made it impossible for me to update at work by requiring they be purchased thru the internet... and that's corporately impossible where I work). As I had locally incorporated patches which I fear were never uploaded, some to squash incompatibilities, I apologize for the inconvenience. Not all the fires are out, so to speak, but most are now somewhat under control. I should have three weeks with a modicum of time to set a few things straight, at least. Merci Hubert Holin

2 1

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

08 Mar '04

Eric, The recent changes to the new std_min/std_max caused some unexpected problems in uBLAS. I have narrowed them down to support for boost::numeric::interval in uBLAS. This is picked up by ublas/libs/test7. This test is however not at present part of the regression run. The new std_max (or std_min) is implemented by returning a constant reference to the return value of std::max. This should be OK as std::max similarly returns a const reference to one of its const reference parameters. For gcc this causes some problems when the type is a boost::numeric::interval. The test case is very simple. #include <boost/numeric/interval.hpp> #include <boost/minmax.hpp> int main() { boost::numeric::interval<float> a,b,c; c = boost::std_max(a, a); } gcc (2.95.3 and 3.3.1) is only warning "returning reference to temporary". I am surprised this doesn't show up in more cases. Why gcc thinks it needs a temporary here is beyond me Michael -- ___________________________________ Michael Stevens Systems Engineering ___________________________________

3 3