- Boost - lists.boost.org

[iterator] Efficiency of transform_iterator
by Arno Schödl 04 Sep '08

04 Sep '08

Looking at other performance issues with stacked iterators, the fact that transform_iterators, in particular the ones doing calculation and returning by value, may get dereferenced many times and do the same calculation many times over seems bad to me, because it is so different from the behavior of trivial iterators, which are very cheap to dereference. I am sure this has been suggested many times, but why isn't there a cached_transform_iterator that contains an internal cache for its result? The actual calculation would be done in the ctor and after increment/decrement/advance. The cached_transform_iterator must know its end like a filter_iterator, because it must not dereference it. As invariant, the cache could either be always constructed, which saves some checks, but needs the value_type to be cheaply default-constructible, or only if not at end. tranform_iterators running on bidirectional_iterators could still claim that they are random_access, so that when advance is called, they skip N items of the underlying iterator and only do the computation on the destination item. This may be problematic because algorithmic choices may be made based on the traversal category, and performance suffer as a result. I am not sure how much of a problem that would be in practice. It would be nice to do the same for forward_iterators, defining a forward_random_access_traversal category. Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229

2 2

Re: [boost] [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.
by Johannes Brunen 04 Sep '08

04 Sep '08

Hello Jurko, "Jurko Gospodnetic" <jurko.gospodnetic(a)docte.hr> schrieb im Newsbeitrag news:<g9neff$v6f$1(a)ger.gmane.org>... > First some collected background information related to Microsoft's > checked & debugging iterator support to get a clearer image of what we > are modeling. And could someone please collect a similar summary for > other compilers/libraries? Below you can find a excerpt of the stlports user config file. I do not use the stlport so maybe someone else can give more profound info. > Now the design summaries in order of preference. Note that the list > is a 'work in progress' and the ordering and the 'importance' are based > on my own personal choices and current understanding of all the feedback > received so far. Feel free to holler if you do not agree with them and > I'll update as needed. Currently, I favor design B. > -------- > Design B > -------- > Improved version of the originally suggested 'Design A' allowing for > debugging iterators and making the features msvc toolset specific, > although the exact implementation described here is based on the msvc > compiler documentation: > > Feature: <checked-iterators> > 'on' --> _SECURE_SCL=1 > 'off' (default) --> _SECURE_SCL=0 > > Name mangling: <checked-iterators> adds 'c' to library name if > enabled (assuming it's applicable). > > Feature: <debugging-iterators> > 'on' --> _HAS_ITERATOR_DEBUGGING defined > 'off' (default) --> _HAS_ITERATOR_DEBUGGING not defined > > <runtime-debugging>off & <debugging-iterators>on are incompatible. > > Name mangling: <debugging-iterators> adds 'e' to library name if > enabled (assuming it's applicable). > * We really need to mangle library names to make it clear which > libraries have checked/debugging iterators enabled and which do not, at > for those compiled with MSVC, as these options produce binary > incompatible libraries. This can be done by either adding new tag > letters for these features... Yes > * All this will affects only code compiled using MSVC compiler > versions 8.0 & above. It may also affect other non-MSVC toolsets as we > get more information on them. Stlport gives also additional support for checking. Greetings, Johannes P.S.: Excerpt from the STLport user-config.h file responsible for configuration of the library. I did take all entries which might be relevant in the context. /* * Set _STLP_DEBUG to turn the "Debug Mode" on. * That gets you checked iterators/ranges in the manner * of "Safe STL". Very useful for debugging. Thread-safe. * Please do not forget to link proper STLport library flavor * (e.g libstlportstlg.so or libstlportstlg.a) when you set this flag * in STLport iostreams mode, namespace customization guaranty that you * link to the right library. */ #define _STLP_DEBUG 1 /* * You can also choose the debug level: * STLport debug level: Default value * Check only what the STLport implementation consider as invalid. * It also change the iterator invalidation schema. * Standard debug level: Check for all operations the standard consider as "undefined behavior" * even if STlport implement it correctly. It also invalidates iterators * more often. */ #define _STLP_DEBUG_LEVEL _STLP_STLPORT_DBG_LEVEL #define _STLP_DEBUG_LEVEL _STLP_STANDARD_DBG_LEVEL /* When an inconsistency is detected by the 'safe STL' the program will abort. * If you prefer an exception define the following macro. The thrown exception * will be the Standard runtime_error exception. */ #define _STLP_DEBUG_MODE_THROWS /* * Use this option to catch uninitialized members in your classes. * When it is set, construct() and destroy() fill the class storage * with _STLP_SHRED_BYTE (see below). * Note : _STLP_DEBUG and _STLP_DEBUG_ALLOC don't set this option automatically. */ #define _STLP_DEBUG_UNINITIALIZED 1 #define _STLP_DEBUG_ALLOC 1 /* * Uncomment and provide a definition for the byte with which raw memory * will be filled if _STLP_DEBUG_ALLOC or _STLP_DEBUG_UNINITIALIZED is defined. * Choose a value which is likely to cause a noticeable problem if dereferenced * or otherwise abused. A good value may already be defined for your platform. */ #define _STLP_SHRED_BYTE 0xA3 ____________ Virus checked by G DATA AntiVirusKit Version: AVK 19.305 from 04.09.2008 Virus news: www.antiviruslab.com

1 0

[regex] Build with ICU broken
by Jürgen Hunold 04 Sep '08

04 Sep '08

Hi ! It seems that building Regex with ICU support is broken because of http://svn.boost.org/trac/boost/changeset/48454 compiling on SuSE 11.0 results in the attached error message. It seems that Boost.Build does not evaluate the added dependency. I crosspost to Boost.Build because I'm not sure if this is supposed to work or not. Or if anyone has a better idea. The regression table fro regex is green because obviously no one is using ICU in regression testing. I only use it to minimize the annoying startup messages from Boost.Build... Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 2

[exception] missing public header files in SVN
by vicente.botet 04 Sep '08

04 Sep '08

Hi Emil, What is going on the Boost.Exception library SVN repository? The following 1.36.0 public header files are missing: * boost/exception/enable_current_exception.hpp * boost/exception/enable_error_info.hpp Vicente --------------------------- Vicente Juan Botet Escriba

2 1

[dataflow][review] facilities for creating generic components
by Stjepan Rajko 04 Sep '08

04 Sep '08

Hello, I updated the Dataflow documentation with some examples showing how to create generic (in the sense that they can be used with a number of signal signatures) components for Dataflow.Signals with the help of some provided class templates. These class templates are applicator, conditional, instantiator, and modifier (there is also a conditional_modifier which is not documented, but it basically provides functionality of both conditional and modifier). The updated docs (with examples) are uploaded to: http://www.dancinghacker.com/code/dataflow/ You will find the mentioned class templates in the Components subsection of the Dataflow.Signals section. For example, the modifier documentation shows how to easily build a generic multiplier component, which will multiply each argument of the passing signal by a specified factor. The component could then be used as follows: { signals::storage<void (int, double)> result; multiplier<void (int, double)> multiply_by_3 (3); // result will store the result of the multiplication multiply_by_3 >>= result; multiply_by_3(1, 1.5); BOOST_ASSERT(result.at<0>() == 3); BOOST_ASSERT(result.at<1>() == 4.5); } { signals::storage<void (float, int, double)> result; multiplier<void (float, int, double)> multiply_by_half (0.5); // result will store the result of the multiplication multiply_by_half >>= result; multiply_by_half(1.0f, 9, 9.0); BOOST_ASSERT(result.at<0>() == 0.5f); BOOST_ASSERT(result.at<1>() == 4); BOOST_ASSERT(result.at<2>() == 4.5); } Note that without this facility, building such a generic multiplier would be somewhat involved (unless you are using variadic templates). Stjepan

1 0

min function that accepts any number of arguments
by Peng Yu 03 Sep '08

03 Sep '08

Hi, std::min accepts only two arguments. When I have more than two arguments to compare, it becomes inconvenient. I'm wondering it is possible to added a min function that accepts any number of arguments in the future version of boost? Thanks, Peng

5 5

[1.36.0, date_time] boost/date_time/compiler_config.hpp not copied by install?
by Stefan Heinzmann 03 Sep '08

03 Sep '08

Hi all, when building boost 1.36.0 on Windows using VS2008 SP1 I found that the file boost/date_time/compiler_config.hpp was not copied to the install target directory tree. Can anybody confirm this or have I made a mistake? Cheers Stefan __________________________________________________ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com

1 0

[string _algo library] warning/issues under visual c++ 8
by Sean Farrow 03 Sep '08

03 Sep '08

Hi: When using the string algo library func tion is_any_of, I get the following warning under visual c++: c:\program files\boost\boost_trunk\boost/algorithm/string/detail/classification.hpp (102) : warning C4996: 'std::copy': Function call with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To disable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators' Could secure warnings be turned off, or could we potentially look int o using checked iterators with visual c++? Also, I get the following isues: c:\program files\boost\boost_trunk\boost/algorithm/string/classification.hpp(206) : see reference to function template instantiation 'boost::algorithm::detail::is_any_ofF::is_any_ofF>(const RangeT &)' being compiled with [ CharT=char, IteratorT=const char *, RangeT=boost::iterator_range ] Is this something I should worry about, what does this mean? Any help apreciated. Sean. __________ Information from ESET NOD32 Antivirus, version of virus signature database 3406 (20080902) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com

2 1

Re: [boost] Try-out Adler-32 code?
by Bram Neijt 02 Sep '08

02 Sep '08

That should be ok then. The RFC states: """The MD5 algorithm is being placed in the public domain for review and possible adoption as a standard."""" So there should be no problem then. I had problems with the code I used was to much of a "derived work", which ment: """License is also granted to make and use derivative works provided that such works are identified as "derived from the RSA Data Security, Inc. MD5 Message-Digest Algorithm" in all material mentioning or referencing the derived work.""" I'm no lawyer but I think you are in the clear then :D Bram On Tue, 2008-09-02 at 04:42 -0400, Daryle Walker wrote: > I didn't take the implementation from any of the MD5 sources lying > around, I did a "clean room" build from the RFC's description. > (They're all byte-wise, while mine is bit-wise [the only one, > AFAIK].) I did use the RFC's sample code to get the values of the > various constants. Do I need to have some sort of licensing with the > RFC board; aren't they free for all?

3 3

[serialization] generic runtime helpers
by JOAQUIN M. LOPEZ MUÑOZ 02 Sep '08

02 Sep '08

Hello, The section on proposed case studies for Boost.Serialization talks about the poosible inclusion of a so-called "generic runtime helper": http://tinyurl.com/6khxns http://www.boost.org/doc/libs/1_36_0/libs/serialization/doc/new_case_studie… which subject I had the pleasure to discuss with Mr. Ramey some time ago. I've got a couple of questions regarding this feature: 1. Is there any tentative release version for getting this included? 2. Is the idea to include the generic runtime helper as part of the core API of an Archive, or will it be just an adaptor? In other words, would the core "Saving Archive" and "Loading Archive" concpets be extended to also feature this runtime helper? FWIW, I'm strongly in favor of having the runtime helper be part of the core Archive concepts: it is my stance that this can be incredibly useful to implement serialization code for types with special lifetime semantics (as is the case with boost::shared_ptr and boost::flyweight) without violating the encapsulation either of the type or of Boost.Serialization. The key and only property of such a runtime helper is its ability to associate an Archive object with a type-dependent helper object, which I see as a very modest, yet highly useful, extension to the Archive concept. Just to exemplify how useful helpers can be, allow me to sketch the serialization process of flyweight<T> as implemented with runtime helpers: * Saving: the helper<flyweight<T> > is just a bag of flyweight<T>s whose elements are *exemplars*. when saving a new flyweight, first we check whether an equivalent flyweight is already present in the helper: if so, the index of the exemplar is output, otherwise, the underlying T associated to the flyweight is saved and the flyweight is added to the helper as a new exemplar. * Loading: again the helper is a bag of flyweight<T>s. When loading a flyweight<T>, we can read either an index or a T object: in the former case we just initialize the flyweight with the corresponding exampler; in the latter case we load the T object, construct a flyweight from it, add it as new exemplar and initialize the loading flyweight with it. This implementation is totally non-intrusive and maximally efficient. An observant reader will also notice that it can be translated almost literally to a serialization scheme for shared_ptr, which shows the potential of the runtime helper feature. Currently, shared_ptr serialization relies on a non-documented adhoc helper, which technically makes it a non-serializable type: promoting the runtime helper to the Archive concept would allow to make shared_ptr a first-class citizen. I also think more types can benefit from this feature when implementing their serialization code. Valid concerns may be raised that extending the Archive concept would break backwards compatibility. However, it is easy to help programmers migrate their user-defined archives to the new concept: just provide a mix-in base class implementing the required functionality, so that if class my_archive { }; models the original Archive concept, just adding the following: class my_archive: public boost::archive::runtime_helper_impl { }; would automatically make my_archive model the new concept. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0