April 2011 - Boost - lists.preview.boost.org

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