- Boost - lists.boost.org

[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