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

[config] Macro BOOST_NO_NOEXCEPT is required
by Takaya Saito (SubaruG) 05 May '11

05 May '11

http://thread.gmane.org/gmane.comp.lib.boost.devel/214978 I think the macro BOOST_NO_NOEXCEPT ( or BOOST_NO_0X_NOEXCEPT ) is required soon. How's the status now?

5 7

result_of overloaded member function?
by Arno Schödl 05 May '11

05 May '11

Hello, is there a way to get the result type of an overloaded member function? Something like: template< class T, class A > typename boost::result_of< T::func(A) >::type invoke( T& t, A& a ) { return t.func(a); } Thanks for help, Arno -- Dr. Arno Schödl | aschoedl(a)think-cell.com Technical Director think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl

3 3

[Convert] Not a review
by Phil Endecott 05 May '11

05 May '11

Dear All, I've not looked at this library in anything like enough detail to write a proper review, though I have followed a fair amount of the discussion both during the review and during previous discussions of a "better lexical_cast". My view comes down to this: there are zillions of different ways of doing this (both syntax and semantics) and no solution can keep everyone happy (as evidenced particularly by the previous discussions). But that doesn't matter, because every single C++ programmer is capable of writing their own conversion functions that work exactly how they want them to work, if they have the right building blocks. The building blocks are things like C's strto*(), etc. Personally, I prefer thin wrappers like these ones: template <typename ITER> long int strtol(ITER begin, ITER end) { ... } template <int N> long int strtol(const char (&s) [N]) { return strtol(&s[0],&s[N]); } inline long int strtol(std::string s) { return strtol(s.begin(),s.end()); } For variations on error policy I add words like "try", "must" or "maybe" to the function name; similarly for hex and other variations. But I don't suggest that these are going to suit other people. Why should we try to find a "one size fits all" solution to this problem? In my humble opinion, Boost does not need this functionality. Perhaps some of the lower-level "building blocks" would be useful, though - if things like strto*() are deficient. Regards, Phil.

3 4

Re: [boost] howto: boost.lambda + stl on VS 2010 (SP1) ?
by Peter Dimov 05 May '11

05 May '11

Raffi Enficiaud wrote: > To this point, I thought that using accumulate would be cleaner: > std::accumulate(m.begin(), m.end(), double(0), & _1->*&aa::second); std::accumulate takes a binary function. It doesn't do s += f(*i) as you seem to think, it does s = f(s, *i). So you should probably pass _1 + &_2->*&aa::second to it.

1 0

howto: boost.lambda + stl on VS 2010 (SP1) ?
by Raffi Enficiaud 04 May '11

04 May '11

Hi all, Sorry for bothering with this. I recently encountered some problems in using boost.lambda with Visual 2010 Express, and need some clues for solving the issue (there are many ways around of course). I simply want to accumulate the values of a std::map, and I thought using lambda to access the second member of the map iterator was appropriate. Here is the piece of code: typedef std::map<T1, unsigned short> m_t; m_t m ; // fill m double acc(0); std::for_each(m.begin(), m.end(), var(acc) += & _1->*& m_t::value_type::second); The last line does not compile on Visual (it does on GCC), I have to add a typedef: typedef typename m_t::value_type aa; std::for_each(m.begin(), m.end(), var(acc) += & _1->*& aa::second); Which one is "more correct" ? To this point, I thought that using accumulate would be cleaner: std::accumulate(m.begin(), m.end(), double(0), & _1->*&aa::second); But I have several compilation errors, and on the top of it: 1>(..)/boost-1_46_1\boost/lambda/detail/member_ptr.hpp(512): error C2296: '->*' : illegal, left operand has type 'const rt0 ' 1> boost/lambda/detail/member_ptr.hpp(622) : see reference to function template instantiation 'RET boost::lambda::detail::member_pointer_action_helper<true,false>::apply<RET,A ,B>(A &,B &)' being compiled 1> with 1> [ 1> RET=unsigned short &, 1> A=rt0, 1> B=rt1 1> ] I do not really understand what rt0/rt1 are. The former should be the iterator::value_type and the latter the pointer to member. Most of all, the call with accumulate looks very similar to the for_each one to me. So, is the problem between the keyboard and the chair ? Best, Raffi

1 0

[Block Pointer] make_block
by Phil Bouchard 04 May '11

04 May '11

Hi, I just disabled the constructor and the assignment operator having a raw pointers as a parameter and I added the make_block factory function. We can see it in action in the following example: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/example/bl… Is it time for a review? -Phil

7 23

[Spirit Karma] Mutable references formed by pass_container in Karma "repeat" tests
by Doug Gregor 04 May '11

04 May '11

There are a few Karma failures using the latest Clang due to the pass_container detail class forming mutable references: http://www.boost.org/development/tests/release/developer/output/dgregor2-bo… I know that at least some compilers (e.g., GCC) don't diagnose mutable references, but this code is ill-formed account to the standard. Someone want to take a shot at eliminating or factoring out the mutability to avoid these mutable references? - Doug

2 1

[Review] Boost.Convert library, last day
by Edward Diener 04 May '11

04 May '11

This is a reminder that formal review of the Boost.Convert library by Vladimir Batov ends today, May 2. There have only been a few reviews of the library so the library welcomes reviews. If you are one of the people who have been dissatisfied by the perceived limitations of Boost lexical_cast, or have discussed such limitations on Boost mailing lists in the past, please look at the library and give a review of it, as its intent is to offer a greatly enhanced version of lexical_cast as a new library. *************** * Its Purpose * *************** The library builds on the past boost::lexical_cast experience, then takes those conversion-related ideas further to suit better today's applications and programing needs. It still offers simple, minimal interface, familiar conversion behavior and additionally provides: * throwing and non-throwing conversion-failure behavior; * support for the default/fallback value to be returned when conversion fails; * two types of the conversion-failure check - basic/simple and better/safe; * formatting support based on the standard std::streams and std::stream-based manipulators (like std::hex, std::scientific, etc.); * support for different locales; * support for boost::range-compliant char and wchar_t-based containers; * no DefaultConstructibility requirement for the Target/Destination type; * consistent framework to uniformly incorporate any type-to-type conversions, extensibility and additional room to grow. With its present support for string-to-type and type-to-string conversions it is an essential tool for applications making extensive use of configuration or MS-Windows-Registry-style files or having to process/prepare considerable amounts of data in, say, XML, etc. More so, it is easily extendable to accommodate, specialize and uniformly deploy new user-defined type-to-type conversions. ******************* * Where to get it * ******************* The Boost Vault is accesible again after being down for most of the week, so you can get the library from the Boost Vault at http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost-… You can also get the library, using Subversion, from https://svn.boost.org/svn/boost/sandbox/convert. The HTML documentation is part of the distribution and can be found at libs/convert/index.html in the distribution above. ******************** * Writing a review * ******************** The reviews and all comments should be submitted to the developers list, and the email should have "[convert] Review" at the beginning of the subject line to make sure it's not missed. Please explicitly state in your review whether the library should be accepted. The general review checklist: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Edward Diener, Review Manager

10 17

Re: [boost] Boost.Locale and the standard "message" facet
by Vicente BOTET 04 May '11

04 May '11

Hi, > Message du 30/04/11 15:48 > De : "Artyom" > A : boost(a)lists.boost.org > Copie à : > Objet : Re: [boost] Boost.Locale and the standard "message" facet > > > Subject: [boost] Boost.Locale and the standard "message" facet > > > > Hi, > > > > I was wondering how Boost.Locale is related > > to the standard message facet which is used > > to translate messages. > > > The standard message catalogs allow to extract > messages by integer identifiers but may use string > identifiers and it is implementation defined > > It is undefined how to load message facets Well implementation defined doesn't mean undefined. > or format them and so on. The formatting can always be done on top of this facet, isn't it? > It does not support plural forms and context. I'm not an expert, but doesn't catalogs and the set parameter can be used for your domain an context? Respect to plural forms, how Boost.Locale manages with locales that have 3 or 4 forms of plurals (If I understood your private mail, Hebrew is an example of this)? I've the impression that Boost.Locale manage simple plurals but not all kind of plurals? BTW, what is the criteria in Boost.Locale to identify a plural form? How your library manage plurals for message that have several parameters? For example translate("%1 hours, %2 minutes, %3 seconds") % h % m % s > It is the most unless facet around. What do you mean? That the scope is reduced? > > Note that the facet > > interface work with integer identifiers > > avoiding all the issues raised by the > > get_text/translate functions > > provided by Boost.Locale. > > > > Use of integer identifiers is the best > way to screw the localization in the software. > > What does 3456 means? Do you really think > it is good to write translate(MY_MESSAGE_OPENING_FILE) Why not? Note that we can also write translate(MyMessage::OpeningFile) if this seems clearer to you > No, never - never - never - never - never > use such "constant" or "integer" identifiers. I understand that some as you can find that the use of integers scale worst than the use of strings as we need to maintain constants unique on a given context, but this can be checked on debug mode. Some time ago when I had to write a localization application, we used integer identifier to log internationalizable messages. This reduced drastically the size of the log. I guess only this advantage was enough to take integers instead of strings, for us of course. An advantage I see is that you need to concentrate all the message id of a set/context in a single file so no need to have tools that parse your code to get the strings to translate. BTW, how do you recover message translation from a domain with your underlying implementation, copy/paste or is there a possibility to have specific files for specific domains, or there is a single translation file by locale? I've not take a look at your implementation yet. Please could you tell me when the translation file is read? Is the file parsed only once and the translations stored on a cache? > Always use natural text. I think your natural language interface lets the user to have the impression that anything is possible, when a lot of limitations seem to be there as other have already commented in this ML. > > Is there any reason Boost.Locale > > could not follow the standard design? > > The standard message catalogs to weak I would like to here the rationale of the standard message design by someone that is aware of it (some pointers will be welcome also). > > What are the advantages of the Boost.Locale design? > > > > 1. Defined way to load and format catalogs You could provide a defined way on top of this facet, isn't it? > 2. Support of pural forms Plural forms can be designed on top of the message facet? > 3. Support of message-context As I said, I suspect that the set parameter is interpreted as your context. > 4. Using natural language identifiers as keys See below. This is not always an advantage, and as far as I see adds some constraints on the interface so the tool can take care to automatically extract the strings to translate. > 5. Convenense interface What do you mean? Could you compare both? > More? Well, I think that it would be great if you can add a complete comparison of the interfaces and a rationale why you think your design is superior on the documentation. Best, Vicente

2 7

[range] as_literal always returning iterator_range
by Tobias Germer 04 May '11

04 May '11

Hi all, I think there is a problem with the behavior of boost::as_literal. If I got it right, it is supposed to create an iterator_range from null-terminated strings, which is fine. However, it also creates iterator_ranges from exisiting ranges, i.e., it converts general ranges to iterator_ranges. I think as_literal should fall back to identity (i.e., just return its argument) if its argument is already a range. With the current behavior, the type information of the range is lost. This is a problem if I write generic code and want to dispatch several cases based on the type of the range. Consider the following example: ------------------------------- template<class Rng> void f( Rng const& r ) {...} template<class T> void f( iterator_range<T*> const& r ) {...} void f( std::string const& s ) {...} void f( std::vector const& v ) {...} template<class Rng> void g( Rng const& r ) { f(as_literal(r)); ... } ------------------------------- Function g() accepts general ranges as well as zero-terminated strings. It dispatches its argument using the type of the range and the overloads of f(), in order to execute special code for some ranges like strings and vectors. (In my particular case, I have special treatment for ranges of contiguous memory.) This is not possible anymore after calling as_literal, because it always returns an iterator_range. Wouldn't it be better to return the original range, for example like this: template< class Rng > typename enable_if< has_range_const_iterator<Rng>, Rng &>::type as_literal (Rng& r ) { return r; } Regards, Tobias -- Dr. Tobias Germer | tgermer(a)think-cell.com Software Engineer think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl

3 2