August 2008 - Boost - lists.preview.boost.org

Problems with building docs on trunk
by Andrey Semashev 03 Aug '08

03 Aug '08

Hi, I recently updated to Boost trunk and now I cannot build any QuickBook documentation. I get the following error: /home/lastique/src/boost/trunk/tools/build/v2/build/virtual-target.jam:1032: in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <phtml>standalone_HTML.manifest error: previous virtual target { boostbook%boostbook.docbook-to-htmldir-standalone_HTML.manifest.HTMLDIR { boostbook%boostbook.boostbook-to-docbook-bimap.docbook.DOCBOOK { quickbook%quickbook.quickbook-to-boostbook-bimap.xml.XML { bimap.qbk.QUICKBOOK } } } } error: created from libs/bimap/doc/standalone error: another virtual target { boostbook%boostbook.docbook-to-htmldir-standalone_HTML.manifest.HTMLDIR { boostbook%boostbook.boostbook-to-docbook-bimap.docbook.DOCBOOK { quickbook%quickbook.quickbook-to-boostbook-bimap.xml.XML { bimap.qbk.QUICKBOOK } } } } error: created from libs/bimap/doc/standalone error: added properties: <link>static error: removed properties: <link>shared /home/lastique/src/boost/trunk/tools/build/v2/build/virtual-target.jam:468: in actualize-no-scanner from module object(file-target)@505 /home/lastique/src/boost/trunk/tools/build/v2/build/virtual-target.jam:123: in object(file-target)(a)505.actualize from module object(file-target)@505 /home/lastique/src/boost/trunk/tools/build/v2/build-system.jam:681: in load from module build-system /home/lastique/src/boost/trunk/tools/build/v2/kernel/modules.jam:281: in import from module modules /home/lastique/src/boost/trunk/tools/build/v2/kernel/bootstrap.jam:128: in boost-build from module /home/lastique/src/boost/trunk/boost-build.jam:17: in module scope from module I tried the branches/release version of Boost, but the error persists. I had QuickBook working just fine before I updated (sorry, I don't remember the previous revision number). Could someone point me to the problem source, please?

2 3

A library for checking overflow in the built-in int types?
by Isaac Dupree 02 Aug '08

02 Aug '08

Is there interested in a library to check for overflow in (primarily) the built-in integers? (and some other things related to int-wrapping: see below). It implements a different thing than constrained_value, though I suppose they might have some code in common. I need/want it in my own project, so I've been working on such a thing: Use case: I'm trying to write some performance-critical code that might buggily rely on larger ints than are provided, and it's not obvious whether there are actually any integer overflows happening (I hope not, but I need to test -- there are some bugs that might be overflow-related). Additionally, it has to behave exactly the same on the network across different computers it's compiled on (so I've been using all specific int-sizes, such as int32_t). (okay, it's a multiplayer game where all players simulate on their own computers to keep in sync, and most of the time only transfer their very simple commands over the network.) For example, a bug I'd had that took me a while to squash involved not realizing that right/left-shifting by an unsigned integer's bit-size is undefined behavior, (the bug manifested on x86-linux-gcc but not powerpc-linux-gcc). Also, the platforms manifested different behaviors for dividing by zero (crash with SIGFPE(!) versus continue with some value). Most of the time I want overflows to be treated as errors, (although sometimes I actually want the unsigned modulo-behavior, and a plausible error behavior would be to clamp the value to within the range and log to stderr). I looked at a (proposed for boost?) constrained-value library http://student.agh.edu.pl/~kawulak/constrained_value/index.html . Since I want the full range of the builtin types, and constrained_value deliberately doesn't check for overflow in the underlying representation, I need something different (or additional). Ideally it could be a drop-in replacement for the builtin types I've been using. Like constrained_value, I decided it was too unsafe to have implicit casting back to the representation-type. The integral-promotion effects inherited from C would surely end up being changed by such a wrapper. So I also want a wrapper that just "sanitizes" those promotions: I think e.g. adding ints of the same signedness should produce a value with the max. of their two bit-sizes, and anything else (including mixed-signedness) require explicit casting. Then I can wrap that type with my overflow-checking template (which has performance overhead) for testing, while having exactly the same behavior as without the overflow-checking when there are in fact no overflows. There's also the issue of determinism in relation to implementation- defined behavior -- e.g. dividing with or right-shifting negative numbers. In one wrapper I probably want to (optionally, depending on policy template arguments perhaps) prevent doing those operations on the underlying types, and perhaps have another wrapper that detects those cases and replaces them with builtin operations that work. (e.g. (sint >> shift) becomes (sint >= 0 ? (sint >> shift) : ~(~sint >> shift)) (I started out not being so wrapper-happy, but then I thought it was probably cleaner to have a library that makes it generally easy to wrap int-like things.) Hopefully a compiler that doesn't need them, can just optimize out the pessimizations. Other notes about implementation "decisions" I've thought about: It's very convenient to assuming that the underlying values are two's complement bitwise (signed or unsigned) integer types that have some number of bits, for writing algorithms to efficiently check for overflow, so I do that in the part of the library that has range-checking algorithms for ints. However, I allow underlying types to be larger than strictly needed (and in some cases the underlying type being larger, allows the overflow-checking code to be faster as well). Currently I have the overflow-checking algorithms in macros, which I don't like much. But it has some advantages: - library can even be used in preprocessor constant expressions, e.g. in an #if. (not worth as much as it could be because it can't interact with Boost.Preprocessor constants usefully.) - Until we have C++0x "constexpr" functions, the only way to share int-based algorithms between runtime code and compile-time template code is macros. - The maximum bit-sizes of the values could be allowed to vary at runtime. But then we lose a lot of static optimizations. Putting the bit-sizes as dynamic arguments even to an "inline" function template seems risky, but making them static is forever. In light of constrained_value's mutable ranges, I don't think there's actually a need for that. Bit-shift amounts are often but not always known at compile-time... but let's let the compiler worry about that? But there's a disadvantage: - No explicit sharing; the compiler will have to figure out that two expressions are identical. However, explicit sharing kills 'constexpr' functions too... but at least then the shared expression can be put into another named function so that it might be less work for the compiler to notice that they're the same. Overflow checking for signed numbers is annoying/inefficient, because e.g. negating the minimum value is overflow. Perhaps there should be two signed compile-time modes, one in which those can overflow but not the bitwise operators ~ | ^ &, and another mode without that minimum value, in which normal arithmetic would be "safer" but bit-operations a bit less so (but you should know what you're doing if you're using them on signed values anyway). Conceivably a wrapper something like this could be used to wrap "integer-valued doubles that are small enough to represent each consecutive integer" as odd-sized integer values computed by FPU. But (x < 1) where x is a double may not even give the same answer each time, apparently! So I don't have the skills to do anything like that. ideas of what people might want for overflow behavior: - boost::optional<int> to have non-throwing failure, similar to floating-point NaN. - clamping to the endpoints (overflow becomes the max value defined by the bit-size, underflow the min value, and if division by zero is one of the things detected... well that's something a policy will have to say). - modulo-arithmetic for any number of bits you want, even if it's not a multiple of CHAR_BIT. - obviously, exception throwing or assert failure In the process I found/invented an int-log-base-two implementation that seems it should be decently fast at runtime and also works as an integer constant expression. (although with GCC it can detect with __builtin_constant_p and bitsizes, whether it can change that to __builtin_clz[l[l]], so it can be often be turned into a special processor instruction at runtime for many architectures including x86 and powerpc; do other compilers have facilities like that?). Unfortunately I've been struggling a little with the int-wrapping template classes, but I thought I'd ask if there was interest before struggling to make sure my code approached Boost-quality rather than just "good enough for me" quality :-) cheers, -Isaac

6 5

Why I hate subversion
by Eric Niebler 02 Aug '08

02 Aug '08

U boost/indirect_reference.hpp U boost/parameter.hpp svn: In directory 'boost' svn: Can't move 'boost/.svn/tmp/foreach.hpp.2.tmp' to 'boost/foreach.hpp': Permission denied ericne@ericne-xps ~/boost/org/trunk $ svn up svn: Checksum mismatch for 'boost/.svn/text-base/enable_shared_from_this.hpp.svn-base'; recorded: '12d8c5183a709a7699c13b312073c36c', actual: 'c89a6b23045ff8c89d2de74213d1649a' Does this ever happen to anybody else? I get this random corruption of my local subversion repository about once a month. -- Eric Niebler Boost Consulting www.boost-consulting.com

11 15

[unnullable_ptr] Proposal for a new library
by Angel Tsankov 02 Aug '08

02 Aug '08

Hello, Is there any interest in a class template which acts like a pointer and guarantees at compile time and at no CPU or memory cost (except when a call to any of its methods is not inlined) that the pointer is not null? One of the applications that I have found for this template is in defensive programming to eliminate the chances that dereferencing a pointer will result in undefined behaviour (when the pointer is null). Using this template is superior to any alternative method (that I know) to achieve the same result, since: (*) it consumes no CPU (in contrast to null checks); (*) the class template instances are copy constructible and copy assignable (in contrast to references which can also be used to guarantee unnullability); (*) it is natively supported by the language and provides a 'real' guarantee (in contrast to 'design by contract'); (*) supports the natural syntax for access to the wrapped resource (in constrast to boost::ref). Regards, Angel Tsankov

13 35

[shifted_ptr] STL support works at 90% (...!)
by Phil Bouchard 02 Aug '08

02 Aug '08

I've finalized the ad extremum idea of STL support of smart pointers such as shifted_ptr which is a good example to use because of the distinct types it is using as pointer types (T *, shifted<T> *, shifted_allocator::pointer, etc.). I have 2 patch files that can be used as an example to add support for real smart pointers using Gcc's STL. These are located in the bits/ folder. These are Gnu related but I wanted to share this here for objectivity. I have added special contructors in shifted_ptr that takes raw pointers (T *) instead of the type safe shifted<T> *. This is temporary until I add the proper casts inside the STL code. What else? I simplified shifted_allocator and fixed abominable bugs in shifted_ptr created by these temporary constructors added. Now I'm pretty dang happy about it... There are still some I need to fix and some more are yet to be found but it should be much easier now. Once again I am using shifted_ptr_test2.cpp as my main test application. Later, -Phil

1 2

Possible library submissions: fuzzy logic library, new container
by Alex Shafir 01 Aug '08

01 Aug '08

I am trying to determine if there might be any interest in a couple of possible library submissions. Both ideas were very useful and instrumental for many C++ development projects that I was doing for the last years. The fuzzy logic library is a simple, pure C++, optimized for speed, practical implementation of the fuzzy logic calculations that DOES NOT attempts to comply with the FCL(Fuzzy Control Language) standard (like IEC 1131). It CANNOT load FCL files. Instead similar to the Boost Spirit framework it provides a syntax that enables fuzzy logic rules to be written exclusively in C++. Compiled fuzzy model specifications are immediately executable. A snippet of what this syntax currently looks like is at the end of this message. The other idea is the “sparse array” container. Working for securities trading industry I used it innumerable number of times. It is useful in situations where there is a set of entities identified by integer(unsigned) numbers. Most often the numbers are identity keys in a database, a protocol field ids, etc. The potential range of the numbers makes it impractical to use a C++ array or the STL <vector>. On the other hand the average percentage of the keys that are really used in an application relative to the potential range is often less then 5% and there are huge holes of unused keys between zero and max(used key). The data elements or pointers to objects are kept in a structure similar to a balanced B-tree. Elements are directly accessed by an index operator. Access involves only a few arithmetic and redirection operations. When storing a new element that is outside of the range provided by exiting data structure the structure bilds itself up extending the indes range enough to accommodate a new index value. Existing data are never physically moved like in the STL vector. So, all references/pointers/iterators referencing existing elements are never invalidated. Feel free to comment. Fuzzy model syntax sample: ======================================== #include "TestModel.h" using namespace Fuzzy; // test model definition TestModel::TestModel(string file): Model(file), angle(-1), velocity(-1), speed(-1) { // fuzzy variables definitions created by the base class (Fuzzy::Model) // Input/Output methods; Input/Output arguments are refs // to double scalar variables Var& Angle = Input(angle); Var& Vlcty = Input(velocity); Var& Speed = Output(speed); // membership functions definitions created by fuzzy variables // Term method; Term method takes curve name as an argument; // cureve names are defined in the Fuzzy::Model curve definition // file MemFun& AngleNegHigh = Angle.Term("AngleNegHigh"); MemFun& AngleNegLow = Angle.Term("AngleNegLow"); MemFun& AngleZero = Angle.Term("AngleZero"); MemFun& AnglePosLow = Angle.Term("AnglePosLow"); MemFun& AnglePosHigh = Angle.Term("AnglePosHigh"); MemFun& VlctyNegHigh = Vlcty.Term("VelocityNegHigh"); MemFun& VlctyNegLow = Vlcty.Term("VelocityNegLow"); MemFun& VlctyZero = Vlcty.Term("VelocityZero"); MemFun& VlctyPosLow = Vlcty.Term("VelocityPosLow"); MemFun& VlctyPosHigh = Vlcty.Term("VelocityPosHigh"); MemFun& SpeedNegHigh = Speed.Term("AngleNegHigh"); MemFun& SpeedNegLow = Speed.Term("AngleNegLow"); MemFun& SpeedZero = Speed.Term("AngleZero"); MemFun& SpeedPosLow = Speed.Term("AnglePosLow"); MemFun& SpeedPosHigh = Speed.Term("AnglePosHigh"); // these are the model rules; syntax is pretty strightforward; // rules look like operator >> where lhs is the condition and // rhs is the conclusion; // lhs and rhs have to be in parens if they contain more then // one term because of the c++ operators precedence rules; // conclusion may be a comma separated list of output terms // in parens ((AngleZero and VlctyZero)or(AnglePosLow and VlctyNegLow)or(AngleNegLow and VlctyPosLow)) >> SpeedZero; ((AngleZero and VlctyNegLow)or(AngleNegLow and VlctyZero)) >> SpeedNegLow; ((AnglePosLow and VlctyZero)or(AngleZero and VlctyPosLow)) >> SpeedPosLow; ((AngleZero and VlctyNegHigh)or(AngleNegHigh and VlctyZero)) >> SpeedNegHigh; ((AnglePosHigh and VlctyZero)or(AngleZero and VlctyPosHigh)) >> SpeedPosHigh; } TestModel::~TestModel() { } void TestModel::run(double a, double v, double &s) { // we assign scalar variables to class members angle = a; velocity = v; speed = s; // then run the model // it should be pretty fast as it all designed to preallocate // all the needed large objects in the model constructor Model::run(); // and assign the values of output variables s = speed; }

3 2

dll-path feature
by brook＠biology.nmsu.edu 01 Aug '08

01 Aug '08

It seems that I need to use the dll-path feature to add an -rpath directive to the linker when my boost libraries are installed. This seems to be described (mostly) fairly clearly at http://www.boost.org/boost-build2/doc/html/bbv2/faq/dll-path.html What is not clear is where the feature should be invoked. My attempt to modify Jamroot to add <dll-path> to the boost-install rule failed in the sense that not rpath information makes it into the installed libraries. (The rest of this snippet is the original.). rule boost-install ( libraries * ) { package.install install : <dependency>/boost//install-headers $(install-requirements) : # No binaries : $(libraries) : # No headers, it's handled by the dependency ; install stage : $(libraries) : <location>$(BOOST_STAGE_LOCATE) <dll-path>/path/to/add/via/rpath ; local c = [ project.current ] ; local project-module = [ $(c).project-module ] ; module $(project-module) { explicit stage ; explicit install ; } } So, how is one supposed to invoke the <dll-path> feature in order to have -rpath added to the linking of libraries during their installation? Thanks for your help. Cheers, Brook

3 4

[1.36.0 beta] Bug fix procedures
by Beman Dawes 01 Aug '08

01 Aug '08

Bug reports from the beta are starting to surface on the user's list. Here is the procedure for dealing with them: * Apply the fix to the trunk. * Wait until enough regression tests have cycled to demonstrate that the fix worked and didn't break anything else. * Apply the fix to branches/release. * Keep an eye on the release test results to be sure there were no unintended consequences. In other words, there is no need to ask the release managers for permission to apply to branches/release as long as tests are clean. The whole point of doing a beta is to shake these user detected bugs out of the woodwork and apply the resulting fixes in time for the release. Thanks, --Beman

3 2

fixed-pt [improved]
by Neal Becker 01 Aug '08

01 Aug '08

Here is an improved version of fixed-pt, incorporating some of the suggestions given here:

5 4

[release] xpressive bug fix
by Eric Niebler 01 Aug '08

01 Aug '08

What are the chances that I'll be able to merge a bug fix to the release branch? This one: http://svn.boost.org/trac/boost/ticket/2157 just came in, and I've already fixed it on trunk. Assuming that the next cycle of the trunk tests don't show anything amiss, would I be permitted to merge the fix? The bug will not cause crashes, but it will lead to incorrect results when matching the end-of-line assertion ($) against internal line breaks, which is fairly common usage scenario. I have high confidence in the fix. These are the relevant changesets: http://svn.boost.org/trac/boost/changeset/47899 http://svn.boost.org/trac/boost/changeset/47901 -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 3