January 2009 - Boost - lists.preview.boost.org

[constrained-value] Some observations and questions.
by Jeroen N. Witmond [Bahco] 09 Feb '09

09 Feb '09

Greetings, Please forgive me for intruding on the Boost Development mailing list. I'm rather new to Boost, but I'm in love with it, because IMHO it shows C++ as it should be used. :) While browsing this mailing list, I came across the review announcement[1] for the Boost Constrained Value library[2]. I like the concept, so I downloaded[3] and installed the library. I also installed file boost/utility/swap.hpp from the sandbox. I had to hack the example program[4] to get around "[boost] [utility/swap] Ambiguous overload"[5]. To get familiar with Boost and the Boost Constrained Value library, I first rewrote the example program into a Boost.Test testcase[6]. (I have tried not to disturb the documentation generated from this file, but I did not test this.) As testcase, it runs succesfully, with the hack mentioned above. (At least for me, Emacs has problems with font-lock-mode[7] on this file. The original example program does not demonstrate this problem.) In the section on Custom error policies in the example program, perhaps it should be explicitely stated that: - on entry into the error handler, constraint(new_value) will always be false. An error handler that neither changes the constraint, nor supplies a valid value can therefore throw unconditionally. - on entry into the error handler, constraint(value) will only be false during the construction of an object with an invalid value. If the error handler does not throw in this case, the library will raise signal SIGABRT (application abort requested). - the only case where the error handler can be empty is when the constraint always returns true, as in 'template <typename ValueType> class unconstrained'[8]. This code[9] illustrates these points. Next I was itching to create and more real-life use case for the Boost Constrained Value library, with special attention on improving error reporting. So I wrote four template classes[10], implementing non-positive, non-negative, positive and negative constraints over any integral type. (This code still can be improved in many ways.) These constrained integers can be declared like: positiveInteger<int> i; // Construction with value 0 would fail, BOOST_CHECK_EQUAL( i, 1 ); // so it is set to 1. They can used like teir base type. In case of constraint violations (e.g. 'i = 1;' for 'i' above), an exception is thrown, which derives from both std::logic_error and boost::exception. The std::logic_error::what() returns: Failed assert(1 <= 0); And from the boost::exception, the following information can be retrieved (slightly edited to fit the newsgroup): constrained-integer.hpp:168: In '[very long function name]': Failed assert(-1 > 0); constrained-integer.cpp:82: Constraint was defined here. See the first testcase in the Boost.Test testsuite[11] for the code that produced these messages from boost::exception. The remainder of the testsuite runs the four template classes both against fundamental types, and against classes that implement infinite precision integer arithmetic. This showed that I needed to implement 'bool operator == (const Integer & v) const' for these classes, but not for the fundamental types. As implementing this operator==() for fundamental types results in compiler errors, the implementation is present only when preprocessor symbol 'CLASS_TYPE' is defined. (My attempt to hack this in the Boost Constrained Value library source failed.) Note that no hackery is needed for the relational operators used in the constraints. Otherwise, the testsuite compiles correctly and runs almost as expected. It would appear that in the process I may have discovered a bug[12] in the mp_math library in the sandbox. One question I have is related to the requirement of the Constrained Value library that the constraint and error handler objects must be completely constructed before the constrained object is constructed. In these four template classes, I handle this by deriving my template type (e.g. nonPositiveInteger) from the constraint class and indirectly from the error handler class. The purpose is to allow these template types to be used as drop-in replacements for the types they constrain. In this context it appears to work, but I'm having second thoughts about its validity and advisability. Although it is not a Boost question, is there anybody who wants to comment? One thing that has gotten me completely stumped is deriving my own template class from constrained_value::unconstrained. Whatever I try, I get the weirdest of compiler error messages. See the bottom of [10] and [11] for my latest attempt in the section guarded by '#ifdef DO_UNCONSTRAINED'. I must be missing something obvious. Also all other comments will be appreciated. Regards, Jeroen. PS: All files referenced in this email and authored by me are released under the Boost Software License, Version 1.0[99]. Note however that this code is not of release quality. [ 1] http://lists.boost.org/Archives/boost/2008/12/145581.php [ 2] http://student.agh.edu.pl/~kawulak/constrained_value/index.html [ 3] http://rk.go.pl/f/constrained_value.zip [ 4] file libs/constrained_value/doc/src/examples.cpp in [3]. [ 5] http://lists.boost.org/Archives/boost/2007/10/128494.php [ 6] http://www.xs4all.nl/~jnw/boost/constrained-value/test-constrained-value.cpp [ 7] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510475 [ 8] file boost/constrained_value/unconstrained.hpp in [3]. [ 9] http://www.xs4all.nl/~jnw/boost/constrained-value/understanding-ignore.cpp [10] http://www.xs4all.nl/~jnw/boost/constrained-value/constrained-integer.hpp [11] http://www.xs4all.nl/~jnw/boost/constrained-value/constrained-integer.cpp [12] http://lists.boost.org/boost-users/2009/01/43824.php [99] http://www.boost.org/LICENSE_1_0.txt

2 1

[constrained] constrained_vector
by Neal Becker 09 Feb '09

09 Feb '09

I'm interested in something like constrained, but applied to a vector of values. The case I'm interested in is a homogeneous vector of bounded int values, with bounds set at runtime. It is trivial to have a vector<bounded<int> >, but this would not be space efficient in the case where the policies, bounds on all the values are the same. I'm thinking that maybe some parts of constrained (such as policies) could be reused, independent of the rest of constrained. Has anyone looked into the idea of constrained vector?

3 4

[1.38.0] beta 2 release candidate
by Beman Dawes 09 Feb '09

09 Feb '09

The beta 1 release candidate from earlier in the week had enough issues that I decided not to push it out to sourceforge. Most (all?) of those issues have been corrected, and a new release candidate is up at http://boost.cowic.de/rc/ If no showstoppers surface I plan to move this beta to sourceforge tomorrow (Friday) and announce it here, the users list, and the announce list. The final 1.38.0 release would then come about week later. There are pending bug fixes for Boost.Python and Boost.Asio that are not in the beta but Dave and Chris are planning to have ready for the final release. --Beman

10 28

[constrained_value] Review version
by Robert Kawulak 09 Feb '09

09 Feb '09

Hi all, I've made some minor changes to the Boost Constrained Value library: - reorganized the structure of header files, - renamed saturating/saturating_int into clipping/clipping_int, - using boost::swap where applicable (if you don't have it, you need to get it from http://svn.boost.org/svn/boost/branches/release/boost/utility/swap.hpp) - made no_constraint policy public, - now the stream operators are not defined if BOOST_NO_IOSFWD macro is defined, - fixed identifiers containing "__" (not allowed by C++), - fixed minor language errors in the docs. The library is ready for the formal review, which starts this monday (1.12). It is only missing the detailed regression tests, which will be added after the review. Currently the examples file (libs\constrained_value\doc\src\examples.cpp) can be used instead -- it uses most of the functionality of the library and should compile and run returning 0. As usually, the code and documentation can be downloaded here: http://rk.go.pl/f/constrained_value.zip The documentation is also available online here: http://rk.go.pl/r/constrained_value Any comments and problem reports for platforms that has not been tested yet are very welcome. Best regards, Robert Kawulak -=##############=- "I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones." - Albert Einstein

3 4

[constrained_value] serialization
by Neal Becker 09 Feb '09

09 Feb '09

constrained_value does not currently support serialization. 1. Should it be added to the lib? 2. What would be a suggested implementation?

3 5

[threadpool] new version - supporting future library (C++0x) from Anthony Williams
by k-oli＠gmx.de 09 Feb '09

09 Feb '09

Hello, I've uploaded a new version of boost.threadpool (v17) at http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost-…. It uses the future implementation of Anthony Williams (C++0x - available at http://www.justsoftwaresolutions.co.uk/files/n2561 future.hpp). Please save it as file 'future'. best regards, Oliver

3 10

[1.38] CMake support added to release branch?
by John Maddock 08 Feb '09

08 Feb '09

I see from the 1.38 news section that experimental CMake support has been added to the release: I thought we were going to have a review before this happened? John Maddock.

8 11

[format] please add operator String()
by Thorsten Ottosen 08 Feb '09

08 Feb '09

Hi, In code like this: std::string columns() const { return (boost::format("%7s, %7s, %7s, %7s") % "testCost" % "optimalEcr" % "efficiecyEcr" % "testCostEcr").str(); } it is very annoying to have to put () around the whole expression and then call .str() (Just imagine that we are creating a string on the fly to a function). Therefore I suggest that we add operator string_type() const { return str(); } to the interface of basic_format<>. Any comments? -Thorsten

7 8

Re: [boost] [date_time] Time zone improvements
by Rutger ter Borg 07 Feb '09

07 Feb '09

Jeff Garland wrote: > Very cool :-) One question -- is there a portable solution where a user > could deploy a files onto a Windows system or is it a Unix only solution? Portable, big endian binary files. The variant I'm proposing is also based on the POSIX standard http://www.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap08.html: "TZ This variable shall represent timezone information. The contents of the environment variable named TZ shall be used by the [snip] functions, and by various utilities, to override the default timezone. The value of TZ has one of the two forms (spaces inserted for clarity): :characters or: std offset dst offset, rule " The second variant is what's currently in Boost.Date_Time as Posix Time Zone, having a direct specification of the time zone. I'll be talking about the first variant, containing :characters. Although this is implementaiton specific, most POSIX-compatible systems have implemented the Zoneinfo database for this variant, e.g., Linux-based systems, many BSDs, Mac OS X, etc. The :characters point to any other zoneinfo-compatible binary file, either with an absolute or relative path. A natural step for changing Boost.Date_Time would be to make changes such that the Posix Time Zone supports both formats. I.e., variant 1) posix_time_zone( ":/etc/localtime" ); or posix_time_zone( ":/usr/share/zoneinfo/Europe/Amsterdam" ); variant 2) posix_time_zone( "EST-5EDT,M4.1.0,M10.5.0" ); I think both should work as it is from the same standard, and seems to be a natural and consistent starting point to look at changing the interface. Do you agree? > Actually, I believe the abstract timezone is able to support this, but > there > isn't a concrete implementation. It would be great to have the concrete > implementation to prove out the abstraction (obviously from the text below > you think there needs to be changes). As far as I can tell, the abstract time zone class currently is not able to represent variant 1): the abstract zone class is geared towards a single-lined definition of a time zone, whereas variant 1) may be regarded as a series of definitions, i.e., a map of < transition_time_point_in_utc, { gmt_offset, abbreviation, is_dst, ... } > looking up utc_to_local is a matter of doing a lower_bound search on the transition time points. The right-hand side of the map above is widely implemented with a struct called ttinfo. A proposal from my side would be to change the abstract time zone class in such way that it is able to represent both variants. The easiest approach here is probably to introduce the ttinfo structure, and make the current library working with that. variant 1): has a map of transition points, returns a (pointer to a) ttinfo structure. May hold more than 2 different ttinfo structures. variant 2): always has 2 ttinfo structures (std/dst). Uses dst-calculations/functions to lookup the transitions point, returns the right (pointer to a) ttinfo structure. What do you think? Cheers, Rutger

2 3

support for gcc hidden visibility in shared libraries
by Stjepan Rajko 06 Feb '09

06 Feb '09

Hello, Many (almost all?) linked boost libraries don't work as shared libraries when compiled with the -fvisibility=hidden switch on gcc version>=4. I am wondering whether there is interest in making them work under these circumstances, as it might not be too hard to do, and there seems to be some benefit to it. To my limited understanding, making a symbol visible in a shared library using, say, __attribute__ ((visibility("default"))) on gcc, is analogous to using __declspec(dllexport) on windows. Many boost libraries already use macros that apply __declspec(dllexport) on windows - so these macros could set to expand to __attribute__ ((visibility("default"))) on gcc. Even better, a boost-wide macro could be added to the config headers. More information on this can be found here: http://gcc.gnu.org/wiki/Visibility Just to note, I have very limited understanding of compiling/linking and I might not have a full grasp of everything involved here. Also, my only reason for thinking that -fvisibility=hidden should be supported is that for a long time now, I haven't been able to use boost shared libraries on my os x platform, and only now I realized that the reason for this is that I had stuck -fvisibility=hidden in my user-config.jam a long time ago to suppress some warnings. Nonetheless, it seems like there are benefits to supporting it that go beyond preventing people like me from accidentally shooting themselves in the foot. Kind regards, Stjepan

6 16