- Boost - lists.boost.org

[Preprocessor] Can we generate token for #include programmatically ?
by Joel Falcou 15 May '09

15 May '09

Here is what I had in mind #define BASE foo.hpp #include BOOST_PP_STRINGIZE(BOOST_PP_CAT(nt2/support/numeric/functions/scalar/,BASE)) It fails because it seems we can't paste stuff ending with / ... Using fiel iteration, how can I circumvent hsi problem and generate a list of #include whose filename are computed from a sequence of name in a BOOST_PP_SEQ and a given, changing, prefix path ?

2 6

Re: [boost] [rfc] Unicode GSoC project
by Graham 15 May '09

15 May '09

Dear Eric/ Mathias, >That's good, these are needed. Also needed are tables that store the various >character properties, and (hopefully) some parsers that build the tables >directly from the Unicode character database so we can easily rev it >whenever the database changes. A good reloadable character library is in the vault. >And UnicodeGrapheme concept doesn't make sense to me. You say, "A model of >UnicodeGrapheme is a range of Unicode code points that is a single grapheme >cluster in Normalized Form C." A grapheme cluster != Unicode code point. It >may be many code points representing a base character an many zero-width >combining characters. So what exactly is being traversed by a >UnicodeGrapheme range? >It is thus important to be able to apply algorithms with graphemes as the >unit rather than code points to deal with graphemes not representable by a >single code point. I think that a grapheme is more of an iterator concept than a data type concept. By specialising it you will unnecessarily complicate any library. Don't forget that, for example, the current grapheme may start as one character, then suddenly 'grab' the surrounding characters as it makes a combined glyph. I have never found a use case in practise where specialising the grapheme as other than a validated series of code points was helpful. The two cases where graphemes are important is in display [which requires intermediate glyph conversion anyway, and works just as well on runs of code points, so code points are fine] and in editing - and the grapheme-ness here alters during typing. >The Unicode standard also specifies various features such as a collation >algorithm in Technical Standard #10 - Unicode Collation Algorithm for >comparison and ordering of strings with a locale-specific criterion, as >well as mechanisms to iterate over words, sentences and lines Have a look at the character library that I posted in the vault - if you can do graphemes then you can do words, paragraphs etc as they are all just attributes of the characters with simple rules. Graphemes come in to their own for text display and editing and you would need these as well to be able to support that. Don't forget that windows GDI only supports point arithmetic and this means that you need to be able to locate word boundaries to display text well at different scales to work around the GDI scaling rounding [and GDI+ is not much better].

2 1

[1.39.0] Beta candidate
by Beman Dawes 15 May '09

15 May '09

The beta candidate files are up at http://boost.cowic.de/rc/ Before pushing these out to SourceForge, it would be great if a few Boosters could download and try them out as a final QA check. Post your experiences here. Thanks, --Beman

9 24

Review Request: Algorithm.Sorting
by Steven Ross 15 May '09

15 May '09

I have uploaded algorithm_sorting.zip for a formal review to become Boost.Algorithm.Sorting, if people feel that is appropriate. It is 3 templated hybrid radix-based/comparison-based algorithms, specialized to sort certain types of data more efficiently. All 3 have superior worst-case and average-case performance to std::sort, based upon my testing. None of these algorithms use much additional memory. All of them can sort key + data, and as they do fewer swaps, tend to do so much faster than std::sort. As a general rule, the speedup of these algorithms relative to std::sort increases as data set size increases. These algorithms tend to be faster relative to std::sort when comparisons are slow, as they do less (or no) comparisons. string_sort, which sorts strings in O(n*length) time, as compared to O(n*length*log(n)) for pure comparison-based algorithms. It is consistently faster than std::sort in string sorting, by a little more than a factor of 2 based upon my testing. float_sort, which sorts IEEE floating-point numbers as integers, but attaining the same ordering as std::sort, with the exception of -0.0 and NaNs, both of which cannot be ordered based upon their comparison function. float_sort is roughly twice as fast as std::sort on UNIX-type OSes I've tested on, and roughly 7X as fast on Windows. I believe this speedup to be because floating-point comparisons are slow on Windows. integer_sort, which sorts integers around 60% faster than std::sort on UNIX-type OSes, and 25% faster on Windows. On Windows with MSVC, std::sort sorts already-sorted and small range data extremely quickly, and integer_sort processes already-sorted data slower than it by as much as a factor of 3X. I believe this to be due to some optimization for already-sorted data, as integer_sort takes substantially less absolute time on already-sorted data than unsorted data. So integer_sort on Windows has a tradeoff: better worst-case and average-case performance, but worse best-case performance. integer_sort and float_sort share some tuning parameters. I have set values that seem to work well on both UNIX-type and Windows OSes, but people are welcome to try to see what values are best for their system and problem type. The ideal values for integers and floats may be different on some systems (such as Windows), but for simplicity they are kept the same. A tuning/testing script named tune.pl is included, for those who wish to see how fast these algorithms are on their system (and verify correctness). I don't recommend using it for tuning without the -large option, and that takes days. If you do use it for tuning, I also recommend the -verbose option, to see what it's doing.

6 19

[exception] current_exception mishandling standard exceptions
by Adam Badura 14 May '09

14 May '09

It seems that current_exception mishandles standard exceptions. I noted two problems: 1) Some standard exceptions are not handled at all. This includes std::runtime_error and its derived (std::overflow_error, std::range_error, std::underflow_error), std::domain_error (handled by general std::logic_error), std::length_error (handled by general std::logic_error) and std::ios_base::failure (handled by general std::exception). Why is it so? 2) Non-standard exceptions derived from standard exceptions are sliced by current_exception. It detects those types by throwing and caching and thus will catch also derived types (like null_pointer : public std::invalid_argument). But during construction of internal structures the standard exception type is used and thus copy construction slices the original exception object. If typeid was used instead of throwing/catching (or dynamic_cast) to detect the type current_exception could at least detect that is will slice the original object and use a different type so it would not pretend everything is OK. Adam Badura

3 6

[property_tree] XML parser broken in 1.39.0
by Boris Schaeling 14 May '09

14 May '09

Calling boost::property_tree::xml_parser::read_xml() to parse a XML file and populate a property_tree doesn't work anymore in Boost 1.39.0 (at least not in Visual C++ 2008). The compiler error I see is: boost\iterator\iterator_adaptor.hpp(230) : error C2027: use of undefined type 'boost::STATIC_ASSERTION_FAILURE<x>' with [ x=false ] The property_tree headers include boost\spirit\home\classic\iterator\position_iterator.hpp which includes boost\iterator\iterator_adaptor.hpp. I also see this warning: Warning: This header is deprecated. Please use: boost/spirit/include/classic.hpp Warning: This header is deprecated. Please use: boost/spirit/include/classic_position_iterator.hpp It looks like as if a change in Boost.Spirit or Boost.Iterator broke the XML parser. Does Boost.PropertyTree have a maintainer who can look into this? Boris PS: As it turns out it's broken in Boost 1.38.0, too. With 1.36.0 I don't get a compile error (1.37.0 I don't have installed and can't test).

3 5

Re: [boost] [rfc] Unicode GSoC project
by Graham 14 May '09

14 May '09

> 1. The vast majority of characters (by frequency of use) are > on the BMP. > 2. For seamless integration with the majority of existing > software with good Unicode support. > >I don't find either of those claims very convincing. I hope that your >library will not try to make UTF-16 some sort of default encoding, or >otherwise give it special treatment. Phil, I think each application needs to be assessed on its own merits. For example: For data storage on mainly ASCII text I use UTF-8. For text manipulation I often use UTF-16. For a Unicode text editor I use UTF-32. There is not a one size fits all. Yours, Graham

1 0

New version of C++ Middleware Writer now on line
by Brian Wood 14 May '09

14 May '09

Shalom Version 1.9 of the C++ Middleware Writer is now available. This version adds support for Boost Array and it also has a command line interface that allows users to bypass the web interface. In other words, it makes it easy to integrate the C++ Middleware Writer into your build process. http://webEbenezer.net/build_integration.html<http://webebenezer.net/build_integration.html> -- Brian Wood Ebenezer Enterprises http://www.webEbenezer.net <http://www.webebenezer.net/>

1 0

Binary compatibility of boost releases. Is there such a thing at all?
by Alexander Churanov 14 May '09

14 May '09

Hi folks! I am working on boost port for FreeBSD. At present I am investigating into versioning of shared libraries. Historically, versions of boost shared libraries on FreeBSD do not match boost release version. Some FreeBSD folks beleive that application should not be recompiled just because the boost was updated, say from 1.37 to 1.39 and that shared library version for 1.39 may stay the same as it was for 1.37. I'm afraid it's not correct. I've read that there is no binary compatibility for boost shared libraries from different releases, and that application must use exactly the same library it was compiled for. However, these documents are of 2003-2004. Here is the question: What is the actual status of binary compatibility for boost? Alexander Churanov, maintainer of devel/boost

3 3

[future] usage question for new accepted library
by Alan Patterson 14 May '09

14 May '09

Hi, I see Anthony William's future implementation has been accepted over Braddock Gaskill's. I have been using Braddocks implementation and in particular a couple of features which I believe are not in Anthony's implementation. So I am looking for some pointers for how I might do the following with the accepted futures implementation. 1) Using the implicit cast of future<T> to T. I have an application where I can submit jobs to a scheduler, have them executed and provide me with a return value. My scheduler uses a policy for implementation: scheduler<single_threaded_policy> scheduler<threadpool_policy> The user submits a task and gets the result like result_type r = scheduler.submit(some_task()); where result_type is obtained from the scheduler and can either be of type T for single_threaded or future<T> for threadpools. Either way the client doesn't care which, because he can use a T or future<T> identically IF future<T> casts to T. I like this because the client never knows anything about futures, he treats all result_types as type T. I guess the way to do this with the accepted future implementation is to create a template function that does the following: T actual_r = get<result_type>(r); which call get() if it is a future or just returns r if not. But this is no where near as nice IMHO. The user no longer just uses the result_type of his task directly for what seems to be a basic type. 2) callbacks when future is set I have a usage scenario where I submit a batch of tasks where I collect results until I either have the result I want or collect enough that I can return what I have. This is neither a wait_for_any or a wait_for_all, more a kind of wait_until_i_have_enough. I currently implement this by submitting the batch of tasks and getting a batch of futures. I then register a callback on each future that gets called as each future gets set. The callback collects results as they come in and can decide to bail out early if it has enough results. How would I go about implementing this usage with the new futures implementation? Thanks in advance and sorry for the long post. Alan

2 1