- Boost - lists.boost.org

Collection of Jamfiles for 3rd-parties?
by Mateusz Loskot 15 Mar '10

15 Mar '10

Hi, I'm wondering if would it make sense to have a directory in Sandbox or close where Jamfiles for various third-party programs and libraries could be maintained. I imagine it could make it easier to integrate various dependencies with Boost and Boost Sandbox libraries. For example, GIL makes use of libpng, libjpeg, libtiff, libz, gzip/bzip2 are used by others too. I found that HAIKU OS maintains collection of Boost Build enabled libraries: http://dev.haiku-os.org/browser/haiku/trunk/src/libs I'm not suggesting to do the same, but perhaps it would make sense to maintain Jamfiles only, so users can download them and refer to such libraries using symbolic targets. I'm curious of your comments? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

2 1

base class for boost::array
by Peter Myerscough-Jackopson 15 Mar '10

15 Mar '10

Dear all, In using boost::array I have felt the need to pass around boost::array's of an unknown size (unknown to the function receiving the array). I have therefore created an abstract base class for boost::array so that I can create a pointer to a common base class for arrays of different sizes. Essentially std::vector's of different sizes can be passed into a function with a fixed prototype, but because boost::array constructs a different type for each array size, a single fixed prototype cannot be described such that it can be called with different sizes of boost::array. In code I can write (toy functions) : double sumTotal(const std::vector<double>* values) { double result = 0 ; BOOST_FOREACH(double v, values) { result += v; } return result; } But I can't write: double sumTotal(const boost::array<double>* values) { double result = 0 ; BOOST_FOREACH(double v, values) { result += v; } return result; } Without the second function being a template function, i.e. I cannot provide a library that takes a boost::array<double>. With the attached base class, I could define a function that takes a boost::array_base<double>. Since, I think, the ability to allow boost::array to be used in this way is that it requires the use of virtual functions, I have written it so that the inheritance is optional. It is enabled with a #define before including array.hpp . Is this useful? (I am aware that I maybe could use a boost::range) Thanks for your time, Peter Ps. On my current compiler, swap and operator= could not be uncommented in the array_base class. PPs. This is my first post to boost dev, please be kind... J Dr Peter Myerscough-Jackopson - Senior Engineer Tel: +44 (0)23 8076 7808 Fax: +44 (0)23 8076 0602 Web: http://www.macltd.com/ <BLOCKED::http://www.macltd.com/> Email: peter.myerscough-jackopson(a)macltd.com <mailto:peter.myerscough-jackopson@macltd.com> MULTIPLE ACCESS COMMUNICATIONS LIMITED is a company registered in England at Delta House, The University of Southampton Science Park, Southampton, SO16 7NS, United Kingdom with Company Number 1979185 and VAT Number GB 411942866

5 4

[Boost.Locale] New Release
by Artyom 15 Mar '10

15 Mar '10

Hello Boost List! ================= I'm glad to introduce updated version of Boost.Locale library: This library was designed for Boost and created because of needs CppCMS framework. I'm looking forward to formal review and general inputs from Boost.Community. Documentation: http://cppcms.sourceforge.net/boost_locale/html/index.html Download: From: https://sourceforge.net/projects/cppcms/files/ File: https://sourceforge.net/projects/cppcms/files/boost_locale/boost_locale.zip… Boost.Locale is a library that brings high quality localization facilities in C++ way. It provides the natural glue between C++ locales framework, iostreams and powerful ICU library giving: * Correct case conversion, case folding and normalization * Collation including support of 4 Unicode collation levels. * Date, time, timezone and calendar manipulations, formatting and parsing including transparent support of calendars other then Gregorian. * Boundary analysis for characters, words, sentences and line-breaks. * Number formatting, spelling and parsing. * Monetary formatting and parsing. * Powerful message formatting including support plural forms, using GNU catalogs. * Character set conversion. * Transparent support of 8-bit character sets like Latin1. * Support of char, wchar_t and C++0x char16_t, char32_t strings and streams. New in this version: ==================== a. Fully redesigned break iterator interface b. Added date_time and calendar support that allow manipulating with dates over non-Gregorian calendars c. Implemented full set of unit-tests d. Added support of many platforms and compilers. e. Lots of bug fixes. f. Complete reference with Doxygen g. Many tutorial updates, thanks to Markus Raab inputs Tested compilers and platforms: =============================== - Compilers: - GCC 3.4, 4.1, 4.2, 4.3, 4.4 - Intel Compiler 11.0 - SunStudio 12 with STLPort - MSVC 2008 - Operating Systems: - Linux - FreeBSD - OpenSolaris - Windows XP - Windowns XP/Cygwin - ICU Versions: 3.6, 3.8, 4.2 Full list of tests: =================== - Linux: - Debian GNU/Linux 2.6.18, x86, GCC 4.1.2, ICU 3.6.1 - Debian GNU/Linux 2.6.26, x86_64, GCC 4.3.2, ICU 3.8.1 - Debian GNU/Linux 2.6.26, x86_64, GCC 4.4 -std=c++0x, ICU 3.8.1 (Some faults on char16_t/char32_t support) - Debian GNU/Linux 2.6.26, x86_64, Intel Compiler 11.0, ICU 3.8.1 - FreeBSD - FreeBSD 8.0, i386, GCC 4.2.1, ICU 3.8.1 - OpenSolaris: - SunOS OpenSolaris 5.11, i386; Sun Studio 12, with STLPort, ICU 4.2 - SunOS OpenSolaris 5.11, i386; GCC 3.4.3, ICU 4.2 - Windows XP/SP2 - Cygwin 1.5, GCC 3.4, ICU 3.8 - Cygwin 1.5, GCC 4.3, ICU 4.2 - Windows XP/SP2, Mingw/GCC 4.4, ICU 4.2 (Static build only) - Windows XP/SP2, MSVC9 (2008)

10 19

[iterator] Help needed understanding output_iterator requirements
by Thomas Klimpel 15 Mar '10

15 Mar '10

Dear iterator experts, Jesse Perla recently reported that boost::multi_array fails compilation for many basic tasks on MSVC 2010. I investigated the failures, because I had already investigated other failures on MSVC 2010 reported by Jesse Perla for boost::ublas. While I'm quite familiar with boost::ublas, I'm a complete novice with respect to boost::multi_array and boost::iterator. I could track the failures to a specific (intentional?) behavior of iterator_facade from Boost.Iterator (more specifically of facade_iterator_category.hpp): http://lists.boost.org/Archives/boost/2010/03/163039.php Thomas Klimpel wrote: > What effectively happens it that the iterator gets the category > "input_iterator", but std::copy wants to have an "output_iterator". I > think I understand why the iterator doesn't satisfies the requirement > of a "forward_iterator", but it's unclear to me why it didn't qualify > as an "output_iterator". There is an "input_output_iterator_tag" in > "boost/iterator/detail/facade_iterator_category.hpp", so it would have > been possible for the iterator to be both "input_iterator" and > "output_iterator". However, it seems to me that > "input_output_iterator_tag" is never used in the Boost.Iterator > library. I would have to read more about "output_iterator" to > understand whether Boost.Iterator is correct here. With my current > understanding of "output_iterator", I would say it's a bug in > "boost/iterator/detail/facade_iterator_category.hpp". > > Perhaps somebody with more knowledge about "output_iterator" and > Boost.Iterator can explain to me why an iterator using the > "boost::random_access_traversal_tag" for the "CategoryOrTraversal" > template parameter of "iterator_facade" will never get the category > "output_iterator" (or "input_output_iterator_tag"). Of course I could go on and read more about "output_iterator", or find out whether the Boost.Iterator documentation has to say something about this issue, but since I only came to this problem because I wanted to help Jesse Perla on a problem with boost::multi_array, I would much prefer if an "iterator expert" could "take over". Regards, Thomas

2 2

[log] Boost.Log formal review
by Vladimir Prus 15 Mar '10

15 Mar '10

Boosters, the formal review of the Boost.Log library, written by Andrey Semashev, starts now and will run through March 17, 2010. The documentation for the current version is available at: http://boost-log.sourceforge.net The downloads are at: http://sourceforge.net/projects/boost-log Here are the important points: 1. All comments are appreciated. Even if you don't have the time for in-depth study of everything, comments on parts of the library are welcome. In particular, if you are already using logging in your applications and have specialized requirements, you might want to directly check how the proposed library handles them. 2. The reviews and all comments should be submitted to the developers list, boost(a)lists.boost.org and the email should have "[log]" prefix in the subject to make sure it's not missed. The deadline for reviews is 23:59, March 17, PST = 2:59, March 18, EST = 7:59 March 18, GMT = 10:59, March 18 MSK 3. Please explicitly state in your review whether the library should be accepted. 4. The general review checklist is provided below: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Thanks, Volodya

16 52

Fwd: Re: [log] review part 1
by Andrey Semashev 15 Mar '10

15 Mar '10

Due to technical reasons this reply went off-list. For sake of keeping the conversation public, I'm reposting it. -------- Original Message -------- Subject: Re: [boost] [log] review part 1 Date: Sat, 13 Mar 2010 16:08:14 +0300 From: Andrey Semashev <andrey.semashev(a)gmail.com> To: Steven Watanabe <watanabesj(a)gmail.com> On 03/12/2010 07:22 AM, Steven Watanabe wrote: > I mostly have documentation notes at this point. Andrey, since I have so > many, and they're mostly fairly minor, would it be better if I made > a patch for the documentation source? Yes, that would be great. I quickly reviewed your suggestions, and they all look reasonable (I always have a hard time with articles). Thanks! > I think newbies should probably be replace globally with new users, > since I kind of feel that the term newbie is somewhat derogatory. Ok. I didn't mean to offend anyone, of course. :) > http://boost-log.sourceforge.net/libs/log/doc/html/log/defs.html > ================================================================================ > > For Log record: > I don't like the expression "A single pack of information," although > I can't think of anything better off hand. A collection of data,...? > ================================================================================ > > Issues: > > Instead of compiling a narrow or wide library, why don't you use > libboost_log > and libboost_wlog? There are parts that would be the same in both these libraries. Most notably, singletons of file_collector repository and some constants. This might lead to linking problems if someone tries to use both versions of the library. > I agree with other comments that I saw about Attribute being > a poor choice for what it does. I would prefer that the term "Attribute" > should be used for what you call an "Attribute Value," and that > there should be a different term, like "Attribute Extractor" for > what you call an "Attribute." My understanding of the term "attribute" is that it's some kind of meta-information that defines the concrete values that will be attached to log records. I'm ready to agree that the word "attribute" doesn't bring my intention precisely, but the alternatives don't quite get closer. "Extractors" are reserved for another tool in the library.

5 6

static in_class constants
by Christian Henning 15 Mar '10

15 Mar '10

Hi there, I'm finishing up some linker problems I have with gcc. One area of problems seems to be static in_class constants that I have declared in my header file. MSVC doesn't have problem with it but gcc is complaining. I'm wondering how other libs in boost are dealing with these problems. For instance in my new gil::io lib I define some tags in pnm_tags.hpp as follows: /// Defines type for image type property. struct pnm_image_type : property_base< uint32_t > { BOOST_STATIC_CONSTANT( type, _mono_asc = 1 ); // Monochrome ASCII encoding BOOST_STATIC_CONSTANT( type, _gray_asc = 2 ); // Gray level ASCII encoding BOOST_STATIC_CONSTANT( type, _color_asc = 3 ); // sRGB color ASCII encoding BOOST_STATIC_CONSTANT( type, _mono_bin = 4 ); // Monochrome binary encoding BOOST_STATIC_CONSTANT( type, _gray_bin = 5 ); // Gray level binary encoding BOOST_STATIC_CONSTANT( type, _color_bin = 6 ); // sRGB color binary encoding }; Thanks, Christian

7 27

Review - boost::log
by Tom Brinkman 15 Mar '10

15 Mar '10

Should boost log be accepted into the boost library? My vote is no. This library will just reinforce boost's reputation as being a repository of needlessly complicated highly templatized libraries for relatively easy programming tasks. I don't mind this added complexity when it comes to genuinely difficult problem spaces. In my view, however, logging is not one of those problem spaces. Logging is one of those things that if it takes longer than 10 minutes to read the documentation and get up to speed, it will not get used. What is your evaluation of the design? Very much in the spirit of a typical boost library. However, it has very little attention to "C" interfaces and makes heavy use of templates. I suppose because this is boost, that that is acceptable. However, boost and the c++ community at large should start moving towards a more friendly attitude towards a "C" style api for utility libraries. Most non-boost c++ developers will dismiss this library out of hand, not because its a bad library, its not, it's just more of the same. Heavy handed use of templates. I guess I've spent too much time over the last 5 years ripping out poorly conceived heavily templated code. The thought of adding to this madness, with another utility library that is burdened by templates is hard to swallow. What is your evaluation of the documentation? Good What is your evaluation of the potential usefulness of the library? Logging is useful. Yes. Did you try to use the library? With what compiler? Did you have any problems? Yes. GCC++. No problems How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 2 hours Are you knowledgeable about the problem domain? Yes. I was the review wizard for three years and have followed the progression of boost from the beginning, Tom Brinkman

10 23

Re: [boost] suggestion on assertion macros
by Andrzej Krzemienski 15 Mar '10

15 Mar '10

> there were a discussion recentrly about verifying arguments of > assertion macros while checks are turned off > i've got an idea of how to check the argument(s) and guarantee zero > code size and runtime overhead Hi, This is a good addition to assertions, but once we decide that we are improving assertions, there is much more that needs an improvement. Most of them are listed in the thread on Contract++ library (proposed for Boost) that you are already referring to. But let me list the potential improvements here. 1. If the expression in assertion throws an exxception, this should also be considered an assertion failure. Otherwise evaluating or not evaluating an assertion may render different program behavior. You can implement that by wrapping the expression with a try-catch block; but then assertion is a statement rather than an expression. Personally I think it is even better that an assert in a statement and it cannot be a subexpression of a bigger expression, but it no longer complies to assertion interface. Lambdas have the capability of changing statements into expressions, but we do not have them yet. 2. Be able to disable some assertions, but not all, e.g. I want the following assert in my code never to execute: assert<low_level>( is_sorted( v.begin(), v.end() ) ); find_logarithmic( v.begin(), v.end(), val ); Simply because it may be too slow even in debug. 3. I may want to disable even syntax checking in order for my compilation to run faster. I guess we should also consider user that prefer slower applications that compile faster 4. Make sure that the expression does not access any global variables. Well, we shouldn't really forbid that but give it as an option for the programmers that like "functional style" programming. I don't know how to do that now, but with lambdas, I believe it is posible with empty capture lists. 5. At least try to limit the possibility of the expression having any side effect. Contract++ ttries to do it by enforcing the const correctness of some inputs. Perhaps, even the old assert is left alone and some super-assert like the one from Concept++ should be incorporated into Boost and be the preferred way of veryfing user assumptions. Regards, &rzej

6 11

[iostreams] Add char_traits to the Device concept
by thomas weidner 14 Mar '10

14 Mar '10

Hi, i came across this issue when trying to use iostreams with a custom character class and custom character traits. The main problem is, that iostreams assumes std::streampos as the position type for all devices. Some parts of iostreams, like detail::indirect_streambuf honor the char traits' custom pos_type, but this will cause build failures as the underlying device (even code_converter) uses std::streampos as position type. My proposal is to add an associated character traits type to a Device. A Device type whould therefore not only provide information about the underlying character type, but also about the used pos_type, off_type and code conversion (not) done. I would even use traits different from std::char_traits<Ch>/iostreams::char_traits<Ch> as default character traits for most devices. Most devices like for example file_descriptor_sink don't do any code conversion, so a pos_type which contains a mbstate_t is useless and leaves the user with the impression, that code conversion *is* done. A simple integral type like C's off_t should do fine. Let's call those traits binary_char_traits for now. As an implication of this a iostreams::stream_buffer<file_descriptor_sink> should use the Device's char traits type, so should be a std::basic_streambuf<char, binary_char_traits<char> >. Especially it whould not be useable with std::iostream. This is IMO a nice and very clean result, as an iostream expects characters on which code conversion has been performed. You whould need to plug a code_converter in between. Some thoughts about iostreams::code_converter. Perhaps we should change the Codecvt template parameter to a second traits type. This traits type will become the code_converter's associated char traits type. the codecvt type could be an extra template parameter or is simply std::codecvt<code_converter_char_type, underlying_device_char_type, codecvt, code_converter_traits_state_type>. this whould be the same mechanism as code conversion in the stdlib works (using std::codecvt specialization). Comments to my thoughts are very welcome. --- Thomas

1 0