April 2011 - Boost - lists.boost.org

[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

[preprocessor] seq/size.hpp BOOST_PP_SEQ_SIZE MSVC empty list warning
by damien benoist 19 Apr '11

19 Apr '11

Hello, It seems that BOOST_PP_SEQ_SIZE generates a warning with empty sequences under MSVC (vs 2010/boost 1.46.1). The same call works with gcc. The tests are available below. I've also put a patch but: - I'm really not sure of it (I have never been as far with preproceesor as in boost/preprocesor/) - I only tested it with BOOST_PP_CONFIG_MSVC (it should also be tested with BOOST_PP_CONFIG_EDG) And anyway this warning will likely appear with all macros manipulating sequences. Should this warning just be ignored or disabled with MSVC? More general question: I'm discovering boost. I'm really impressed by the macros in boost/preprocessor. It makes a lot of things possible. But it provides features the preprocessor was not meant for. For that, it uses a lot of tricks. How portable is it? How many architectures is it known to work/not work with? Can we be confident that it should work with any preprocessor? Thanks for your help. $ cat lstsz2.h #include "boost/preprocessor/seq/size.hpp" #define lst0 #define lst1 (a) #define lst2 (a)(b) #define lst3 (a)(b)(c) BOOST_PP_SEQ_SIZE(lst0) BOOST_PP_SEQ_SIZE(lst1) BOOST_PP_SEQ_SIZE(lst2) BOOST_PP_SEQ_SIZE(lst3) $ cpp -I ~/wh/softs/boost/1.46.1 < lstsz2.h ... 0 1 2 3 $ cl -I `cygpath -d "$HOME/wh/softs/boost/1.46.1"` /E lstsz2.h ... 0 1 2 3 lstsz2.h(8) : warning C4003: not enough actual parameters for macro 'BOOST_PP_SEQ_SIZE_I' $ diff -u 1.46.1/boost/preprocessor/seq/size.hpp.old 1.46.1/boost/preprocessor/seq/size.hpp --- 1.46.1/boost/preprocessor/seq/size.hpp.old 2005-06-21 09:55:15.000000000 +0200 +++ 1.46.1/boost/preprocessor/seq/size.hpp 2011-04-19 14:42:02.218750000 +0200 @@ -13,6 +13,7 @@ # define BOOST_PREPROCESSOR_SEQ_SIZE_HPP # # include <boost/preprocessor/cat.hpp> +# include <boost/preprocessor/empty.hpp> # include <boost/preprocessor/config/config.hpp> # include <boost/preprocessor/tuple/eat.hpp> # @@ -21,7 +22,7 @@ # define BOOST_PP_SEQ_SIZE_I(par) BOOST_PP_SEQ_SIZE_II ## par # define BOOST_PP_SEQ_SIZE_II(seq) BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_, BOOST_PP_SEQ_SIZE_0 ## seq) # elif BOOST_PP_CONFIG_FLAGS() & BOOST_PP_CONFIG_EDG() || BOOST_PP_CONFIG_FLAGS() & BOOST_PP_CONFIG_MSVC() -# define BOOST_PP_SEQ_SIZE(seq) BOOST_PP_SEQ_SIZE_I(seq) +# define BOOST_PP_SEQ_SIZE(seq) BOOST_PP_SEQ_SIZE_I(seq BOOST_PP_EMPTY()) # define BOOST_PP_SEQ_SIZE_I(seq) BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_, BOOST_PP_SEQ_SIZE_0 seq) # elif defined(__IBMC__) || defined(__IBMCPP__) # define BOOST_PP_SEQ_SIZE(seq) BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_, BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_0, seq))

2 1

[TypeTraits] Are any of the new C++2011 traits implementable using SFINAE expressions?
by John Maddock 19 Apr '11

19 Apr '11

I'm quite sure the answer to this is no.... but are there any new language features in C++2011 that would allow the implementation of any of the following traits within the language? Thanks in advance, John. template <class T> struct is_trivial template <class T> struct is_trivially_copyable template <class T> struct is_standard_layout template <class T> struct is_literal_type template <class T, class... Args> struct is_constructible; template <class T> struct is_default_constructible; template <class T> struct is_copy_constructible; template <class T> struct is_move_constructible; template <class T, class U> struct is_assignable; template <class T> struct is_copy_assignable; template <class T> struct is_move_assignable; template <class T> struct is_destructible; template <class T, class... Args> struct is_trivially_constructible; template <class T> struct is_trivially_default_constructible; template <class T> struct is_trivially_copy_constructible; template <class T> struct is_trivially_move_constructible; template <class T, class U> struct is_trivially_assignable; template <class T> struct is_trivially_copy_assignable; template <class T> struct is_trivially_move_assignable; template <class T> struct is_trivially_destructible; template <class T, class... Args> struct is_nothrow_constructible; template <class T> struct is_nothrow_default_constructible; template <class T> struct is_nothrow_copy_constructible; template <class T> struct is_nothrow_move_constructible; template <class T, class U> struct is_nothrow_assignable; template <class T> struct is_nothrow_copy_assignable; template <class T> struct is_nothrow_move_assignable; template <class T> struct is_nothrow_destructible; template <class T> struct underlying_type;

2 1

Re: [boost] [Filesystem] error including filesystem v3 with icpc -std=c++0x
by Galen Andrew 19 Apr '11

19 Apr '11

> > Hello, > > > > Including boost/filesystem.hpp is giving me errors using Intel > > compiler in Linux with -std=c++0x that look like > > > > > boost/filesystem/v3/operations.hpp(303): error: name followed by "::" > > must be a class or namespace name > > {detail::copy_file(from, to, > > copy_option::fail_if_exists);} > > ^ > > It compiles fine under g++ -std=c++0x. > > What happens with the Intel compiler if you don't specify -std=c++0x? Without -std=c++0x those errors are gone, but a similar error pops up in another boost library I'm using boost/random/variate_generator.hpp(209): error: name followed by "::" must be a class or namespace name typedef typename random::detail::engine_helper<have_int, want_int>::BOOST_NESTED_TEMPLATE impl<decorated_engine, typename Distribution::input_type>::type internal_engine_type; ^ > The regression tests are passing for Intel on Linux, but it doesn't > look like any of them specify -std=c++0x > > What version of the Intel compiler are you using? Version 12.0.2.137 Build 20110112 > > What version of Boost are you using? 1.46.1 Thanks!

1 0

[network] Release 0.9.0
by Dean Michael Berris 19 Apr '11

19 Apr '11

Good day everyone, apologies for the cross-post. I just wanted to point everyone interested in the development of the cpp-netlib project to the 0.9.0 release announcement over at C++ Soup: http://cplusplus-soup.com/2011/04/18/cpp-netlib-0-9-0-released/ -- more information about what happened in the library between the beta and the official release can be found there. As earlier mentioned, this version is the pre-1.0 snapshot that is being officially submitted to the Boost C++ Library as Boost.Network. I would like to ask the review wizards to please accept this announcement as a request to put Boost.Network/cpp-netlib into the review queue pending a review manager. I would greatly appreciate volunteers who would like to be the review manager(s) for the Boost.Network review. Have a good one and I definitely hope this helps. Cheers from down under! -- Dean Michael Berris http://about.me/deanberris

2 1

[gsoc] Review needed --- BGL extension : community detection algorithm
by Xu Sun 19 Apr '11

19 Apr '11

Hi, Thanks for Robert's advise. 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 And the abstract: Implement new library based on Blondel's method and Newman's method providing community detection functionality into Boost libraries. Through this library, users can get their input direct/indirect weighted/unweighted graph segmented based on the criterion that the nodes within the same community have a more significant relationship than those between different communities. Sorry to bother others. Thanks, Xu Sun

3 2

[OT] Boost Users/Developers Down Under?
by Dean Michael Berris 19 Apr '11

19 Apr '11

Hey Everyone! Apologies for the cross post and off-topic, but I just moved to Sydney, Australia and I was wondering whether there are any Boost users/developers that are based here who'd like to get together for a geek out session somewhere in the city? I tried to look at the Boost Users Map (http://goo.gl/O1I15) and I only saw one other Boost user in the area -- maybe there are others lurking around who'd be interested in a meet-up here? :) Cheers from down under! :D -- Dean Michael Berris http://about.me/deanberris

1 0

FW: [locale] Off-list review
by steve.bush＠neosys.com 19 Apr '11

19 Apr '11

-----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Vicente BOTET Sent: 19 April 2011 10:33 >Hi, I have the impression that this review has already been sent at Date: Sat, 16 Apr 2011 15:40:53 +0400 . >BTW, who sent it? I did. I am sorry for wasting everybody's time. I joined the list immediately afterwards and have followed the very lively discussion intently since then. Artyom is quite resolute in the defence of his design decisions some of which brutally practical compromises - even if theoretically ugly. Things like broken standard libraries and "Broken" csv just aren't going to be fixed. This particular library has to live in the real world of existing libraries, not a vacuum, so the exquisite design purity which is so much a part of many boost libraries is less a consideration here. One of the strengths of the library seems to be that Artyom has used it in production for some years, although apparently mainly in posix/utf-8 environment and without CJK. I seriously doubt there will be any better offer for internationalisation library than this and it may trigger a better solution later on. If that is the case then this review better try to identify any unacceptable features in the library - especially those that cannot be replaced in future versions. If there are few or none then I think it should be admitted. Steve Bush

1 0

[locale] Off-list review
by Chad Nelson 19 Apr '11

19 Apr '11

This review was sent to me privately, rather than to the list. I don't think I realized that when I received it. Apologies if I had forwarded it earlier too. -- Chad Nelson Oak Circle Software, Inc. * * * Begin forwarded message: Date: Sat, 16 Apr 2011 15:40:53 +0400 From: <steve.bush(a)neosys.com> --- What is your evaluation of the design? Very good to start with since leveraging locale for i18n/l10n is a great rallying point for developers. Translate GETTEXT might be better in a separate library to increase degrees of freedom and reduce coupling. --- What is your evaluation of the implementation? The wrapper/backend strategy provides immediate benefit while leaving the door open to progressive reimplementation. Since it is a wrapper, could PARTS of it be implemented as a header only? --- What is your evaluation of the documentation? The documentation is more than good enough to start with considering this library's potential usefulness. --- What is your evaluation of the potential usefulness of the library? This library is potentially *extremely* useful because it LEVERAGES an important chunk of standard C++ that is sadly underutilised merely due to a few design and implementation flaws. This library has potential something of the order of Boost.FileSystem. This is a VERY strategic library and any shortcomings will be resolved with time. --- Did you try to use the library? With what compiler? Did you have any problems? Didn't try. --- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I meticulously read all documentation several times. --- Are you knowledgeable about the problem domain? Yes, we have used similar technique for Exodus http://devwiki.neosys.com and will replace those with Boost.Locale if and when it becomes available. --- Do you think the library should be accepted as a Boost library? YES - It is relatively small but has a massive effect. It has a very low cost/benefit ratio since it leverages long standing classic C++ locale design/skills.

3 3

[locale] review
by Phil Endecott 19 Apr '11

19 Apr '11

Dear All, Here is a brief review of the proposed Boost.Locale library. I know little about the internationalisation issues that this library addresses, so I will focus just on the few areas where I do have some experience. The documentation is generally of good quality but could be expanded in places as noted below. I appreciate the introduction of std::locale at the beginning; having avoided std::locale for precisely the "common critical problems" mentioned, this introduction was useful. As others have said, a similar introduction to icu, perhaps even deep links to appropriate parts of its documentation, and perhaps also to Unicode docs would be useful. I found that it was not sufficiently easy to find which header each function is in, e.g. on the charset_handling.html page the name of the header is not mentioned; if I click on e.g. from_utf I get to a reference page that also doesn't name the header. Use of strings rather than symbols: there are a few places where the library uses strings such as "UTF-8" or "de_DE.UTF8" rather than symbols like utf_8 or de_DE_UTF8. This use of strings can make things run-time errors that could otherwise be compile-time errors. Mis-typing e.g. "UTF_8" or "de-DE" is too easy. Perhasp in some cases the domain of the parameter is not known at compile time, but even in those cases, it should be possible to provide symbols for the most common choices. Collation: I would be interested to know how fast these comparisons are compared to regular std::string::operator<. If I correctly understand what transform does (more docs needed), it would be interesting to then compare the performance of std::map<...,comparator> with a std::map<> storing transformed strings. Or similarly, to compare std::sort using the comparator with std::sort of a pair<transformed string, original string>. Ideally these collation functions would take character ranges of arbitrary types, however I guess that the icu API takes char* making this unreasonable. Apparently there is no option for a NULL-terminated char*, unlike the case conversion functions, right? Case conversions: I don't know what "title case" is or what "fold case" means; the docs should define this. At least linking to the definitions of the Unicode normalisation forms would also be useful; preferably, some explanation of how they should be used would be included. I can think of two recent case-conversion problems that I have had, both related to geographic names: 1. I had a list of North American names, in "UPPER CASE". I decided to convert them to "Initial Capitals" for better appearance, but later realised that this was broken for accented names in Quebec. I could imagine some sort of "case conversion is lossy" property of a locale that would detect this; does anything like that exist? (I guess not.) 2. In a similar case I found that " 's " was being wrongly capitalised, e.g. "St. John'S Street". (This was with PostgreSQL's case conversion functions.) Again it would be useful to know whether (a) does the library try to handle this sort of thing correctly, and (b) can it tell me whether the operation that I want to do is lossy or not? For example, say I have a set of place names that are a mixture of en_US and en_CA and fr_CA but I don't know which; can I perform a conversion that works because those locales all have the same rules for e.g. ' and -? (I guess not.) Character set conversion: I think it's great that Boost might finally get character set conversion - it's overdue! However, I'm not enthusiastic about this: std::string utf8_string = to_utf<char>(latin1_string,"Latin1"); 1. It should be possible for the source character set to be a compile-time constant symbol, and a template parameter e.g. conv<latin1,utf8>(str). As it is, if I want to convert just a few bytes, it will surely spend more time decoding the charset name string than actually converting. 2. As above, ideally it should take a range of arbitrary type and output to a back_insert_iterator; presumably this is an icu limitation. 3. The error handling seems to be basic - it's "all or nothing". Considering from_utf, since this is the direction where there are more things that can be unrepresentable, I might want to: - Skip the character; - Replace with '?'; - Replace with an unaccented version, or e.g. curly-quotes to plain-quotes; - Throw an exception that aborts the whole operation; - Do the conversion up to the point of difficulty and then indicate the problem. 4. There's also the case where the input is chunked, and the chunk-breaks might fall within multi-byte characters; so individual chunks are potentially malformed while the overall stream is OK. I think the best way to handle this is with a stateful functor to do the comparison; I wrote one using iconv, like this: Iconver<latin1,utf8> latin1_to_utf8; while (!end_of_input()) { output.append( latin1_to_utf8(input.get_chunk()) ); } assert(latin1_to_utf8.empty()); // detect unconverted partial chars at end of input Also: how is the performance of this conversion? If it is being done by icu, we should have a hook (i.e. specialisation, hence my suggestion of template parameters for the character sets) so that we can provide optimised versions of important conversions. Here are my answers to the "normal questions": - What is your evaluation of the design? Generally it seems like a reasonable design for an icu wrapper. If it were not an icu wrapper, no doubt some things could be done better. - What is your evaluation of the implementation? I've looked at very little of the source. I decided to look at iconv_codepage.hpp since I have some experience with iconv. I note that a union is being used in what I believe is an undefined way: union { char first; uint16_t u16; uint32_t u32; } v; v.u16 = 1; if(v.first == 1) { return "UTF-16LE"; } else { return "UTF-16BE"; } In my own iconv wrapper code I need a const_cast because the POSIX spec misses a const on the second argument to iconv(); some platforms correct this, but not all: #if defined(__FreeBSD__) || defined(__OpenBSD__) || defined(__NetBSD__) || defined(__sun__) // Previously __APPLE__ was included in this list; presumably they have // changed their headers. If you have an older system you may need to put // it back. #define ICONV_ARG2_IS_CONST #endif This doesn't seem to be done here. There seems to be some use of reinterpret_cast which I think should be a static_cast via void*: virtual std::string convert(char_type const *ubegin,char_type const *uend) { .... char const *begin = reinterpret_cast<char const *>(ubegin); "int err" should probably be "errno_t err". There seems to be a "magic constant" of 10 to allow for the difference in size between the input and the output. Some comments would help. For example, to describe the meaning of the return values and error codes from iconv(). Based on that limited look, my view is that the code probably works, but it could be improved in many ways. - What is your evaluation of the documentation? Good enough. - What is your evaluation of the potential usefulness of the library? Useful and overdue. - Did you try to use the library? With what compiler? Did you have any problems? No, I've not compiled anything. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 3 hours reading the docs and looking at a tiny bit of the implementation. - Are you knowledgeable about the problem domain? Not beyond the areas that I have discussed above. > Please explicitly state in your review whether the library should be > accepted. It's borderline. I was going to say "yes, but please consider updating at least the charset conversion functions in the way that I proposed". But then I looked at the source and noted what I think are well-known issues like abuse of union and reinterpret_cast, which have lowered my opinion a bit. And then I've seen some other reviews that have looked at the areas I've not considered (i.e. message translation) and they have been quite critical. Based on all of that, my view has shifted to "no, but this is worthwhile functionality, so please come back when you've resolved some of these concerns". Regards, Phil.

4 9

[locale] Strange(?) result in example code
by Noah Roberts 19 Apr '11

19 Apr '11

#include <boost/locale.hpp> #include <iostream> //#include <ctime> using namespace boost::locale; int main() { generator gen; //std::locale::global(gen("snthsnth")); // no exception std::locale::global(gen("en_US.UTF-8")); double now = time(0); std::cout << "Today is " << as::date << now << std::endl << "Current time is " << as::time << now << std::endl << "The current weekday is " << as::ftime("%A") << now << std::endl; std::cin.get(); } http://cppcms.sourceforge.net/boost_locale/html/formatting_and_parsing.html I get warnings about converting from time_t to double (which I rather expected) and then get basic, double formatted output: Today is 1.3029e+009 Current time is 1.3029e+009 The current weekday is 1.3029e+009

5 14

[locale] Review
by Noah Roberts 19 Apr '11

19 Apr '11

- What is your evaluation of the design? Functions. Seems straight forward to use. - What is your evaluation of the implementation? What I used worked. I did not look over the source. - What is your evaluation of the documentation? Good except that there are at least some errors/inconsistencies (ngettext in messages_formatting.html for example is missing an argument). Also need to be explicit about which version of 3rd party programs are required (see below). - What is your evaluation of the potential usefulness of the library? I'll probably be using it for our product (assuming it plays fine with Qt, which I don't see any reason why not) so I'd say very. - Did you try to use the library? With what compiler? Did you have any problems? Yes. MSVC2010. No problems specific to the library but did have a pretty hard time figuring out which version of gettext was necessary and finding it. Simple search for gettext win32 or windows does not turn up a version compatible with this library (--keyword=translate:1,1t syntax invalid). Had to get the recent MSYS developer toolkit (mingw + msys wasn't even enough). After a couple of hours of searching it seemed to be the only option. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I wrote a simple program and played with a few of the functions. I downloaded and installed various tools that are supposed to help with translating. Basically did a short, 4 hour evaluation of whether I could propose it for use. - Are you knowledgeable about the problem domain? Not as much as I certainly should be. - Should it be in boost? I have some concerns about the fact that it relies so much on 3rd party stuff. The gettext tools are obviously moving targets and not having an easily accessible version of xgettext for Visual Studio users is not an optimal situation. Having to install MinGW and the works shouldn't be required. Various supposed binary downloads of gettext for win32 either are not or are too old. I also found that of the tools listed for working on po files, only one both worked with plural forms and worked on win32. In fact possibly only the one worked with plural forms at all. The fact that this library implements a gettext like setup is nice, but the dependency then upon gettext to provide the source extraction tools and such is unfortunate and could certainly lead to problems where there are version conflicts. Based on my experience I'd say that clearly there are some availability issues in this area for those using Visual Studio. Since gettext is someone else's problem, I don't see how boost can safely make sure the necessary programs are available to anyone using boost. Certainly some better documentation about which version of gettext is being emulated should be included (I looked through the docs and never saw anything specifying version). Once I did find the correct version of the tools (or at least a version that responded as the documentation explained) the system seemed to work out just fine. I would like to see an alternative to a complete msys install (though I personally like to have it around, others on my team find it useless). I would guess that there should be one but I seriously couldn't find it. I would also like to see boost::locale::format work like boost::format. The documentation also calls this thing a printf like utility class but it doesn't, as opposed to boost::format, accept printf format strings. On the other hand, boost::format(translate("%.4g")) % 3.14 worked just fine so I don't know what this locale specific version is providing. All that said, I think it could be a good addition. We certainly need something like it and it at least does what I think I need from such a library.

4 13

[type_traits] Plans to add C++11 type traits?
by Beman Dawes 19 Apr '11

19 Apr '11

Now that C++11 (formerly C++0x) is done, are there any plans to add the type traits to Boost that we don't already have? See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3290.pdf --Beman

4 4

[locale] Review: Tutorial
by Gevorg Voskanyan 19 Apr '11

19 Apr '11

index.html: "Correct case conversion, case folding and normalization." Please insert a link to a resource explaining the difference between case conversion and case folding. std_locales.html: In the first code snippet "std::use_facet<std::ctype>(some_locale)" is wrong. Should be: std::use_facet<std::ctype<char> >(some_locale) "imbued into an iostream" doesn't look OK, especially with 'iostream' in fixed-width font. "imbued into an I/O stream object" perhaps. Such usage of 'iostream' is present on most other pages as well. A link near the "cout.imbue(std::locale("en_US.UTF-8")); ..." example to the "Locale names are not standardized. ..." paragraph would help. Would be good to mention std::has_facet. What is paper_size::inches? I guess it should be measure::inches. The comment below needs to be corrected too. class measure is missing the static std::locale::id id; member print_distance example should use the 'out' object instead of std::cout. "// Set default locale as global" This comment is misleading. The default locale in C++ programs is the 'classic' locale. std::locale("") is the user's preferred locale. Or perhaps we can use the system's default locale term, but I think "user's preferred" is better. formatting_and_parsing.html: Strictly speaking, "the iostream STL library" is not correct formulation. Should be e.g. "the standard I/O streams". why "double now=time(0);" and not "time_t now=time(0);" ? s/tommorrow/tomorrow/ s/display in local time format/display in local time zone/ s/as::locale_time/as::local_time/ s/Locale time is/Local time is/ conversions.html: Add code example calling to_lower and fold_case on "grüßen" to help users understand the difference between the two. messages_formatting.html: s/Is change to/Is changed to/ Is there a default search path for dictionaries (/usr/share/locale under *nix), or should an application always call add_messages_path() ? "The source text is not copied." Sometimes 'not' is highlighted, and sometimes 'is'. So what does it try to say after all? That the provided string argument must not die before the translated string is fetched? s/tanslate/translate/ s/Japaneese/Japanese/ ja << msg missing semicolon s/main()/int main()/ std::wstring msg = translate("Do you want to open the file?").str<wchar_t>(some_locale) missing semicolon s/GNU Gettext catalogs has/GNU Gettext catalogs have/ "is \c n 1 or not" looks like a doxygen formatting problem. Such problems exist in some other places as well. s/Occured/Occurred/ s/managment/management/ "Is there any reason to prefer the Boost.Locale implementation to the original GNU Gettext runtime library? In either case I would probably need some of the GNU tools." Maybe add a c. point about license charset_handling.html: s/does not provides/does not provide/ localized_text_formatting.html: s/when we create a messages/when we create messages/ localized_text_formatting.html: wcout << wformat(L"Today {1,date} I would meet {2} at home") % time(0) % name <<endl missing semicolon int a_and_b = a+b; please change to int a_plus_b = a+b; dates_times_timezones.html: s/they fully aware/they are fully aware/ Or rather, what does 'they' refer to here? s/than setting "current day of week"/then setting "current day of week"/ add << between some_point and " is the " s/We recommended you look/We recommend you to look/ And what date-time range does the ICU backend support? I'd like to echo other reviewers that printing date/time should not print a number by default. s/alway/always/ s/and over that build dates/and over that builds dates/ working_with_multiple_locales.html: s/get.locale_cache_enabled(true);/gen.locale_cache_enabled(true);/ s/std::locale ar=get("ar_EG.UTF-8");/std::locale ar=gen("ar_EG.UTF-8");/ s/as parameters in various functions/as parameters to various functions/ using_localization_backends.html: s/Case handing/Case handling/ recommendations_and_myths.html: s/it probably the most/it is probably the most/ s/and may other applications/and many other applications/ building_boost_locale.html: s/If your icu build in placed/If your icu build is placed/ s/if you relay on auto-linking/if you rely on auto-linking/ appendix.html: "is depend" substitute with "is dependent" or "depends" s/not bring read performance advantage/not bring real performance advantage/ s/would work only of standard facets/would work only if standard facets/ s/Boost locale fully supports/Boost Locale fully supports/ s/may broke/may break/ s/tje/the/ "including all Western, Cyrillic, Hebrew, Thai, Arabic and CJK encodings." Shouldn't be "characters"? s/std::sting/std::string/ s/not indented to be used in production/not intended to be used in production/ General remarks: Usage of comments in code snippets is inconsistent in the sense that sometimes the comment comes after the code is addresses, the other times it comes before. One of those styles should be used all over the place - preferably comments coming first as that is the common practice in other Boost libraries. Would like to see examples of using Boost.Locale facets directly. Would like to see examples of user-defined I/O inserters/extractors that respect the current state of Boost.Locale formatting as altered by manipulators. E.g. a "class money" example which uses the Boost.Locale currency formatting info for its I/O, or a "class bigint" example which uses the Boost.Locale number formatting info for its I/O. Bonus points if they fallback to std facets if corresponding Boost.Locale info is missing from the stream! Thanks, Gevorg

2 4

[locale] Formal review of Boost.Locale library starts tomorrow
by Chad Nelson 19 Apr '11

19 Apr '11

The formal review of the Boost.Locale library by Artyom Beilis starts tomorrow, April 7th, and is scheduled to last through April 16th. *************** * Its Purpose * *************** Boost.Locale provides thorough localization features to C++ programs by way of std::locale facets. Excerpted from the introduction: C++ offers a very good base for localization via the existing C++ locale facets [...] But these are very limited and sometimes buggy by design. Support for localization varies [...], and there are frequently incompatibilities between them. On the other hand, there is a great, well debugged, high quality, widely used ICU library that gives all of the goodies. But it has a very dated API that mimics Java behavior, completely ignores the STL, and provides a useful API only for UTF-16 encoded text, ignoring other popular Unicode encodings like UTF-8 and UTF-32 and limited but still popular national character sets like Latin1. Boost.Locale provides the natural glue between the C++ locales framework, iostreams, and the powerful ICU library. Although it can use the ICU library, it supports several other processing options as well. ******************* * Where to get it * ******************* 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 * ******************** The reviews and all comments should be submitted to the developers list, and the email should have "[locale]" 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? -- Chad Nelson Oak Circle Software, Inc. * * *

17 82

[Filesystem] error including filesystem v3 with icpc -std=c++0x
by Galen Andrew 19 Apr '11

19 Apr '11

Hello, Including boost/filesystem.hpp is giving me errors using Intel compiler in Linux with -std=c++0x that look like boost/filesystem/v3/operations.hpp(303): error: name followed by "::" must be a class or namespace name {detail::copy_file(from, to, copy_option::fail_if_exists);} ^ It compiles fine under g++ -std=c++0x. There are also a plethora of warnings like boost/filesystem/v3/operations.hpp(626): warning #279: controlling expression is constant BOOST_ASSERT(m_imp.get() && "attempt to dereference end iterator"); ^ I'd appreciate any help/ideas. Thanks, Galen

2 1

[locale] Review of Boost.Locale library
by Edward Diener 18 Apr '11

18 Apr '11

This is my review of the Boost Locale library. It is divided into two parts, a review of the documentation and a review of the library itself. I will refer to Boost Locale as just Locale, with a capital L, for the remainder of this review. I will use the term C++ locale to refer to the C++ standard library locale implementation. 1. Documentation The layout of the main page is decent, but I would have expected a discussion there, or as a first topic, of what Locale brings that the C++ standard locale does not have. I was disappointed not to find such a discussion. The documentation topics are specified as Tutorials. I do not think they are Tutorials, which is fine with me since I much prefer topics rather than exmaples when trying to understand a library. a. Introduction to C++ Standard Library localization support The common critical problems of the C++ locale portion of the standard library seems spurious to me. The problems mentioned are really about implementations or programmer usage, not the C++ locale library itself. The only valid problem mentioned I find there is that the C++ standard library did not attempt to standardize any locale names. This makes using C++ locales based on locale names non-portable. Unfortunately the issues there make a very weak argument for the Locale library itself. b. Locale generation I would have liked it if the doc here specified where one finds valid lists of language, country, encoding, and variant which make up a locale name. Without this information, the one valid problem mentioned regarding C++ locale is also a problem with Locale. The note about wide strings and 8-bit encoding makes no sense to me at all. If I am using a wide string encoding, why would I not be using wide string iostreams ? c. Collation There is no explanation about what 'collation' is about. This is very disappointing, as it makes the rest of the discussion difficult to follow. The examples were worthless to me since the classes involved have not been mentioned or discussed. Also the examples are woefully incomplete even in what they represent. This is one reason why I dislike documentation which attempts to teach by example. It always seems to assume that if it throws examples at the reader before anything about the classes/templates in the examples have been mentioned, that this is somehow an effective way of learning a library. Instead it just creates confusion and serves unfortunately as a way by which a library implementer does not have to explain how the classes in his library actually work or relate to each other. d. Conversions "You may notice that there are existing functions to_upper and to_lower in the Boost.StringAlgo library. The difference is that these function operate over an entire string instead of performing incorrect character-by-character conversions." In he second sentence, "these function" gramatically refers to the functions in Boost.StringAlgo, but I doubt that is what is meant. I do not understand how these conversion functions use a locale. The example gives: boost::locale::to_upper(gruben) used in a stream. Is this function using the locale imbued in the iostream ? Again this is what happens when one creates examples without first explaining topics in a rational and orderly way. e. Numbers, Time and Currency formatting and parsing A bunch of ICU flags are mentioned but with no indication about how these are supposed to be used by iostreams. These flags look like they are supposed to be used by C-like format printf statements but since Locale uses iostreams I can not understand their purpose with Locale. f. Messages Formatting (Translation) Gnu gettext should be explained when it interfaces with Locale. Just telling someone to learn Gnu gettext is not adequate. Other than that the explanation is pretty thorough. g. Character Set Conversions An explanation of what character sets are, and what character set conversions entail, should be the beginning of this documentation. h. Localized Text Formatting "Each format specifier is enclosed within {} brackets.." These are not "brackets" but "braces". Brackets are '[]'. i. In general It is confusing to me how generated locales affect the functionality of the different sections presented under 'Using Boost.Locale'. In a number of situations I am looking at classes or functions and I have no idea how these pick up a locale. I do understand that when used with iostreams the locale is determined by the locale imbued in the iostream. But outside of iostreams I do not understand from the documentation what locale is being used. If it is the C++ global locale, the documentation should say so. This entire issue about how locales are actually being used in various parts of the library should be explained as part of an overall explanation of the library. I find this good overall explanation of the library the major flaw in the documentation. The documentation itself is well-ordered and the explanations generally decent. But I find it next to impossible to understand a library when the documentation does not take the time to explain concepts/topics and instead substititutes exmaples as a means of understaning a library. 2. Library itself I did not look at the code itself and have no interest in critiquing the source. Others do this much better than I ever can. The library offers a great deal of functionality and a great positive of the library is that it works with multiple backends and brings those backends into the C++ world. In general I think that using the global locale is a bad programming practice when one specifically intends to work with locales. Unfortunately it was hard for me to understand how individual locales are used with each of the parts of the library from the documentation. But I will assume for the time being, because it seems the only correct design, that each part of the library which is documented can work with some non-global locale which is created and passed around as necessary. The only design flaw which I could discover in the library was in message translation. The fact that translation always begin from English ( or perhaps some other narrow character language ) to something else is horrendous. I can understand that the Locale implementer wanted to use something popular and that already exists, but an idea so tremendously flawed in its conception either needs to be changed, if possible, or discarded for something better. I do understand that translation is just one part of this large library, but I hope that the implementer undestands how ridiculous it is to assume that non-English programmers are going to be willing to translate from English to language X rather than from their own language to language X. I am assuming that all other parts of the library support both narrow character encodings and wide character encodings fully, and that at least UTF-16 is always supported using wide characters. It was really hard for me to make out from the docs whether or not this was the case. I believe a great deal of work was put into the library, and that this work is invaluable in bringing locale usage into C++ in a better way than it is currently supported in C++ locale. But I would have to vote "No" that the library should be accepted into Boost at the current time, with some provisos which would most likely gain my own change to a "Yes" vote in the future. 1) The documentation should explain the differences and improvements of Locale over C++ locale in a good general way. 2) The documentation should explain the use of locales for each of the topics. 3) A number of topics should discuss what they are about in general, and more time should be given to discuss how the classes/templates relate to each other. 4) Message translation should be reconsidered. I don't mean to say that the way it is done is enough to have the library rejected, but I can not believe that it is not a flawed system no matter what the popularity of Gnu gettext might be. My major trouble with the library, which has led to my "No" vote, is that I can not really understand how to use the library from the documentation or what the library really offers over and above C++ locales. I realize the library programmer may not himself be a native English speaker, but if I can not really understand a library from its documentation in a way that makes sense to me I can not vote for its inclusion into Boost. I strongly suspect that if I were to understand the functionality of the library through a more rigorous explanation of its topics, and each topics relationship to a locale class and various encodings, I mught well vote for its inclusion into Boost. But for now, and in the state which the documentation resides for me, I can not do so. So I hope this review will be undersstood at least partially as a request to improve the docs as much as anything else.

6 10

[locale] Review. Internationalization library?
by Vicente BOTET 18 Apr '11

18 Apr '11

Hi, from the name of the library Boost.Locale and the section "What is Boost.Locale?" I didn't get enough information about the motivation and the scope of the library. I think that maybe be this is due to the fact that the dependency to ICU hides a lot of features the library provides. I think that a direct link to what ICU is is a must, but I would expect a little bit more than "On the other hand, there is a great, well debugged, high quality, widely used ICU library that gives all of the goodies" in this section. >From my side if the library was named Boost.Internationalization I'm sure I would had take a look long time ago. Do you think that this renaming (or a shorter one) will cover the whole library or there are parts of the library that don't fall in the internationalization domain? As the review period has been extended, I will try to review at least the documentation. Best, Vicente

3 17

Would a construct_cast<T>(u..) be useful?
by Johannes Schaub (litb) 17 Apr '11

17 Apr '11

I was wondering whether it makes sense to have another kind of cast in boost, which behaves like the following: template<typename T, typename ...U> T construct_cast(U &&... u) { T t(std::forward<U>(u)...); return t; } This cast works if std::is_constructible<T, U...>::value is true, and fails if it is false. It presents a slightly more explicit form of boost::implicit_cast<T> in that explicit constructors of T are allowed, and for the case of a single- elemented parameter pack, explicit conversion functions of U converting to "T" are allowed. It does not allow non-implicit conversions like void* -> nonvoid*, Base* -> Derived*. Advantages over not having construct_cast: - Converting expressions to "bool" by use of "contextually converted to bool", without using things like "!!x" or "x ? true : false" (the first may trigger user defined opeators for "operator!", which may not be desired). - No need for introducing a temporary named variable like the above "t". - If all you want is to consider contexual conversions, explicit constructors and conversion functions, this can be used. All these conversion seem "safe", compared to the set of conversions allowed by T(u) and even static_cast<T>(u). What do you think about it?

2 1

BGL
by Sultana Rashid 17 Apr '11

17 Apr '11

Hi all, I have submitted two proposals to Boost.I am very interested in C++ works and algorithms,so I submitted only for Boost projects.I met an accident after proposal submission so that I could not refine my project ideas.Now I am well and have enough free time to interact with mentors and do the necessary works.My proposals can be found here: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/monowara… http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/monowara… Now I am writing something about one of my algorithms' prospective design. *Dinitz blocking max flow algorithm:* *Input:* Graph& g .A directed graph. The graph's type will be a model of VertexListGraph and IncidenceGraph. *Input:* *source node* which is a vertex. Its type will be graph's vertex descriptor type. *Input:* *sink node* ,its type will be same as source node. *Input:* capacity map(CapacityEdgeMap cap),the edge capacity property map. The type must be a model of a constant Lvalue Property Map. The key type of the map must be the graph's edge descriptor type. Default: get(edge_capacity, g) *Input:* reverse edge map(ReverseEdgeMap rev) An edge property map that maps every edge (u,v) in the graph to the reverse edge (v,u). The map must be a model of constant Lvalue Property Map. The key type of the map must be the graph's edge descriptor type. Default: get(edge_reverse, g) *Input:*residual capacity map(ResidualCapacityEdgeMap res) ,This maps edges to their residual capacity. The type must be a model of a mutable Lvalue Property Map. The key type of the map must be the graph's edge descriptor type. Default: get(edge_residual_capacity, g) At first the whole capacity will be the residual capacity,then after every phase of calculation it will act as output. *Input:* vertex index(VertexIndexMap index_map) Maps each vertex of the graph to a unique integer in the range [0, num_vertices(g)). The map must be a model of constant LvaluePropertyMap. The key type of the map must be the graph's vertex descriptor type. Default: get(vertex_index, g) *Output:*The total flow of the network,flow in every iteration and min cut. *** User will be able to use the algorithm in two ways, named parameter version and non-named parameter version.* *** In named parameter version,explicit inputs will be the graph,source and sink node.Other will be default params. * *** In non-named parameter version,all will be explicitly input. * * * I studied already implemented flow algorithms and took help.But I am in confusion about UTIL parameters.* * If I get help or advice ,I'll try my best to refine my ideas about implementation and design.I studied all the relevant algorithms and wish to write all after getting feedback.I am not sure what to write about algorithm design.Would I write details how input and output will work as how min cut will be got or how flow will be determined? Please give me some hints.Hope to get some help.If I am not suitable for GSoC,however I want to know and implement. Mariya

2 1

Proposal Complete
by Sitesh Shrivastava 17 Apr '11

17 Apr '11

Dear Andrew, First of all, I'd like to thanks for letting me complete the timeline and other missing details in the proposal. I have almost completed my proposal. Please have a review of it and do let me know in case modification is required. Proposal URL: http://socghop.appspot.com/gsoc/proposal/review/google/gsoc2011/sitz/3001 --Thanks & Regards, *Sitesh Shrivastava* Junior Undergraduate, BIT Mesra Phone: *+91-9470521313 *E-Mail: *siteshshrivastava(a)gmail.com *Home-Page: *https://sites.google.com/site/siteshshrivastava** *

1 0

[locale] Off-list review of Boost.Locale library
by Chad Nelson 17 Apr '11

17 Apr '11

Date: Sat, 16 Apr 2011 15:40:53 +0400 From: <steve.bush(a)neosys.com> --- What is your evaluation of the design? Very good to start with since leveraging locale for i18n/l10n is a great rallying point for developers. Translate GETTEXT might be better in a separate library to increase degrees of freedom and reduce coupling. --- What is your evaluation of the implementation? The wrapper/backend strategy provides immediate benefit while leaving the door open to progressive reimplementation. Since it is a wrapper, could PARTS of it be implemented as a header only? --- What is your evaluation of the documentation? The documentation is more than good enough to start with considering this library's potential usefulness. --- What is your evaluation of the potential usefulness of the library? This library is potentially *extremely* useful because it LEVERAGES an important chunk of standard C++ that is sadly underutilised merely due to a few design and implementation flaws. This library has potential something of the order of Boost.FileSystem. This is a VERY strategic library and any shortcomings will be resolved with time. --- Did you try to use the library? With what compiler? Did you have any problems? Didn't try. --- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I meticulously read all documentation several times. --- Are you knowledgeable about the problem domain? Yes, we have used similar technique for Exodus http://devwiki.neosys.com and will replace those with Boost.Locale if and when it becomes available. --- Do you think the library should be accepted as a Boost library? YES - It is relatively small but has a massive effect. It has a very low cost/benefit ratio since it leverages long standing classic C++ locale design/skills.

3 2

doxygen limitations
by Vicente BOTET 17 Apr '11

17 Apr '11

Hi, I would like to comment some limitations I have found while trying to generate the reference manual from the code comments using doxygen. 1. C++0x explicit operators are not documented as explicit with a warning explicit operator underlying_type const&() const ^^^^ gives operator underlying_type const &() const; 2. ::type misplaced when inheriting from a metafunction template < typename Final, typename UT, typename MetaMixinSeq=boost::mpl::vector0<>, typename Base=base_opaque_type > class new_class : public linear_hierarchy::type { gives template, typename Base = base_opaque_type> class new_class : public linear_hierarchy::type< MetaMixinSeq, Final, Base > { // ^^^^ 3. The base type is missing if the class is not documented elsewhere. This applies to other classes defined in other libraries in Boost or the Stl, but also when we use parameterized inheritance. template struct inherited_from_underlying { template struct type : Base { // Parameterized inheritance }; }; gives template struct inherited_from_underlying { // member classes/structs/unions template struct type { }; }; 4. When the brief comment takes only one line the comment is included on the Synopsis and nothing on the description section //! the underlying type typedef UT underlying_type; generates typedef UT underlying_type; // the underlying type 5. The classes are sometimes implicitly prefixed with his namespace template < typename UT, typename Tag=void, typename Bool=bool, typename MetaMixinSeq=boost::mpl::vector0<>, typename Base=base_private_opaque_type > class private_opaque_type : public private_opaque_class< private_opaque_type, UT, Bool, MetaMixinSeq, Base> gives template, typename Base = base_private_opaque_type> class private_opaque_type : public boost::opaque::private_opaque_class< private_opaque_type< UT, Tag, Bool, MetaMixinSeq, Base >, UT, Bool, MetaMixinSeq, Base > Do you have a workaround to some of these issues? What about creating a specific doxygen limitations and workarounds wiki page? Is there a possibility that the generated html goes to a single reference html file? Best, Vicente P.S. You can see directly some real examples on the documentation of Boost.Opaque https://svn.boost.org/svn/boost/sandbox/opaque/libs/opaque/doc/html/index.h….

3 5

[locale] Review of the proposed Boost.Locale library
by Volker Lukas 17 Apr '11

17 Apr '11

Hello, this is my review of the Locale library proposed for inclusion in Boost. I vote to accept the proposed Boost.Locale as a Boost library. - What is your evaluation of the design? The library is nicely structured into individual components, as far as I can infer from the documentation and having a glance at some of the source files. I like that it is possible to use different backends, utilizing the large ICU library when available. - What is your evaluation of the implementation? I was having only a superficial look at some of the source files, so I can not comment much. What I have seen looks clean to me. While reading the source code I think I could benefit from even more code comments. There are a lot already, but on the other hand there exists for example a source file libs/locale/src/shared/mo_lambda.cpp apparently containing a whole state machine or something without any word how it is used. I also stumbled over an odd comment in file libs/locale/src/std/numeric.cpp in line 163: "// workaround common bug - substitute NBSP with ordinary space". As a reader who did not already write the code I can not infer much from comments such as this one - I mean "What is the common bug then?" If this comment refers to the situation that e.g. the locale implementation of GCCs standard library implementation generates invalid UTF-8 when using NBSP as thousands seperator, then the comment should say that. Well, my point about comments is a minor issue of course. I do not suggest that the author goes over all the code again just to add or change comments. I am a bit worried over the size of the libraries binary. On GNU/Linux x86_64 the built libboost_locale.so is almost 10MB large and codesize according to the "size" utility is almost 1MB. This comes in addition to the underlying ICU library. Is there any potential for reducing codesize? Due to the same concern about codesize I have also one concrete suggestion relating to the comparator template of the collation component. I suggest to not make the default comparision level a template parameter, instead to store it as a member. This way, when instantiating container templates the number of instantiations can be kept down. Or am I mistaken in thinking this would lead to more compact code? - What is your evaluation of the documentation? It is nicely structured. I could easily find the documentation for any specific component I was using and the documentation is also very helpful if you have a task at hand and want to find out which component to use (and whether such a component is available in the proposed Boost.Locale). There are some issues I have: Phrasing is sometime odd. For example right in the beginning, under the headline "What is Boost.Locale" there is a sentence which reads "C++ offers a very good base for localization via the existing C++ locale facets std::num_put, std::ctype, std::collate etc. But these are very limited and sometimes buggy by design." I can only guess what that means. Superficially it seems like a contradiction to me, something which is excellent can not be buggy by design, not even sometimes. Okay, minor issue again, it just stands out because it is only the fourth or fifth sentence or so. There are some typos (I guess) where it is important to be correct: Under "Messages Formatting (Translation)", subheading "Indirect Message Translation" all functions are documented as "The source text is not copied.". From the emphasis in the original document I think I can conclude that some of these functions copy and some do not. The reference section of the documentation should document the requirements on the CharType which many functions/classes are parameterized upon (can it be char/wchar_t only?). The reference documentation for token_iterator and break_iterator should not have individual entries for operator++, operator--, operator== and other operators which are always required for iterators, unless the documentation adds information. Instead, it should just be stated to which iterator concepts these templates conform. Documentation for the dereferening operators (operator*) of these templates states that the underlying sequences iterated over can not be modified with these operators. As this is the case, could a usage hint be incorporated stating that users should always use const_iterators as arguments to these templates? If a user sometimes employs for example std::string::iterator and sometimes std::string::const_iterator this would lead to unnecessary code bloat. Also, operator-> is missing from these templates. - What is your evaluation of the potential usefulness of the library? It is potentially very useful. The only objection I could conceive of is that ICU already provides much of the functionality of Boost.Locale. This library also duplicates functionality of Matthew Wilsons excellent Fastformat library (http://fastformat.sourceforge.net/) though the latter does not feature localization support as complete as that of the proposed Boost.Locale. - Did you try to use the library? With what compiler? Did you have any problems? I used the CMake way to build this library on an Opensuse system on x86_64. Compiler is GCC 4.5.1 (or a Svn snapshot roughly corresponding). The Boost version built against is 1.46.1, as delivered by Opensuse. I did not encounter any problems building the library. I played around with some of the components of the library and ran the supplied test cases. There is one inconsistency I noted, the following program generates output "Currency: $100.11" when the environment variable LANG is set to "en_US.UTF-8" and variable LC_MONETARY is set to "de_DE.UTF-8". Shouldn't the library honor LC_MONETARY? If LANG is set to "de_DE.UTF-8" "Currency: 100,11 €" is put out. Program: ------------------------------------------------- #include <ios> #include <iostream> #include <ostream> #include <locale> #include "boost/locale.hpp" int main() { namespace loc = boost::locale; using std::cout; loc::generator gen; cout.imbue(gen("")); cout << "Currency: " << loc::as::currency << 100.11 << '\n'; } ------------------------------------------------- - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Reading the tuturial section of the Documentation. Glancing over the reference section. I also had a look at some of the source files, but only superficially. - Are you knowledgeable about the problem domain? Only marginally. With best regards, Volker Lukas

2 1

[locale] Review: Build
by Gevorg Voskanyan 17 Apr '11

17 Apr '11

build/Jamfile.v2: line 18: s/Feaures/Features line 130: There should be a space between '!' and '<target-os>cygwin', otherwise the whole condition will never evaluate to true line 132: s/need/needs/ . Also it can be equivalently replaced with just: EXIT "error: Boost.Locale needs either iconv or ICU library to be built." ; line 200: doesn't posix backend work for BSDs other than darwin? line 283: <link>shared:<define>BOOST_LOCALE_DYN_LINK=1 should be present in usage requirements too. The same applies to <threading>multi as well. lines 275, 282: what's the reason for commenting build_options and having <conditional>@configure instead? line 288: Being a vim user myself I appreciate this, but in general tabs are not allowed in code per Boost's development policy. Users of other editors would not be happy with tabs here :) General remarks: As a Boost.Build user I would see it very beneficial when using Boost.Locale to be able to have ICU build from source with BB just like the other 3rd party libraries commonly are. For it to work Boost.Locale Jamfile can check if a project /icu is available, and if so use /icu//icu as source and skip ICU configuration checking together with options for linking to prebuilt ICU. I can prepare and propose a patch for this if that scheme is OK with you. Examples and performance benchmarks should have Jamfiles too. Gevorg

2 6

SFINAE yes_type and no_type
by Jeroen Habraken 16 Apr '11

16 Apr '11

Hi, Is there a specific yes_type and no_type inside boost that I should be using when writing a SFINAE test? There seem to be quite a few defined already and reinventing the wheel (albeit it being trivial) again doesn't make sense. Regards, Jeroen

6 9

[GSoC] Reviewing
by Andrew Sutton 16 Apr '11

16 Apr '11

We have a little less than a week to finalize the set of 10 accepted projects. I've made tentative assignments to the top 10 projects that have a single willing mentor. There are two proposals with two mentors, that I did not assign a mentor to. If you are one of the mentors, you'll be getting a separate email, off list :) There are two highly rated proposals without mentors. I'm trying to work out what to do with those also. If you don't like your tentative assignment, let me know. There are 15-20 proposals that haven't been rated. I know that some are waiting on further input, but we should at least have initial ratings by the end of the week. Also, please check with the students of your highest rated proposals to see if they submitted proposals to other projects. I have to sit thru the duplication meeting next week and would like to know in advance if we're in competition with other organizations. Thanks, Andrew

1 0

[random] example code fails inside struct
by Beman Dawes 16 Apr '11

16 Apr '11

struct X { boost::mt19937 rng; boost::uniform_int<> million(1,1000000); // VC++ 10 error C2059: syntax error : 'constant' boost::variate_generator<boost::mt19937&, boost::uniform_int<> > random_value(rng, million); }; Why does the example code from the docs fail to compile when placed inside a struct or class? What am I missing? --Beman

3 4

Changesign function and nonfinite facets added to Boost.Math
by Paul A. Bristow 16 Apr '11

16 Apr '11

I've just added changesign function and nonfinite facets to Boost.Math in boost-trunk. These functions were part of the original floating-point collection written by Johan Rade but were previously only available from Spirit in boost-sandbox. Making them First Class citizens in Boost.Math will allow portable input/output of infinity and NaN, including use of lexical cast, archiving and serialization. Multiplatform testing of these new features should start soon. I hope this will not have any unwanted side effects - I'm sure you'll shout if it does. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

1 0

[serialization] Add UTF-8 BOM support to xml_warchive
by Tijmen van Voorthuijsen 15 Apr '11

15 Apr '11

Hi, Recently I ran into the problem that the boost::serialization library could not handle XML files which contain the three UTF-8 BOM (Byte Order Mark) bytes. The serialization library creates XML files without the BOM bytes but when saving such files in an external Windows program, for example XML Notepad, these bytes are automatically added. Thereafter the XML file cannot be read anymore by the boost::serialization library. According to Wikipedia http://en.wikipedia.org/wiki/Byte_order_mark the UTF-8 BOM is optional and therefore creating XML files without the BOM bytes is all right. However, the reading should extended and be able to handle both types, files with and without the BOM. I propose to enhance the xml_warchive and text_warchive for reading with support of the BOM bytes. Example: namespace { const wchar_t g_cchUtf8Bom1 = 0xEF; const wchar_t g_cchUtf8Bom2 = 0xBB; const wchar_t g_cchUtf8Bom3 = 0xBF; } void CheckAndCorrectUtf8Bom(std::wifstream* pifs) { _ASSERT_POINTER(pifs); wchar_t chUtf8Bom1 = 0; wchar_t chUtf8Bom2 = 0; wchar_t chUtf8Bom3 = 0; chUtf8Bom1 = pifs->peek(); if (chUtf8Bom1 == g_cchUtf8Bom1) { *pifs >> chUtf8Bom1; _ASSERT(chUtf8Bom1 == g_cchUtf8Bom1); *pifs >> chUtf8Bom2; _ASSERT(chUtf8Bom2 == g_cchUtf8Bom2); *pifs >> chUtf8Bom3; _ASSERT(chUtf8Bom3 == g_cchUtf8Bom3); } else { // Reset to start of the stream pifs->seekg(0, std::ios_base::beg); } } Kind regards, Tijmen van Voorthuijsen ----------------------------------------------------------------------------------- T. van Voorthuijsen Senior System Engineer Noldus Information Technology bv Nieuwe Kanaal 5 P.O. Box 268 6700 AG Wageningen The Netherlands Phone: +31-(0)317-473300 Fax: +31-(0)317-424496 E-mail: T.van.Voorthuijsen(a)Noldus.nl<mailto:T.van.Voorthuijsen@Noldus.nl> Web: www.noldus.com<http://www.noldus.com>

3 2

[MSM] Interrupt anonymous transitions or blocking process_events?
by Mathias A 15 Apr '11

15 Apr '11

Hi there! I have been experimenting with the MSM (Meta State Machine) and I think it is a very nice tool! After reading and trying most of the example code regarding the MSM I present to you my problem. How do I interrupt blocking calls or long running states with anonymous transitions? Ok, here is my story. Regarding "Defining a submachine" in the docs (http://www.boost.org/doc/libs/1_46_1/libs/msm/doc/HTML/ch03s02.html#d0e597) and supplied source code example (http://www.boost.org/doc/libs/1_46_1/libs/msm/doc/HTML/examples/CompositeTu…) Let's say that this was a real CD player then the player would change to the next song by itself. It would not rely on the user pushing the Next button to change song. Now, if I implement the transition table like this: struct transition_table : mpl::vector4 // Start Event Next Action Guard -----------+-------------+---------+---------------------+----------------------+ a_row < Song1 , none , Song2 , &pl::start_next_song >, a_row < Song2 , PreviousSong, Song1 , &pl::start_prev_song >, a_row < Song2 , none , Song3 , &pl::start_next_song >, a_row < Song3 , PreviousSong, Song2 , &pl::start_prev_song > +---------+-------------+---------+---------------------+----------------------+ > {}; Note the "none" for anonymous transitions. 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". In multi threaded mode (no complete source code for this here sorry. with mutex protected access to process_event) thread 1: lock(mutex) p.process_event(play()); lock.unlock(); thread 2: wait a few ms so we are in the middle of playing a song lock(mutex) p.process_event(stop()); lock.unlock(); 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());. 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. A not so elegant workaround: In thread 2 access the Playing state directly and set a bool variable. (bool externalStop_;) Add a guard to each anonymous transition checking if the source state has externalStop_ == true and stop the transition. The Playing state can then create a stop event and then call process_event(stop()) by itself. And we have successfully injected a stop event. Summary: I cannot seem to get round the blocking call using only the transition table. I really hope it can be done in a more elegant way than I did in the workaround. Any suggestions on how to do this? Thank you! Best regards, Mathias

1 0

[locale] localization_backend_manager interface issue
by Max Sobolev 15 Apr '11

15 Apr '11

> std::auto_ptr<localization_backend> > localization_backend_manager::get() const; Class localization_backend_manager is marked as BOOST_LOCALE_DECL. This is hinting at placing instances of the class in a standalone shared library without problems. But here it is: using std::auto_ptr<> in interfaces is an error (Due to possibility of placing instances of classes in dynamic libraries). Dynamic library that contain your class might be compiled in debug / release / another mode, but client's code might have an alternative heap (because it use another C++ Run Time system) with an alternative heap manager. std::auto_ptr<> doesn't carrying *deleter* with a raw pointer of the allocated object, as boost::scoped_ptr<>, boost::shared_ptr<> or c++0x's std::unique_ptr<> does. Memory allocated from one heap might be "released" by foreign heap manager! :-/ See Sutter/Alexandrescu recommendation do not use std::auto_ptr<> (in ISBN: 9780321113580, C++ Coding Standards, "Rule 60: Avoid allocating and deallocating memory in different modules") and problem description (in ISBN: 9780201604641, Douglas Schmidt, Stephen Huston - C++ Network Programming [Volume 2] Chapter 5, "Sidebar 29: Portable Heap Operations with ACE") ..so change std::auto_ptr<> to some of the more safe smart pointer. > void localization_backend_manager::select( > std::string const& backend_name, > locale_category_type category = all_categories); Why you don't use enums instead of std::string and locale_category_type? (latter is unsigned, actually). So this code is permissible: boost::locale::localization_backend_manager::global().select("...", static_cast<unsigned>(std::rand())); std::string as opposed to ((emulated) scoped) enum implies discarded static type checking plus run-time overhead (due to *run-time* "type" checking, as i guess). unsigned type provides a wider "supertype" for argument than necessary -- - Do you speak English? Мужик с глубоким вздохом: - Yes I do. А хули толку?

5 5

[locale] Formal review of Boost.Local library -- need reviews!
by Chad Nelson 15 Apr '11

15 Apr '11

The final day of the Boost.Locale formal review is scheduled to be Saturday, and though there has been a lot of discussion, so far only one complete review has been submitted. If you're planning to review it, please don't delay. 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. * * *

8 11

Fw: [locale] Formal review of Boost.Locale library
by Chad Nelson 15 Apr '11

15 Apr '11

Begin forwarded message: Date: Thu, 07 Apr 2011 08:49:20 +0900 From: Darren Cook <darren(a)dcook.org> Subject: [locale] Formal review of Boost.Locale library Hello, I'm not on the devel list but just had a look at the Boost.Locale library documentation. Feel free to forward this to the list, or discard it. > - What is your evaluation of the documentation? * No prev/next page links [This should be fixed ASAP, as it discourages evaluating the library] * Confusing first page as it seems to only talk about other libraries, not the one in question. (?) * The examples are not motivating, and just end up looking complex. * I'd have liked to see examples in more languages, in particular some Asian languages, to comfort me that the library has taken their issues into consideration. If the itch being scratched here is just for a couple of European languages then the library may have design flaws. * The backends page ( http://cppcms.sourceforge.net/boost_locale/html/using_localization_backends… ) looks interesting, and may be the start of justifying the reason for this library to exist. It could be expanded with something more concrete: complete examples of doing something useful with different backends, with timings and exe sizes we could compare. > - What is your evaluation of the potential usefulness of the > library? I would choose to use ICU directly, as I couldn't see a reason not to, and I'd be concerned that the wrapper would not have wrapped some obscure function in ICU that I find I end up needing. > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? A quick reading. > - Are you knowledgeable about the problem domain? I've used ICU (it is essential in some situations), though possibly not from C/C++. Darren -- Darren Cook, Software Researcher/Developer http://dcook.org/work/ (About me and my work) http://dcook.org/blogs.html (My blogs and articles)

19 52

Re: [boost] [chrono] Compiler errors for mpl/abs.hpp
by Vicente BOTET 15 Apr '11

15 Apr '11

Hi, since Boost.Chrono was accepted I have moved to the trunk and the release branch. There are a lot of file in the sandbox that have been changed since. In particular the error comes from some compilers don't supporting nested value arithmetic in templates. To workaround this the trunk contain instead template<> struct abs_impl { #if defined(BOOST_MPL_CFG_NO_NESTED_VALUE_ARITHMETIC_2) template< typename N > struct apply : aux::abs_wknd< typename N::value_type, N::value > #else template< typename N > struct apply : integral_c< typename N::value_type, ((N::value < 0) ? (-N::value) : N::value ) > #endif { }; }; For this reason a suggest you to move to the trunk or the release branch. I will remove the Chrono sandbox as soon as the release 1.47 is out. Best, Vicente Message du 15/04/11 00:29 > De : "lcaminiti" > A : boost(a)lists.boost.org > Copie à : > Objet : [boost] [chrono] Compiler errors for mpl/abs.hpp > > Hello all, > > I am trying to compile the example below on MSVC using Boost.Chrono > (headers-only) from the sandbox but I am getting some compiler errors. > > What am I doing wrong? > > Thank you very much. > --Lorenzo > > #define BOOST_CHRONO_INLINED > #include > #include > #include > #include > #include > #include > #include > > int main(int argc, char* argv[]) { > assert(argc == 2); > unsigned long n = sqrt(double(atol(argv[1]))); > > using boost::phoenix::ref; > using boost::phoenix::arg_names::_1; > > double sum = 0.0; > int factor = 1; > > std::vector v(n); > std::fill(v.begin(), v.end(), 1.0); > > boost::chrono::duration sec; > for (unsigned long i = 0; i < n; ++i) { > boost::chrono::system_clock::time_point start = > boost::chrono::system_clock::now(); > std::for_each(v.begin(), v.end(), ( > ref(sum) += factor * _1 > )); > sec += boost::chrono::system_clock::now() - start; > } > std::cout << sec.count() << std::endl; > > assert(sum == n * n); > return 0; > } > > E:\sandbox\boost-sandbox-local\libs\local\example>cl /EHs /Ox /I..\..\.. > /I"c:\P > rogram Files\boost\boost_1_46_1" /I..\..\..\..\boost-sandbox-chrono.x > benchmark_ > boost_phoenix.cpp > Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for > 80x86 > Copyright (C) Microsoft Corporation. All rights reserved. > > benchmark_boost_phoenix.cpp > ..\..\..\..\boost-sandbox-chrono.x\boost/mpl/abs.hpp(72) : error C2143: > syntax e > rror : missing ',' before ')' > ..\..\..\..\boost-sandbox-chrono.x\boost/mpl/abs.hpp(75) : see > reference > to class template instantiation 'boost::mpl::abs_impl::apply' being > compiled > ..\..\..\..\boost-sandbox-chrono.x\boost/mpl/abs.hpp(72) : error C2059: > syntax e > rror : ')' > ..\..\..\..\boost-sandbox-chrono.x\boost/mpl/abs.hpp(74) : error C2143: > syntax e > rror : missing ';' before '{' > ..\..\..\..\boost-sandbox-chrono.x\boost/mpl/abs.hpp(75) : error C2143: > syntax e > rror : missing ';' before '}' > ..\..\..\..\boost-sandbox-chrono.x\boost/mpl/abs.hpp(72) : error C2143: > syntax e > rror : missing ';' before '}' > ..\..\..\..\boost-sandbox-chrono.x\boost/mpl/abs.hpp(72) : fatal error > C1004: un > expected end-of-file found > > > -- > View this message in context: http://boost.2283326.n4.nabble.com/boost-chrono-Compiler-errors-for-mpl-abs… > Sent from the Boost - Dev mailing list archive at Nabble.com. > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

[move] Declarations of the copy constructor and copy-assign operator produced by BOOST_MOVABLE_BUT_NOT_COPYABLE
by Joseph Trebbien 15 Apr '11

15 Apr '11

Looking through the sources of Boost.Move in trunk, I am wondering about a couple of lines in <boost/move/move.hpp> that are part of the expansion of BOOST_MOVABLE_BUT_NOT_COPYABLE when BOOST_NO_RVALUE_REFERENCES is defined: #define BOOST_MOVABLE_BUT_NOT_COPYABLE(TYPE)\ private:\ TYPE(TYPE &);\ TYPE& operator=(TYPE &);\ public:\ operator ::boost::rv<TYPE>&() \ { return *static_cast< ::boost::rv<TYPE>* >(this); }\ operator const ::boost::rv<TYPE>&() const \ { return *static_cast<const ::boost::rv<TYPE>* >(this); }\ private:\ // Why do the declarations of the copy constructor and copy-assign operator overload not take a const-reference to TYPE? When BOOST_NO_RVALUE_REFERENCES is not defined, they do: #define BOOST_MOVABLE_BUT_NOT_COPYABLE(TYPE)\ public:\ typedef int boost_move_emulation_t;\ private:\ TYPE(const TYPE &);\ TYPE& operator=(const TYPE &);\ // Joseph Trebbien

2 1

[chrono] Compiler errors for mpl/abs.hpp
by lcaminiti 14 Apr '11

14 Apr '11

Hello all, I am trying to compile the example below on MSVC using Boost.Chrono (headers-only) from the sandbox but I am getting some compiler errors. What am I doing wrong? Thank you very much. --Lorenzo #define BOOST_CHRONO_INLINED #include <boost/chrono.hpp> #include <boost/spirit/include/phoenix.hpp> #include #include #include #include #include int main(int argc, char* argv[]) { assert(argc == 2); unsigned long n = sqrt(double(atol(argv[1]))); using boost::phoenix::ref; using boost::phoenix::arg_names::_1; double sum = 0.0; int factor = 1; std::vector v(n); std::fill(v.begin(), v.end(), 1.0); boost::chrono::duration sec; for (unsigned long i = 0; i < n; ++i) { boost::chrono::system_clock::time_point start = boost::chrono::system_clock::now(); std::for_each(v.begin(), v.end(), ( ref(sum) += factor * _1 )); sec += boost::chrono::system_clock::now() - start; } std::cout << sec.count() << std::endl; assert(sum == n * n); return 0; } E:\sandbox\boost-sandbox-local\libs\local\example>cl /EHs /Ox /I..\..\.. /I"c:\P rogram Files\boost\boost_1_46_1" /I..\..\..\..\boost-sandbox-chrono.x benchmark_ boost_phoenix.cpp Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. benchmark_boost_phoenix.cpp ..\..\..\..\boost-sandbox-chrono.x\boost/mpl/abs.hpp(72) : error C2143: syntax e rror : missing ',' before ')' ..\..\..\..\boost-sandbox-chrono.x\boost/mpl/abs.hpp(75) : see reference to class template instantiation 'boost::mpl::abs_impl::apply' being compiled ..\..\..\..\boost-sandbox-chrono.x\boost/mpl/abs.hpp(72) : error C2059: syntax e rror : ')' ..\..\..\..\boost-sandbox-chrono.x\boost/mpl/abs.hpp(74) : error C2143: syntax e rror : missing ';' before '{' ..\..\..\..\boost-sandbox-chrono.x\boost/mpl/abs.hpp(75) : error C2143: syntax e rror : missing ';' before '}' ..\..\..\..\boost-sandbox-chrono.x\boost/mpl/abs.hpp(72) : error C2143: syntax e rror : missing ';' before '}' ..\..\..\..\boost-sandbox-chrono.x\boost/mpl/abs.hpp(72) : fatal error C1004: un expected end-of-file found -- View this message in context: http://boost.2283326.n4.nabble.com/boost-chrono-Compiler-errors-for-mpl-abs… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[locale] trouble building
by Noah Roberts 14 Apr '11

14 Apr '11

I grabbed the ICU bin for VS2010. I extracted the content into d:\icu so that d:\icu\include has the various includes. I set up the PATH variable to include d:\icu\bin... I copied boost and lib from the review into boost_1_46_1 where the root of boost source is. The docs seem to imply that I can get a build without ICU if I'm using Windows but this doesn't seem to be the case. I tried --without-icu and I got an error about using --with and --without for the same lib. Here's my attempt to build (with ICU installed): D:\boost_1_46_1\boost_1_46_1>bjam --build-dir=.\build toolset=msvc-10 --with-loc ale --prefix=d:\boost_msvc_1461 --layout=system -sICU_PATH=d:\icu stage Performing configuration checks - iconv (libc) : no - iconv (separate) : no - icu : no D:/boost_1_46_1/boost_1_46_1/tools/build/v2/build\virtual-target.jam:1079: in vi rtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <pstage\lib>libboost_locale.lib error: previous virtual target { common%common.copy-libboost_locale.lib.STATIC_L IB { msvc%msvc.archive-libboost_locale.lib.STATIC_LIB { msvc%msvc.compile.c++-en coding\codepage.obj.OBJ { encoding/codepage.cpp.CPP } } { msvc%msvc.compile.c++- shared\date_time.obj.OBJ { shared/date_time.cpp.CPP } } { msvc%msvc.compile.c++- shared\format.obj.OBJ { shared/format.cpp.CPP } } { msvc%msvc.compile.c++-shared \formatting.obj.OBJ { shared/formatting.cpp.CPP } } { msvc%msvc.compile.c++-shar ed\generator.obj.OBJ { shared/generator.cpp.CPP } } { msvc%msvc.compile.c++-shar ed\ids.obj.OBJ { shared/ids.cpp.CPP } } { msvc%msvc.compile.c++-shared\localizat ion_backend.obj.OBJ { shared/localization_backend.cpp.CPP } } { msvc%msvc.compil e.c++-shared\message.obj.OBJ { shared/message.cpp.CPP } } { msvc%msvc.compile.c+ +-shared\mo_lambda.obj.OBJ { shared/mo_lambda.cpp.CPP } } { msvc%msvc.compile.c+ +-util\codecvt_converter.obj.OBJ { util/codecvt_converter.cpp.CPP } } { msvc%msv c.compile.c++-util\default_locale.obj.OBJ { util/default_locale.cpp.CPP } } { ms vc%msvc.compile.c++-util\info.obj.OBJ { util/info.cpp.CPP } } { msvc%msvc.compil e.c++-util\locale_data.obj.OBJ { util/locale_data.cpp.CPP } } { msvc%msvc.compil e.c++-std\codecvt.obj.OBJ { std/codecvt.cpp.CPP } } { msvc%msvc.compile.c++-std\ collate.obj.OBJ { std/collate.cpp.CPP } } { msvc%msvc.compile.c++-std\converter. obj.OBJ { std/converter.cpp.CPP } } { msvc%msvc.compile.c++-std\numeric.obj.OBJ { std/numeric.cpp.CPP } } { msvc%msvc.compile.c++-std\std_backend.obj.OBJ { std/ std_backend.cpp.CPP } } { msvc%msvc.compile.c++-util\gregorian.obj.OBJ { util/gr egorian.cpp.CPP } } { msvc%msvc.compile.c++-win32\collate.obj.OBJ { win32/collat e.cpp.CPP } } { msvc%msvc.compile.c++-win32\converter.obj.OBJ { win32/converter. cpp.CPP } } { msvc%msvc.compile.c++-win32\lcid.obj.OBJ { win32/lcid.cpp.CPP } } { msvc%msvc.compile.c++-win32\numeric.obj.OBJ { win32/numeric.cpp.CPP } } { msvc %msvc.compile.c++-win32\win_backend.obj.OBJ { win32/win_backend.cpp.CPP } } } } error: created from ./stage-proper error: another virtual target { common%common.copy-libboost_locale.lib.STATIC_LI B { msvc%msvc.archive-libboost_locale.lib.STATIC_LIB { msvc%msvc.compile.c++-enc oding\codepage.obj.OBJ { encoding/codepage.cpp.CPP } } { msvc%msvc.compile.c++-s hared\date_time.obj.OBJ { shared/date_time.cpp.CPP } } { msvc%msvc.compile.c++-s hared\format.obj.OBJ { shared/format.cpp.CPP } } { msvc%msvc.compile.c++-shared\ formatting.obj.OBJ { shared/formatting.cpp.CPP } } { msvc%msvc.compile.c++-share d\generator.obj.OBJ { shared/generator.cpp.CPP } } { msvc%msvc.compile.c++-share d\ids.obj.OBJ { shared/ids.cpp.CPP } } { msvc%msvc.compile.c++-shared\localizati on_backend.obj.OBJ { shared/localization_backend.cpp.CPP } } { msvc%msvc.compile .c++-shared\message.obj.OBJ { shared/message.cpp.CPP } } { msvc%msvc.compile.c++ -shared\mo_lambda.obj.OBJ { shared/mo_lambda.cpp.CPP } } { msvc%msvc.compile.c++ -util\codecvt_converter.obj.OBJ { util/codecvt_converter.cpp.CPP } } { msvc%msvc .compile.c++-util\default_locale.obj.OBJ { util/default_locale.cpp.CPP } } { msv c%msvc.compile.c++-util\info.obj.OBJ { util/info.cpp.CPP } } { msvc%msvc.compile .c++-util\locale_data.obj.OBJ { util/locale_data.cpp.CPP } } { msvc%msvc.compile .c++-std\codecvt.obj.OBJ { std/codecvt.cpp.CPP } } { msvc%msvc.compile.c++-std\c ollate.obj.OBJ { std/collate.cpp.CPP } } { msvc%msvc.compile.c++-std\converter.o bj.OBJ { std/converter.cpp.CPP } } { msvc%msvc.compile.c++-std\numeric.obj.OBJ { std/numeric.cpp.CPP } } { msvc%msvc.compile.c++-std\std_backend.obj.OBJ { std/s td_backend.cpp.CPP } } { msvc%msvc.compile.c++-util\gregorian.obj.OBJ { util/gre gorian.cpp.CPP } } { msvc%msvc.compile.c++-win32\collate.obj.OBJ { win32/collate .cpp.CPP } } { msvc%msvc.compile.c++-win32\converter.obj.OBJ { win32/converter.c pp.CPP } } { msvc%msvc.compile.c++-win32\lcid.obj.OBJ { win32/lcid.cpp.CPP } } { msvc%msvc.compile.c++-win32\numeric.obj.OBJ { win32/numeric.cpp.CPP } } { msvc% msvc.compile.c++-win32\win_backend.obj.OBJ { win32/win_backend.cpp.CPP } } } } error: created from ./stage-proper error: added properties: <debug-symbols>on <inlining>off <optimization>off <runt ime-debugging>on <variant>debug error: removed properties: <debug-symbols>off <define>NDEBUG <inlining>full <opt imization>speed <runtime-debugging>off <variant>release D:/boost_1_46_1/boost_1_46_1/tools/build/v2/build\virtual-target.jam:490: in act ualize-no-scanner from module object(file-target)@962 D:/boost_1_46_1/boost_1_46_1/tools/build/v2/build\virtual-target.jam:135: in obj ect(file-target)(a)962.actualize from module object(file-target)@962 D:/boost_1_46_1/boost_1_46_1/tools/build/v2\build-system.jam:748: in load from m odule build-system D:\boost_1_46_1\boost_1_46_1\tools\build\v2/kernel\modules.jam:283: in import fr om module modules D:\boost_1_46_1\boost_1_46_1\tools\build\v2\kernel\bootstrap.jam:142: in boost-b uild from module D:\boost_1_46_1\boost_1_46_1\boost-build.jam:17: in module scope from module D:\boost_1_46_1\boost_1_46_1> Any ideas?

3 3

[Boost.Pool] TR1?
by Phil Bouchard 14 Apr '11

14 Apr '11

Greetings, I see the Boost.Pool is not making its way up to the C++ standards yet an it is very unfortunate given its great use. Boost.Pool provides an is_from() member function that does a simple range check and returns whether a pointer is part of the pool or not. This is a very useful function which I think should be part of the standards because it could be used for the global pool as well; i.e. the one used by operator ::new and ::delete. The benefits outweigh the costs. Thanks, -Phil

8 49

[Parallel BGL] Property access problem
by Cosimo Calabrese 14 Apr '11

14 Apr '11

Hi to all, I'm working on a WinXP, VS2010, boost 1.46.1, openMPI 1.4.3. I've used in the past the BGL lib, and now I would explore the PBGL extension. I've writed a simple program (you can find it in attach), but I've some problem. When I run it with: mpirun -np 1 .\test.exe it works. But if I use 2 or 4 processors the program crash sistematically in the following way, on different machines too: num_vertices: 10 num_edges: 19 A-->B : 1 A-->C : 10 A-->D : 11 B-->D : 13 C-->D : 12 B-->E : 1 C-->A : 14 E-->D : 1 D-->B : 15 D-->A : 1 E-->B : 16 -------------------------------------------------------------------------- Sorry! You were supposed to get help about: odls-default:could-not-kill But I couldn't open the help file: D:\dev\CommesseAperte\Sviluppo\TELLUSXX_CalcServer\lib\openmpi\installed\share\openmpi\help-odls-default.txt: No such file or directory. Sorry! -------------------------------------------------------------------------- Every process allocates 1 GB. The problem disappear only when I eliminate all the property access (get() and put()). Maybe I access to the MPI framework for the first time during the property access, and so could be an MPI problem? Am I using the property in a wrong way? Thanks in advance, Cosimo Calabrese.

1 1

New, powerful way to use enable_if in C++0x
by Matt Calabrese 13 Apr '11

13 Apr '11

I'm not sure if there is much interest in this or if someone else discovered this as well, but I realized today that enable_if can be used in a new way in C++0x. Traditionally when working with enable_if with function templates you invoke it either in the return type or in an additional function parameter of the function. Each of these has advantages and disadvantages. The parameter form has the downside of augmenting the parameter list. The most notable problems with this approach are that it can't be used with overloaded operators that require a fixed number of arguments, and it can't be used after a variadic argument list. The return type use of enable_if is often preferred since it does not involve augmenting the parameter list, meaning that it can be used with most overloaded operators, but you still can't use it for conversion operations and you can't use it all with constructors as they have no explicit return type. However, in C++0x, there is a new way to use enable_if by altering neither the function parameter list nor the specification of the return type. It can be used with operators, constructors, variadic function templates, and even overloaded conversion operations (the latter of which was previously considered impossible). The way to do it is with C++0x default function template parameters. Rather than try to explain any further in English, the following code should demonstrate the approach fairly clearly (tested in GCC 4.5.2): http://codepaste.net/23yo8o There is only one drawback that I can think of off of the top of my head -- you can't refer to the function parameters by name for the enable_if condition, whereas in C++0x if you use the return type form of enable_if along with the new trailing return type form of function declarations you can. I have never personally wanted to do this and I highly doubt that it's common so this is likely entirely a non-issue, plus you can always use std::declval anyway so you aren't actually losing any high-level functionality. Are there any thoughts on this or drawbacks other than what I mentioned? Should such use be added to the docs as supported behavior in 0x compilers? -- -Matt Calabrese

16 34

[config] Local classes as template parameters
by Lorenzo Caminiti 13 Apr '11

13 Apr '11

On Sat, Feb 12, 2011 at 5:50 AM, John Bytheway <jbytheway+boost(a)gmail.com> wrote: > On 11/02/11 22:29, Lorenzo Caminiti wrote: >> On Fri, Feb 11, 2011 at 4:31 PM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> wrote: >>> From: John Bytheway <jbytheway+boost(a)gmail.com> >>> 2. Might anyone care so much about performance that they absolutely must >>> have the code inlined? The answer is probably "yes" (or at least there >>> will be people who *think* they care, which is also a problem). For >>> these people you could, if you choose, provide an alternate >>> implementation which doesn't indirect through local::function<>, and >>> thus will only work in C++0x (or C++03 with non-standard extensions). >> >> Without inheriting from local::function_base<> and then using >> local::function_ref<> the local struct cannot be passed as a template >> parameter in C++. Is this different for C++0x (C++03)? > > Yes, in C++0x local structs can be passed as template parameters. > Obviously, in C++0x there are lambdas too, so you might think your > library is useless, but I'd expect most compilers to support passing > local structs as template parameters before they support lambdas, so > there is some advantage in having this intermediate implementation. > Also, your macros would allow writing code that worked in C++0x and > C++03, with the virtual function business in only those compilers/modes > where it is necessary. Hello all, Is there a Boost.Config macro that indicates if the compiler allows local classes to be passed as template parameters? Thank you. -- Lorenzo

3 2

[GSoC] Boost.Tree and Boost.BloomFilter
by Alejandro Cabrera 13 Apr '11

13 Apr '11

Hello all, I've filed two proposals for this Google Summer of Code. Boost.Tree: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/cppcabre… <http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/cppcabre…> Boost.BloomFilter: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/cppcabre… I'd be glad to work on either project. Feedback is welcome. Thanks, -Alej

3 5

Installation fails if env VMS is set
by Dreamcat4 12 Apr '11

12 Apr '11

Hi, Over on the Boost-Users mailinglist we have found that this environment variable (and perhaps unknown but maybe others) will cause bootstrap.sh / Jam failure during the Boost libraries compile and install. Heres the full thread: http://lists.boost.org/boost-users/2011/04/67716.php You (or Jam developement team) may wish to consider taking some kind of action to avoid this as VMS is a very common acronym for "Virtual Machines". Its usage elsewhere is widespread and certainly not Boost-specific. Other choices of course - maybe look towards documenting such usag(es) if they cannot be easily avoided. Or consider ways to detect / warn / clean out the users shell environment variables if they are conflicting. Sorry I cant help any further however as a new user I simply have no experience with the Boost library yet. Many thanks. dreamcat4 dreamcat4(a)gmail.com

2 4

[GSOC]SIMD Library
by Faiçal Tchirou 12 Apr '11

12 Apr '11

Hi everyone, I recently ask documentation about the SIMD Library project here and I receive some guides and references links from Joel Falcou. Now I have some questions about the library itself. Is the goal of the project to build a library similar to libSIMDx86 but more focusing on the AltiVec instruction set ? Joel also advises me to take a look at Proto. I read that Proto is used to build DSEL. Will Proto be used to map high level classes and methods of the library to native SIMD instructions ? What about the library itself ? Which modules have to be developped ? Thanks.

8 37

[trac] Misuse of trac system by spammer
by Joachim Faulhaber 12 Apr '11

12 Apr '11

Hi, I received a ticket today: https://svn.boost.org/trac/boost/ticket/5457 that's only purpose is to distribute a commercial link. Has anyone experienced a similar misuse of the trac system? Are there ideas how to prevent this? Regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

3 5

[GSoC] Proposal reviewing
by Andrew Sutton 12 Apr '11

12 Apr '11

Mentors, We need to establish some guidelines for reviewing proposals. They won't be complicated :) I'm opting not to use the mentors mailing list for this announcement. I know that all the mentors are subscribed here. Here's how this should work: 1. Identify the set of proposals for projects that you are interested in mentoring. 2. Evaluate the proposal and write your evaluation as a PRIVATE comment. 3. If you have questions of the student, you can write PUBLIC comments or send them an email. 4. Rank the proposal (I think 5 is the best this year). That would be the project that you want to mentor. Towards the end of the review process, we will select the 10 best proposals. This doesn't guarantee that we'll *fund* 10 proposals, just that I've requested 10 slots. I would like, this year, if all students got feedback regarding their proposals even if they are clearly rejects. The reason for writing evaluations privately, for now, is that it will help me write a public summary for proposals that are not accepted. I'll figure out how this is going to work over the course of the week :) Specific evaluation criteria are up to you (the mentors). You may ask students to modify good proposals. You do not need to ask *all* students to improve their proposals. At the end of the week, you should have a list of 1 or 2 proposals that *you yourself* will mentor. If you are not offering to mentor the project, please don't review it as a 5. Otherwise, we end up with a case where we have to assign a mentor to a project that they aren't interested in. I don't think that this has worked out very well in the past. Also, would prefer that comments regarding specific proposals not be sent to the list. I don't think it would be a good idea for a flood of "this proposal is AWFUL" emails to start popping up. I'm all for transparency, but I don't think airing value judgements would be a beneficial for community development :) Questions or comments involving evaluation criteria and process are fine. Andrew

4 8

[convert] incomplete reference documentation
by Vicente BOTET 11 Apr '11

11 Apr '11

Hi, I was taking a look at the documentation and it seems to me that the reference documentation is incomplete and not ready for review. Do you plan to complete it before review? Thanks, Vicente

4 9