- Boost - lists.preview.boost.org

How to use ASIO without SSLv2?
by Steve M. Robbins 25 Apr '11

25 Apr '11

Hi, Debian just turned off SSL v2 support in openssl due to security concerns [1]. Unfortunately, this broke compilation of several ASIO-using programs such as pion-net [2] and witty [3]. These programs all fail to compile with the following diagnostics: > In file included from /usr/include/boost/asio/ssl/context_service.hpp:30:0, > from /usr/include/boost/asio/ssl/context.hpp:22, > from /usr/include/boost/asio/ssl.hpp:19, > from /build/user-witty_3.1.8-2-amd64-wHJ4Kv/witty-3.1.8/src/http/Server.h:22, > from /build/user-witty_3.1.8-2-amd64-wHJ4Kv/witty-3.1.8/src/http/HTTPStream.C:12: > /usr/include/boost/asio/ssl/detail/openssl_context_service.hpp: In member function 'void boost::asio::ssl::detail::openssl_context_service::create(SSL_CTX*&, boost::asio::ssl::context_base::method)': > /usr/include/boost/asio/ssl/detail/openssl_context_service.hpp:73:28: error: '::SSLv2_method' has not been declared > /usr/include/boost/asio/ssl/detail/openssl_context_service.hpp:76:28: error: '::SSLv2_client_method' has not been declared > /usr/include/boost/asio/ssl/detail/openssl_context_service.hpp:79:28: error: '::SSLv2_server_method' has not been declared What does one have to do in order to use ASIO without SSLv2 support? One suggestion [3] is to simply enclose the related code within #ifndef OPENSSL_NO_SSL2. In the cse of openssl_context_service::create(), however, placing this around the affected switch cases would result in executing the default case default: impl = ::SSL_CTX_new(0); break; Would this be safe to do? Are there other places in the code that need to be addressed? Thanks, -Steve [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589706 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621402 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622070

1 0

Re: [boost] [locale] Formal review of Boost.Locale library -- final days
by Artyom 24 Apr '11

24 Apr '11

> From: Gevorg Voskanyan <v_gevorg(a)yahoo.com> > Points I don't like most: > > - The boundary interface isn't attractive (in my opinion, shared by some other > > > reviewers) As it was common request that was shared by several reviewers I'll take a look on it. And I'll also take a look on regex like interface that may actually be relevant for this case. > - Operator overloading is sometimes used in unintuitive ways. For example > operator/ used to get the value for a specific period type > I'll also update a little date_time the interface to be consistent with other boost libraries, for example to get year(t) t=year(1990); In addition or instead of t = year * 1990 t / year > [snip] > > I noticed lack of exception safety in some places and places where RAII > should have been used. The implementation might benefit from a careful > examination intended to find and fix such kind of problems. I've seen several places that were pointed by reviewers and I had seem some problems with copy constructors in the code so I'll review them. > I also think that > dynamic memory management is used too freely - in many cases their usage is > unavoidable but in some cases they are. Having said that I appreciate that >some > > efforts have already been put in that direction: I noticed several places >where > > fixed-size buffers were used if data is small enough and dynamic allocation if > > > it's larger. > > More details at http://permalink.gmane.org/gmane.comp.lib.boost.devel/218352 > Noted. > > - What is your evaluation of the documentation? > > The documentation structure is good. It enables a new user to get started with > > > the library quickly. The well-organized references help to find documentation > for a specific facility in almost no time. I would however like to see more > links within the text of the pages. There are many spelling and grammar issues > > > in the documentation. Many of them have been already addressed to some extent >by > > me and other reviewers, but it feels like there are still more of them left > there. I agree that the documentation should be thoroughly scanned for such > language issues by a native English speaker. > I also think there should be more examples. > > More details at http://permalink.gmane.org/gmane.comp.lib.boost.devel/218117 >and > > http://permalink.gmane.org/gmane.comp.lib.boost.devel/218343 > I'll do my best, hopefully after third language review you did it would be much better. > > - What is your evaluation of the potential usefulness of the library? > > Very useful. > > > - Did you try to use the library? With what compiler? Did you have any > > problems? > > I have played with the library using number/ordinal formatting, date >formatting, > > currency formatting, spellout, case conversion and boundary analysis features. > >I > > have not used encoding conversion, normalization, timezone/calendar, (message) > > > formatting and collation features. I have used ICU backend only. > > Environment: > FreeBSD 8.0 > g++ 4.5.0 in C++03 mode > ICU 3.8.1 system-wide installation > > What I used was intuitive and easy, except for boundary analysis as noted >above. > > I had some incorrect results most of which I believe are ICU issues. > Some which I'm not so sure about though: > - output of as::local_time was wrong by 2 hours; as::gmt was correct. >Moreover, > > as::date printed the yesterday's date when the local time was 2:24 AM ! > /bin/date shows correct local time, so I believe my system time zone settings > are fine. This is problem with older ICU versions. ICU had included several bugs in the local time zone detection. I assume that the test test_icu_of_os_timezone fails. I've seen things things on FreeBSD: http://art-blog.no-ip.info/files/nightly-build-report.html (Even it is not tested under Boost namespace it still catches the problems) What you need is latest ICU. It had several fixes of timezone detection in 4.6 and this version works fine and passes all the tests. So I recommend you to use it with ICU 4.6 on FreeBSD. There is a some workaround I implemented for Linux for other problem of detecting timezone as "localtime" but it seems that on FreeBSD it is other issue as it has little bit different timezone handling. > - "Note: not all locales provide rules for spelling numbers. In such a case >the > > number would be displayed in decimal format." This was not the case: > std::cout << as::spellout << 117 << std::endl; printed "one hundred and > seventeen" under hy_AM.UTF-8 locale. I'll take a look on this, it may be either CLDR issue or ICU mis-detecting hy_AM locale. > > There were loads of "comma at end of enumerator list" warnings. > > > - How much effort did you put into your evaluation? A glance? A quick > > reading? In-depth study? > > Closer to in-depth study with more than 25 hours invested. > > > - Are you knowledgeable about the problem domain? > > I am well aware of localization problems and approaches that can be used to > tackle them. I have developed in-house solutions to address some localization > needs on as-necessary basis. > > > And finally, every review should answer this question: > > > > - Do you think the library should be accepted as a Boost library? > > Yes. Thank you very much for the review. Artyom

2 1

Re: [boost] [locale] Review results for Boost.Locale library
by Brent Spillner 24 Apr '11

24 Apr '11

On 24 Apr 2011 14:06 Ryou Ezoe wrote: >Believe me, There are so many Boost users who don't know English at all. >They are good at using Boost library because there are enough translations. And why would this library, designed to support international users, be any different? >This English-dependent library cannot be used by these users. >They CAN use English identifier in the source file. like name of >functions, classes, variables etc(badly If you ask me) >But text is written in their language. >There is no way they use English text. >The text in software is not just written by programmer alone. >Non-programmers also write text. >So this library requires English for anybody. What are you proposing, a library where the identifiers and keys are all in Japanese? Esperanto? Perhaps all comments should be replicated in the ~20 most commonly-used languages so that non-English speakers can not just use the library, but also contribute? Artyom has created an internationalization library, not the magic translator box from Star Trek. >That means, if everybody can use this English-dependent library, the >purpose of this library, the localization, is unnecessary. If non-English speakers can't use English-centric internationalization tools, where are the competitors for gettext and ICU? >Blaming people for not to use English doesn't work. They don't care. >Just like you don't care their language. For someone who purportedly doesn't care about non-English speakers, Artyom certainly went to a lot of trouble to create an internationalization library. I'm sure we'd all agree that it's unfortunate that some familiarity with English is a requirement to use almost any programming language, library, or toolchain, which is an additional burden for the millions of non-native-English-speaking programmers and aspiring programmers out there. But that's due to a confluence of historical, economic, and compatibility reasons, and has nothing to do with this library. In fact, by making internationalization easier, Boost.Locale will over time likely /increase/ the number of software tools that people can use in their native languages. Your criticism is entirely misplaced. Brent

1 0

[gil new_io] tiff alpha channel support
by Erik Hvatum 24 Apr '11

24 Apr '11

Briefly: gil new_io does not support tiff alpha channel. Is support planned? If not, I'll attempt to add it and submit a patch if successful. Details: I am using the latest code from the gil-contributions googlecode SVN repository. The following causes a crash when "tifffile.tif" is interleaved 32-bit rgba (ie 8*4 bits, including the alpha channel): argb8_image_t image; read_and_convert_image("tifffile.tif", image, tiff_tag()); If "tifffile.tif" is planar instead of interleaved, no crash occurs. However, the image is not loaded correctly - all channels are filled with the same values, causing the image to apparently be grayscale. "tifffile.tif" stored without an alpha channel loads correctly, but the alpha channel is essential for my application. Around line 237 of io_new/formats/tiff/read.hpp, I see that we are reading into an rgb8_view_t for 8 bit per sample images, so we're obviously not going to retain alpha channel data even if it is read correctly. Additionally, TIFFTAG_SAMPLES_PER_PIXEL is read but not respected. To avoid crashes for tiff images with extra channels, row_buffer_helper must be aware of TIFFTAG_SAMPLES_PER_PIXEL. So that the alpha channel is retained for RGBA images, in the PHOTOMETRIC_RGB case near line 237, if TIFFTAG_SAMPLES_PER_PIXEL is 4, we should read into an rgba*_view_t.

3 4

[FunctionTypes] Can FunctionTypes be extended to work with Boost.Function?
by Mostafa 23 Apr '11

23 Apr '11

This is a request to have FunctionTypes extended to work with Boost.Function. According the current documentation, it does not handle the latter. Rationale: I have a template parameter that can be either a function type or a boost::function, and I would like a uniform method to decompose their signature and return type. Note: an alternative does exist where one to specialize on boost::function and carry out around its underlying signature, but that's just an annoying hassle, and, more importantly, it doesn't work if old style syntax for boost::function is used. Thanks, Mostafa

1 0

[locale] Review of the proposed Boost.Locale library
by Matus Chochlik 23 Apr '11

23 Apr '11

Hi all, this is my review of the proposed Boost.Locale library: DISCLAIMER: I'm pretty familiar with the issues of application localization for the Central/East European region mainly with Slavic languages, mostly those using Latin characters, (Slovak, Czech, Polish), also a little bit with languages using some variant of Cyrillic characters (Russian, Bulgarian) and with West European languages like German, i.e. languages having somewhat different capitalization and collation rules than English has, some of which have also multiple plural forms in certain inflection cases. But I have no experience whatsoever with localization in other environments: Middle-East, Asian, etc. so I might have missed some important issues arising in such cases. - Please explicitly state in your review whether the library should be accepted. Yes, it should be accepted. The general review checklist: - What is your evaluation of the design? Straightforward and easy to use, similar to other localization libraries I've worked with. - What is your evaluation of the implementation? Since most of the problems I've spotted (and many more) were already addressed in Steven's very thorough review of the code and in other reviews I'm not going to reiterate them. AFAIK the Boost Coding Guidelines require max 80 characters per line in the source code. The sources of Boost.Locale do not follow this guideline which makes them slightly less readable, one needs to scroll a lot horizontally. Otherwise I leave the quality of the implementation to be judged by more competent people on this list. Concerning the external dependencies, ICU, tools from GNU gettext (msgfmt, ...), etc.: I don't think that it would be a good idea to re-implement them. A lot of effort has been put into their development, they are well supported, maintained and available for every major platform so I don't see any advantage in reinventing the wheel. - What is your evaluation of the documentation? The documentation is readable and clear to someone familiar with l10n/i18n however things like collation, capitalization, case folding, etc. should be better explained for users who are not familiar with them. The previous/next page links are missing which is little inconvenient. In the Message Formatting/Message Translation section there is a typo: ------------------------------------------------------------------------------ std::cout << boost::locale::tanslate("Hello World!") << std::endl; ------------------------------------------------------------------------------ In the examples and code snippets in the docs I think that "using namespace std;" should be removed and instead of "using namespace boost::locale;" there should be something like "namespace bl = boost::locale;" which would make much clearer which parts of the sample code are referring to Boost.Locale's code and which to std library; Also (but I might be mistaken here since I'm not a native German speaker) the example in the "Conversions" section names a variable 'gruben' (this variable stores the word "grüßen") a German would probably call this variable 'grussen' since 'ß' != 'b'. - What is your evaluation of the potential usefulness of the library? This library is very useful for people working on portable applications that are to be localized for non-English environments. - Did you try to use the library? With what compiler? Did you have any problems? Yes (I built the library), - on Debian Linux (64bit) with ICU 4.6 - using cmake - with GCC 4.6.0 non-C++0x mode: no problems - with GCC 4.6.0 C++0x mode: auto_ptr - related warnings - using bjam (Boost 1.46.1) - with GCC 4.6.0 non-C++0x mode: no problems - on Windows Vista Basic (32-bit) + cygwin + ICU 4.5 - using bjam (Boost 1.46.1) - with GCC 4.3.4: no problems - on Windows Vista (32-bit) + ICU 4.6 (bin package for Win32) - using bjam (Boost 1.46.1) - with MSVC 9: the library built, but for some reason bjam didn't use ICU even with -sICU_PATH specified, and I didn't have the time to investigate why. Also I've built and linked the examples and several small apps of my own trying out some features of the library (message translation, collation), on Debian 64-bit + GCC. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I've read the documentation, some parts of the discussion and some of the other reviews on this list, built the library and examples (see above) + written several toy applications, I've had only a quick glance at the sources. Put together probably somewhere around 12 hours. - Are you knowledgeable about the problem domain? I've worked on several projects with some kind of l10n/i18n using several different utilities (GNU gettext, wxWidgets, an in-house solution). But I certainly don't consider myself an expert on localization for the reasons stated above. Best regards, Matus Chochlik

5 6

[Shifted Pointer] Review Request
by Phil Bouchard 23 Apr '11

23 Apr '11

Greetings, I would like to request a review of the Shifted Pointer utility. I am happy to say that I've corrected some bugs within the library itself and now it seems to be working well with all test files. As pointed out by John Maddock, some pool functions such as ordered_free() can still be optimized in speed or replaced but for now I would like to keep the interface as it is until perhaps some changes to the pool can be proposed. Once again to compile the test executables (with gcc): $ svn co http://svn.boost.org/svn/boost/sandbox/shifted_ptr $ cd shifted_ptr/libs/smart_ptr/example $ make shifted_ptr_test3 And its documentation can be found here: http://fornux.com/personal/philippe/devel/shifted_ptr/libs/smart_ptr/doc/ Regards, -Phil

8 24

Re: [boost] [locale] Formal review of Boost.Locale library -- final days
by Gevorg Voskanyan 23 Apr '11

23 Apr '11

Here's my formal review of the Boost.Locale library. > Writing a review > ================ > > If you feel this is an interesting library, then please submit your > review to the developer list (preferably), or to the review manager > (me). > > Here are some questions you might want to answer in your review: > > - What is your evaluation of the design? I find this library mostly well-designed for localization needs. Points I like most: - Being designed around std::locale system - Great integration with I/O streams - Concentrating mostly on ICU - Yet having backend architecture to account for new possible backends as having them becomes reasonable - Supporting char, wchar_t, char16_t and char32_t - Using (and lobbying for) UTF-8 as default encoding Points I don't like most: - The boundary interface isn't attractive (in my opinion, shared by some other reviewers) - Operator overloading is sometimes used in unintuitive ways. For example operator/ used to get the value for a specific period type Observations: The interface sometimes doesn't meet the expectations a Boost user could have from a Boost library. E.g. not accepting arbitrary ranges as arguments. The overall design of the library takes into account ABI compatibility and ability to switch backends at runtime. Such concerns are not typical for Boost libraries so they have more freedom in some design decisions where Boost.Locale has no much choice. Which I personally don't find to be much of a problem and IMO shouldn't prevent acceptance into Boost. The author goes long ways to make Boost.Locale usable not only for regular Boost users but also for people who write *nix packages (including himself - CppCMS). This might see Boost.Locale gain more popularity, which can only have positive effect on the library and its evolution. > - What is your evaluation of the implementation? I glanced over the sources but didn't give it the thorough examination it deserves. I generally find the implementation reasonable given the constraints above. I noticed lack of exception safety in some places and places where RAII should have been used. The implementation might benefit from a careful examination intended to find and fix such kind of problems. I also think that dynamic memory management is used too freely - in many cases their usage is unavoidable but in some cases they are. Having said that I appreciate that some efforts have already been put in that direction: I noticed several places where fixed-size buffers were used if data is small enough and dynamic allocation if it's larger. More details at http://permalink.gmane.org/gmane.comp.lib.boost.devel/218352 > - What is your evaluation of the documentation? The documentation structure is good. It enables a new user to get started with the library quickly. The well-organized references help to find documentation for a specific facility in almost no time. I would however like to see more links within the text of the pages. There are many spelling and grammar issues in the documentation. Many of them have been already addressed to some extent by me and other reviewers, but it feels like there are still more of them left there. I agree that the documentation should be thoroughly scanned for such language issues by a native English speaker. I also think there should be more examples. More details at http://permalink.gmane.org/gmane.comp.lib.boost.devel/218117 and http://permalink.gmane.org/gmane.comp.lib.boost.devel/218343 > - What is your evaluation of the potential usefulness of the library? Very useful. > - Did you try to use the library? With what compiler? Did you have any > problems? I have played with the library using number/ordinal formatting, date formatting, currency formatting, spellout, case conversion and boundary analysis features. I have not used encoding conversion, normalization, timezone/calendar, (message) formatting and collation features. I have used ICU backend only. Environment: FreeBSD 8.0 g++ 4.5.0 in C++03 mode ICU 3.8.1 system-wide installation What I used was intuitive and easy, except for boundary analysis as noted above. I had some incorrect results most of which I believe are ICU issues. Some which I'm not so sure about though: - output of as::local_time was wrong by 2 hours; as::gmt was correct. Moreover, as::date printed the yesterday's date when the local time was 2:24 AM ! /bin/date shows correct local time, so I believe my system time zone settings are fine. - "Note: not all locales provide rules for spelling numbers. In such a case the number would be displayed in decimal format." This was not the case: std::cout << as::spellout << 117 << std::endl; printed "one hundred and seventeen" under hy_AM.UTF-8 locale. There were loads of "comma at end of enumerator list" warnings. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? Closer to in-depth study with more than 25 hours invested. > - Are you knowledgeable about the problem domain? I am well aware of localization problems and approaches that can be used to tackle them. I have developed in-house solutions to address some localization needs on as-necessary basis. > And finally, every review should answer this question: > > - Do you think the library should be accepted as a Boost library? Yes. > Be sure to say this explicitly so that your other comments don't > obscure your overall opinion. > -- > Chad Nelson > Oak Circle Software, Inc. Gevorg

1 0

[locale] Review: Design and Implementation
by Gevorg Voskanyan 22 Apr '11

22 Apr '11

I briefly skimmed over the sources and noticed some things I'd like to get addressed. Unfortunately this is far from being a real comprehensive review as I would like it to be, due to time constraints. operator= should return non-const reference. I don't really like date_time::operator/() as a syntactic sugar for date_time::get() when the involved period is not period::year, but e.g. period::day_of_week_local. It raises eyebrows when first seeing it, forcing one to look at the documentation to find out what that overloaded operator means. BOOST_LOCALE_DECL needs to be defined in terms of BOOST_SYMBOL_EXPORT and BOOST_SYMBOL_IMPORT. Also the exception classes need to be attributed with BOOST_SYMBOL_VISIBLE (I assume all member functions of exception classes are defined inline, which appears to be the case). Many constructors should be explicit but aren't. Existence of standard C++11 features should be checked with BOOST_NO_XXX macros instead of BOOST_HAS_XXX. E.g. !defined BOOST_NO_CHAR16_T rather than defined BOOST_HAS_CHAR16_T. Boundary interface should seriously be reconsidered. I would like to see it be very much like that of regex_iterator and regex_token_iterator. Please replace throw with BOOST_THROW_EXCEPTION. For classes having a swap member function there should also be a free swap function found by ADL. 'int unused' parameters for post-in/decrement operators will trigger warnings, the parameter name better be removed. Functions using Boost.Locale facets under the hood (e.g. boost::locale::fold_case) should be documented as might throw std::bad_cast. boundary.hpp: line 311: s/continious/contiguous/ line 319: e-b might not be well-formed, use std::distance(b, e) line 338: s/collsion/collision/ date_time.hpp: line 936: t.time(v); should not be called unless in >> v; succeeded format.hpp: line 104: s/get_posision/get_position/ Also, shouldn't this be const? formatting.hpp: line 229: this is not exception-safe localization_backend.hpp: line 145: why not boost::scoped_ptr? shared/formatting.cpp: line 45: this is not exception-safe. Why not use copy-and-swap idiom? (it has no swap() currently, but I see no reason why there couldn't be) shared/mo_lambda.cpp: line 239: s/tockenizer/tokenizer/ encoding/codepage.cpp: Why are converter objects allocated on free store and not stack? icu/all_generator.hpp: What do //ok comments signify? posix/codecvt.cpp: lines 82, 85: needs changed to use RAII posix/converter.cpp: line 159: s/impl_std/impl_posix/ std/std_backend.cpp: line 229: s/impl icu/impl_std/ (noticed cases like this in some other files as well, not necessarily in std/) Gevorg P.S. I plan to submit my final review with vote in 7-8 hours time from now. I hope that is OK.

2 1

[locale] Review: Reference documentation
by Gevorg Voskanyan 22 Apr '11

22 Apr '11

group__boundary.html: s/like and sentence boundaries/line and sentence boundaries/ s/alalisys/analysis/ s/Find a positions/Find positions/ s/like break is required/line break is required/ s/possible followed by/possibly followed by/ "Either first or second sentence break type;." redundant ; "word_any Any word including numbers, 0 is special flag, equivalent to 15." What has 0 to do with word_any that it's being mentioned here? Isn't 15 the value for word_none? s/Maximal used mask/All types of words mask/ maybe? structboost_1_1locale_1_1boundary_1_1break__info.html: s/begging/beginning/ classboost_1_1locale_1_1boundary_1_1boundary__indexing_3_01char_01_4.html: s/analisys/analysis/ classboost_1_1locale_1_1boundary_1_1mapping.html: s/Class the holds/Class that holds/ "When the object is created in creates index" s/in/it/ ? "it is used mostly together ..." capitalize the first letter s/vise versa/vice versa/ many occurrences "you can set the mask value sentence_term" sentence_term should be a link. In general the whole documentation should be scanned to add links where appropriate. "would not be compatible with old ones" add a period classboost_1_1locale_1_1boundary_1_1token__iterator.html: s/white spaces punctuation/white spaces, punctuation/ s/Opposite of ===/Negation of ==/ classboost_1_1locale_1_1boundary_1_1break__iterator.html: "Return the mark that token iterator points at." Shouldn't be break iterator? group__collation.html: "This module that introduces collation related classes" Rephrasing needed classboost_1_1locale_1_1collator__base.html: s/a base class that included/a base class that includes/ What about providing synonyms for collation levels like base_letters = primary, letters_accents = secondary, etc. classboost_1_1locale_1_1collator.html: s/stc::collate/std::collate/ s/two strings in rage/two strings in range/ Strings in rage can be harmful :D It isn't specified what values compare functions return. E.g. is it < 0, 0, > 0 or -1, 0, 1. Needs to be explained what kind of value is returned in which case. group__convert.html: s/various function/various functions/ s/It does not takes/It does not take/ many occurrences group__date__time.html: s/a enum/an enum/ s/perood/period/ date_time now(time(0),hebrew_calendar) cout << "Year:" t / perood::year <<" Full Date:"<< as::date_time << t; Should be: date_time now(time(0),hebrew_calendar); cout << "Year:" << t / period::year <<" Full Date:"<< as::date_time << t; classboost_1_1locale_1_1date__time__period__set.html: Why are the operations not commutative? s/should be in range [0,size)/should be in range [0,size())/ classboost_1_1locale_1_1calendar.html: s/Get grates possible/Get greatest possible/ classboost_1_1locale_1_1date__time.html: s/opject/object/ many occurrences s/perios/period/ "Check if the current time is in daylight saving time" Current time or the time represented by *this? In all other places, references to "current time" need to be checked. s/ingnores/ignores/ many occurrences s/substract/subtract/ many occurrences s/valrious/various/ s/gettimeofdat/gettimeofday/ namespaceboost_1_1locale_1_1period.html: "hour_12 12 clock hour [0..11]" AFAIU the range of hours in AM/PM notation is [1..12], no? s/withing/within/ s/First day if week/First day of week/ s/convers period_type/convert period_type/ namespaceboost_1_1locale_1_1time__zone.html: "namespace that holds function for operating global time zone identifier" Needs rephrasing, perhaps "namespace that holds functions for operating with global time zone" I don't think BOOST_LOCALE_DECL needs to be in documentation. s/returing/returning/ classboost_1_1locale_1_1basic__format.html: s/curl brackets/curly braces/ s/hight/height/ "sci or `scientific` -- display in scientific format" why is scientific in backticks and sci not? "per or percent -- format percent value." What happens when a value out of range [0..1] is passed in? "locale -- with parameter -- switch locale for current operation. This command generates locale with formatting facets giving more fine grained control of formatting. For example: " Where is the example? What are the requirements for Formattible? group__format.html: s/Definiton/Definition/ 2 occurrences s/It use locale and of \a out stream/It uses locale of \a out stream/ group__manipulators.html: s/is treaded as/is treated as/ many occurrences namespaceboost_1_1locale.html: s/namespae/namespace/ s/independed/independent/ multiple occurrences s/typr/type/ "Generate codepage conversion facets" Isn't "encoding" more appropriate? namespaceboost_1_1locale_1_1util.html: s/the codecvt faced/the codecvt facet/ s/it know/it knows/ s/can can/can/ two occurrences classboost_1_1locale_1_1calendar__facet.html: s/Locale id (for work with std::locale/Locale id (needed to work with std::locale)/ classboost_1_1locale_1_1generator.html: s/protable/portable/ s/if it deals with/if dealing with/ classboost_1_1locale_1_1hold__ptr.html: s/transfered/transferred/ two occurrences classboost_1_1locale_1_1info.html: s/Is underlying encoding is UTF-8/True if the underlying encoding is UTF-8/ classboost_1_1locale_1_1localization__backend.html: s/swithc/switch/ s/differnt/different/ s/priority/priotiry/ classboost_1_1locale_1_1localization__backend__manager.html: s/avalible/available/ s/combing/combining/ classboost_1_1locale_1_1message__format.html: "Default constructor" Not exactly, can be called with a size_t argument as well structboost_1_1locale_1_1message.html: "Message class can be explicitly converter to string class" converted s/defailt/default/ \ a --> \a for doxygen, 3 occurrences operator<< not mentioned but should be as it is part of the message class interface A link to group__message.html would be helpful here structboost_1_1locale_1_1gnu__gettext_1_1messages__info.html: s/sturcture/structure/ s/this structure not useful/this structure is not useful/ s/Igronred/Ignored/ s/for narror/For narrow/ s/seach/search/ Inconsistent documentation for data members here: some are documented in Member Data Documentation, the other in the introduction. "Locale category, is set by default LC_MESSAGES, but ma." Incomplete? General remarks: Sometimes qualified ids make it harder to read. For example in group__boundary.html the boost::locale::boundary:: qualifiers make it really hard for me to read the important part here - the individual names. Gevorg

2 2

Re: [boost] [MSM] Interrupt anonymous transitions or blocking process_events?
by Christophe Henry 22 Apr '11

22 Apr '11

Hi Mathias, > Hi Christophe, > > Thank you for the helpful reply! You're welcome :) > That helped me alot doing it that way. Thank you! It was a struggle > before I realized how to call a process_event(...) from within a member > function. I hope I am doing it the right way :-) > > I also tried adding > > boost::signals2::signal<void ()> sig; > > to the statemachine but my compiler did not like that at all > (noncopyable errors). So I stayed with a mutex and a condition variable. > The way I did it can be improved I am sure... > > Anyway, you can see an outline below of how I did this. Perhaps this is > an ok way doing it? <snip> Depending on how you use it, yes. I'm a bit worried with race conditions in case your state machine is also used in another thread, which would also call process_event. Alternatively (if you want to avoid locking/deadlocking/rc), you could also move the worker thread out of the fsm and have both communicate with synchronized message queues. You might want to have a look at boost::circular_buffer, which provides an example (http://www.boost.org/doc/libs/1_46_1/libs/circular_buffer/doc/circular_buff…) Regards, Christophe

2 1

Re: [boost] [Foreach] Supporting range adaptors for temporary containers
by Ivan Le Lann 22 Apr '11

22 Apr '11

----- "Michel MORIN" <mimomorin(a)gmail.com> a écrit : > Sometimes it is convenient to apply range adaptors to a temporary > container > and iterate over it: > > // `using namespace boost::adaptors;` is assumed > BOOST_FOREACH(auto x, std::string("Hello, world!") | reversed) > {...} > > However, the lifetime of the temporary container ends before the loop > body > begins. This problem also exists in C++0x range-based for. > To solve this, I'd like to propose an extension of BOOST_FOREACH > macro: > IIUC, the line below is broken: auto const & broken_range = std::string("Hello, world!") | reversed; So it seems you're proposing to adapt BOOST_FOREACH to solve a problem in adaptors. How do you intend to fix C++11 builtin foreach? In C++11, I think this could be fixed with rvalue refs detection. Shouldn't any function relying on the fact that its arguments still exist after the call do that check? So either delete the &&-function or ... [disclaimer: ugly but funny] make it move the range inside the adaptor somehow. Ivan

4 4

[locale] Formal review of Boost.Locale library -- final days
by Chad Nelson 22 Apr '11

22 Apr '11

The final day of the Boost.Locale formal review is tomorrow, April 22nd. If you're planning to submit a review but haven't, now is the time. I'll accept reviews up until I complete the report on Saturday morning. Writing a review ================ If you feel this is an interesting library, then please submit your review to the developer list (preferably), or to the review manager (me). Here are some questions you might want to answer in your review: - 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? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. -- Chad Nelson Oak Circle Software, Inc. * * *

6 7

Re: [boost] Boost statechart viewer
by Christophe Henry 22 Apr '11

22 Apr '11

> I have no plan about Boost::MSM library in next two months. From the > first point of view I think that it shouldn't be difficult to update > the program to be able to work with Boost::MSM. So maybe after or > during summer holidays. > > If I do anything I will let you know. Hi Petr, If you decide to support MSM, I'll be happy to provide help if you need. Regards, Christophe

1 0

Fwd: Submission for Google Summer of Code 2011
by Suriya Singh 22 Apr '11

22 Apr '11

Project proposal: A lightweight platform independent library for graphics for Android. Start Date: 10 june 2011 Start Coding 10 june 2011 Documentation 1 August 2011 Testing: 25 July 2011 End date: 10 August 2011

1 0

[Foreach] Supporting range adaptors for temporary containers
by Michel MORIN 22 Apr '11

22 Apr '11

Sometimes it is convenient to apply range adaptors to a temporary container and iterate over it: // `using namespace boost::adaptors;` is assumed BOOST_FOREACH(auto x, std::string("Hello, world!") | reversed) {...} However, the lifetime of the temporary container ends before the loop body begins. This problem also exists in C++0x range-based for. To solve this, I'd like to propose an extension of BOOST_FOREACH macro: BOOST_ADAPTED_FOREACH(VARIABLE, RANGE, ADAPTORS) { // do something } which is conceptually equivalent to { auto const& rng = RANGE; // if RANGE is an lvalue, use `auto& rng = RANGE` BOOST_FOREACH(VARIABLE, rng | ADAPTORS) { // do something } } A temporary range, RANGE, is bound to a const reference and its lifetime is extended. (To do this, compiler support of rvalue references and `auto`/ `decltype` is needed. In C++03, a temporary range needs to be copied.) Then we can do the following without worry about the lifetime problem. BOOST_ADAPTED_FOREACH( char ch , std::string("Hello, world!") , reversed | replaced('e', 'a')) { std::cout << ch; } To bind a temporary range, we can also use (non-const) rvalue reference. But I choose to use const lvalue reference. The rationale is * In the pipe operator, a temporary range is captured as a const reference. So if we use rvalue reference binding, the mutability of the resulting range (`auto&& rng = RANGE; rng | ADAPTORS`) and `RANGE | ADAPTORS` would be different. For example, `std::list<int>(3) | reversed` is a const range, but `auto&& rng = std::list<int>(3); rng | reversed` is a mutable range. To be consistent with `RANGE | ADAPTORS`, using const lvalue reference (`auto const& rng = RANGE; rng | ADAPTORS`) is better. * Mutable iteration over temporary ranges makes little sense. Note that, BOOST_ADAPTED_FOREACH works fine if an input range is a temporary containers, but it does not work properly if an input is a range-proxy (such as `iterator_range`) of a temporary container. In this case, only the lifetime of range-proxies is extended and dangling reference to the temporary range occurs: BOOST_ADAPTED_FOREACH( int i , boost::equal_range(std::multiset<int>(...), 1) , reversed) { // Oops, dangling reference! // Input is an `iterator_range` of the temporary multiset<int>(...) } BOOST_ADAPTED_FOREACH( int i , boost::assign::list_of(1)(2)(3)(4)(5) , reversed) { // Oops, dangling reference! // Input is a reference to the temporary `list_of(1)` } Header file and sample code attached. (Though I omitted the C-string support for simplicity, it is easy to add the support.) If there are some interests about this proposal, I will create a trac ticket. Comments? Regards, Michel

3 5

[locale] Review
by Mathias Gaunard 21 Apr '11

21 Apr '11

Let us start with my decision: I vote against inclusion of Boost.Locale into Boost in its current state, but strongly encourage the author to reconsider resubmitting it after some design issues have been reconsidered. In which case, I would be in favour of putting it on the fast-track for a mini-review. Since I am the author of another Unicode library that I'd like to see included in Boost, I hope that my review will not be considered biased. I believe Boost.Locale is a valuable and useful library, and I believe both libraries can coexist. The main reason for my decision is the interface that the library provides: albeit it aims at abstracting the backend used to implement the facilities, it exposes too much of how those facilities are implemented, which prevents benefiting from future backends that may not have the same limitations as the current backends do. Indeed, the Boost.Locale rationale clearly says that it only takes std::basic_string and const char* as input because that's what the backend libraries expect anyway. Yet there are various scenarios where this is useful: - I might want to apply some operation to data in a file without putting it all to memory first; Boost.Locale could copy that memory by chunks to apply that operation for backends that have no native support for this. Copying the whole file to memory is a good enough approximation for a first version. - The input I have may not be directly available in the form of a contiguous buffer, but I wouldn't mind if Boost.Locale copied it. If we consider the functions from_utf, to_utf and between, they can either take a const char*, two const char*, or a std::basic_string. Clearly this would be better if those functions took a range, which covers all three of these cases. It's not just a matter of being generic, it makes the library easier to use since the range is defined by a single argument which can be anything I want, I do not need to convert to what the library needs. If the library needs to do conversion behind the scenes, it can do it just like that, behind the scenes. Taking a range causes the problem however of what the return type should be: I think there should be two variants, one which returns a string, and one which appends to a container (like Boost.StringAlgo) or write to an output iterator (like STL algorithms). Obviously, the former would be defined in terms of the latter. This causes however a big problem: all backends would not be interchangeable with a stable unique ABI. Maybe some template specializations could be injected at link-time, but they would have to be full concrete specializations. Maybe the idea of backends being interchangeable at the ABI level needs to be rethought. After all, isn't being interchangeable at the API level enough, since you can easily mangle the configuration in a symbol to cause an error if linking with the non-matching backend? Still talking about conversion between encodings, I would like it if it was possible to statically choose the encodings we're converting between, as some backends could directly expose a specialized and optimized some_encoding_to_some_other_encoding function. Note the remarks about conversion between encodings also applies to case folding, collation etc. Being able to specify statically the normalization form you're normalizing to and things like that could be useful just as for the character encodings. Perhaps not made clear from the docs, but Boost.Locale embeds another mechanism than the functions in the conv namespace to convert between character encodings: using the classes derived from boost::locale::util::base_converter. This is the only interface that can be passed incomplete data, as obtained through buffering. That interface was designed to implement codecvt facets, and unfortunately, it's not much better. The library implements its own UTF-8/UTF-16/UTF-32 conversion logic there regardless of which backend is used; it is a shame it cannot reuse the to_utf or from_utf functions in all cases. This implementation is also quite tricky since the state management prevents the code from being simple and self-contained. That interface does not allow optimized conversion functions to be used. Compatibility with codecvt facets is a nice feature, but it shouldn't impair the interface of the component that could have other usages. Furthermore, I do not find the boundary analysis interface satisfying at all. It is not made clear in the docs that doing boundary analysis actually goes through the whole string and returns a vector of positions corresponding to the boundaries. You can use that vector to adapt any range into a range of strings. Each dereferencing copies the subrange defined by the vector into a new temporary string. This is pretty terrible. I want to be able to find the boundaries as I advance through a string, or be able to find the closest boundary from an arbitrary position without having to process the whole string. I do not want to have to copy my whole input range into little strings for no reason. Usage of this feature is also unnecessarily verbose. It should not be more than a function call to turn a range of characters into a range of tagged ranges of characters. This part of the library is the one that needs the more work. Ironically enough, it's also the only one that deals a bit with iterators and ranges, and I just asked for more iterators and ranges at the beginning of this review ;). Finally, I will not comment on the implementation too much, since I think other Boosters already did that (though I did not read all of it). There is some unnecessary or non-optimal code, some code more complicated than it should be, some compile-time values tested at runtime, some things that could have reused existing utilities from Boost, and some inappropriate use of reinterpret_cast. While most of the backends are separated, it is not the case for encoding/codepage.cpp, which is shared by all backends and contains ifdefs. This is not a very nice extension point. I'm also a bit concerned about the generalized usage of virtual functions anywhere; it seems unnecessary in quite a few places, please prefer using templates when dynamic binding is not required. A lot of new and vectors too, I'd prefer if ideally the library never allocated anything. I hope my review will be well received and that you will consider all of my "feature requests". Your library is practical and can get things done for sure, but maybe it's not quite as good as it could be in terms of interface yet. Also, if I want Boost.Unicode to ever be a possible backend, Boost.Locale needs to be able to make the most of it ;).

8 18

[Review] Formal review of Boost.Convert library starts Saturday
by Edward Diener 21 Apr '11

21 Apr '11

This is a reminder that formal review of the Boost.Convert library by Vladimir Batov starts on Saturday, April 23, and is scheduled to last through May 2. *************** * Its Purpose * *************** From the introduction: Boost.Convert builds on the boost::lexical_cast experience and still offers a simple, minimal interface, familiar conversion behavior and more: * throwing and non-throwing behavior when conversion fails; * support for the default/fallback value to be returned when conversion fails; * two types of the conversion-failure check - basic/simple and better/safe; * formatting support based on the standard std::streams and std::stream-based manipulators (like std::hex, std::scientific, etc.); * support for different locales; * support for boost::range-compliant char and wchar_t-based string containers (std::string, std::wstring, char const*, wchar_t const*, char array[], etc.); * no DefaultConstructibility requirement for the Target/Destination type; * extendibility and additional room to grow. ******************* * Where to get it * ******************* You can find the Boost.Convert here: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost-… The HTML documentation is part of the distribution and can be found at libs/convert/index.html in the distribution above. ******************** * Writing a review * ******************** The reviews and all comments should be submitted to the developers list, and the email should have "[convert] Review" at the beginning of the subject line to make sure it's not missed. Please explicitly state in your review whether the library should be accepted. The general review checklist: - 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? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Edward Diener, Review Manager

1 0

GSoC 2011
by mahbubul hasan 21 Apr '11

21 Apr '11

Hi, I am Mahbub. I am a CSE graduate. I just saw you had a proposal regarding queue and heap in GSoC 2010. In my undergraduate I did thesis on heaps. In that time I learned soft heap, it might be interesting to you. Here is the short description of soft heap<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.85.3258&rep=rep1&t…>.( http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.85.3258&rep=rep1&t…) Soft heap is a heap like data structure but with some uncertainty. This data structure supports insert, delete, merge, findmin. It does every work in amortized constant time except insert operation which takes O( log 1/e ) where 0<e=<.5. Here e is error rate. The data structure will never contain more than en corrupted elements. There are two versions of soft heap. 1. By Binomial Tree 2. By forest of binary tree There is one more thing that might interesting to you. That is, in my undergraduate I improved the running time of heap sort by significant amount by applying pairing technique. The paper is submitted to International Journal of Computer Mathematics and it is under review now. It mainly improves Carlsson's variant of heapsort. It also improves the deletion method proposed by Gonnet and Munro (Heaps on Heaps). [The heap is inplace, that means no additional space is required] It also improves the Weak Heapsort. WeakHeapsort is a sorting method which requires O(n) additional bit to sort. However applying the pairing technique it can be reduced to O(n/2) additional bit. It is known that weakheap is the theoretically best known algorithm. [Best considering number of comparisons] So I am just curious if you are interested in these types of algorithms. I saw no possible proposal category where these fits in, but I thought you might be interested. Please let me know what do you think about this. Mahbub

2 6

[locale] Formal review of Boost.Locale library EXTENDED
by Chad Nelson 21 Apr '11

21 Apr '11

(This message made it to the announcements list, but the copy intended for the developers list didn't make it and I hadn't noticed. I apologize if this inconvenienced anyone.) There have been only a handful of reviews of the proposed Boost.Locale library to date, and several people have requested more time to provide theirs, so the formal review of the Boost.Locale library has been extended. The deadline for reviews is now 11:59pm UTC on Friday, April 22nd. For those in the Western hemisphere, remember that that's earlier than it might seem -- 7:59pm in New York, 4:59 in Los Angeles. I'll accept late reviews until I complete the report on Saturday morning, but please try to get yours in earlier. You can find the "boost_locale_for_review" version here: https://sourceforge.net/projects/cppcms/files/boost_locale/ The HTML documentation can also be seen at: http://cppcms.sourceforge.net/boost_locale/html/index.html Writing a review ================ If you feel this is an interesting library, then please submit your review to the developer list (preferably), or to the review manager (me). Here are some questions you might want to answer in your review: - 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? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. -- Chad Nelson Oak Circle Software, Inc. * * *

11 34

review needed
by Xu Sun 20 Apr '11

20 Apr '11

Hi, I've posted my proposal on 04/05 but still didn't receive any reply including email or comment. I will be very appreciated if any one can give me any feedback about my proposal. The link is here: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/sunbow/1 Sorry to bother others. Thanks, Xu Sun

4 4

new operator traits: how to merge to the trunk?
by Frédéric Bron 20 Apr '11

20 Apr '11

Dear developpers, I am working on answering all comments of the review concerning the addition of operator traits. When this is finished, what will be the process to include the extension to the trunk? Is it something I will have to do my-self? If so, what is the way to do it? Thanks in advance, Frédéric

2 1

[Fusion] Tentative of trasnform_if failed :(
by falcou 19 Apr '11

19 Apr '11

The following code http://ideone.com/xYk4X doesn't compile and i cant get the why of it. The goal is to have a fusion transform_if that takes a compile-time predicates For each element int he sequence, if the predicates its true, we apply some transform on it, if not we return the element unchanged. What am I missing ?

3 6

Interest in doing project "concept Traits library"
by Rachit Kulshreshtha 19 Apr '11

19 Apr '11

I know that i am running late as i had my university exams but i have been following the projects entitled under Google Summer of Code 2011. I am a student of BITS-Pilani University, India doing my B.E. in Electronics and Instrumentation. I was going through the project "concept traits library" , trying to understand it. I was able to gather much information about what it is and how it works, with some details of the functions under operator traits, mpl_ext and even Concept traits. But since their is no well defined problem statement given on the website, i was wanting to know what functions \ templates already exist as parts of the library and what are we expected to create. Please reply soon... Thnx in advance -- its a bird, its a plane, its a rocket no its Rachit

3 14

Re: [boost] [MSM] Interrupt anonymous transitions or blocking process_events?
by Christophe Henry 19 Apr '11

19 Apr '11

Hi Mathias, <snip> >By calling p.process_event(play()); the the player will start playing >Song1 and then change to the next song by itself. But now in single >threaded mode it blocks until it reaches "Song3". So it is not possible >to process any other events during this time. In other words, it cannot >process another process_event call. The "Playing" state has a "stop" >event but calling this will not help as it will not be processed until >the MSM has reached "Song3". The problem is that a state machine is based on run-to-completion. This means in your case that a transition must be "short". An event comes, a transition is executed, the state machine is in a new stable state and can process a new event. Until this happens, events are queued (in the case of MSM). >I start the same p.process_event(play()); in thread 1. And in thread 2 I >call p.process_event(stop()); The problem with this is that the stop() >event does not get processed until it reaches Song3 because of the >blocking call in p.process_event(play());. Actually I'd think because of the mutex. In any case, your design will be hard to get right I'm afraid. >Perhaps I am going about this the wrong here and please tell me if it >can be done in some other much better way! I want to be able to have >automatic transitions that I can interrupt. You have to use run-to-completion. Base your design on short-terms events fed to the state machine, which triggers work and reacts to changes in forms of other events. In your case, one possibility would be to have the state machine delegate (post) some work upon state entry or transition action to a thread, then posting a new task upon state exit, etc. Make your state machine be serviced by only one thread, triggering work and reacting to events. Trust me on that one, having a state machine serviced by 2 threads is a good receipt for headaches ;-) If you know boost::asio, it's a bit like the async_xxx methods, trigger some work and get ready for the next action (which would be a callback, to continue with this asio example). HTH, Christophe

2 1