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

FW: Registration Available
by Hartmut Kaiser 06 May '11

06 May '11

FYI... Regards Hartmut --------------- http://boost-spirit.com > -----Original Message----- > From: boostcon-plan(a)googlegroups.com [mailto:boostcon- > plan(a)googlegroups.com] On Behalf Of Marshall Clow > Sent: Friday, May 06, 2011 11:25 AM > To: boostcon-plan(a)googlegroups.com > Subject: Registration Available > > Oliver Mueller <oliver.mueller(a)gmail.com> has discovered that he will not > be able to attend BoostCon. > Unfortunately for him, it is well past the refund deadline (which was > 4./14), so he's looking for someone to use his registration. > > If you know someone who could take advantage of a deal on admission, they > should get in touch with Oliver and work something out. > > -- Marshall > > Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> > > A.D. 1517: Martin Luther nails his 95 Theses to the church door and is > promptly moderated down to (-1, Flamebait). > -- Yu Suzuki

1 0

Re: [boost] [Boost-users] [Boost.Spirit] RFC: bin_float parser
by Vitaly Budovski 06 May '11

06 May '11

On 6 May 2011 10:33, Joel de Guzman <joel(a)boost-consulting.com> wrote: > On 5/5/2011 9:08 PM, Vitaly Budovski wrote: >> Greetings, >> >> On 28 April 2011 12:09, Hartmut Kaiser <hartmut.kaiser(a)gmail.com> wrote: >>> Thanks for this! >> >> Apologies for the long delay in replying. >> >>> >>> A couple of comments: >>> >>> 1) Is there a reason why you created separate components instead of simply extending the existing set of binary parsers/generators? >> >> It seemed like it would be a lot more work. I'm guessing I would need >> to add a new template parameter or maybe use the preprocessor, since >> the classes have a few integer<> types inside. Can you suggest a >> better way? >> >>> >>> 2) What's the rationale for not using/extending the endian classes in Spirit, but providing your own set of independent endian types? >> >> See response above :) Another thing I wasn't too happy with was the >> fact that they are in the integer namespace. Perhaps they should be >> moved out of there, since endianness doesn't apply only to integers. >> >>> >>> 3) If this is to be included into Spirit we'd need the corresponding docs as well. >> >> A few more test cases couldn't hurt either. I discovered I missed an >> asterisk in the generate_to line of bin_float_generator. >> Is there a guide for adding docs to boost? > > Boost Spirit uses quickbook. Please check out the Spirit docs. > Here's a link to quickbook: > http://www.boost.org/doc/libs/1_46_1/doc/html/quickbook.html > > Vitaly, the proper forum for this is the Spirit general or devel mailing list: > See Boost.Spirit lists here: http://www.boost.org/community/groups.html > Can we please move the discussions there? > > Regards, > -- > Joel de Guzman > http://www.boostpro.com > http://boost-spirit.com > Thanks Joel. Moving conversation to more appropriate location. Cheers, Vitaly

1 0

next version dates
by Andy Tompkins 05 May '11

05 May '11

Hi, Has it been decided the dates relevant to the next version? I have only looked here (http://www.boost.org/development/index.html) and didn't see anything. I'm not trying to change / hurry or delay anything. I just want to start moving some changes from trunk to release, but I work slowly and want to start closer to the beginning of a release, not closer to the end of one. Regards, Andy Tompkins.

6 12

[foreach] Warning with gcc-4.6.0 and -Wconversion
by Philipp Reh 05 May '11

05 May '11

gcc-4.6.0 made Boost.foreach unusable in 1.46.1 because the rvalue detection no longer works. Now, there is a fix in trunk for it but it has a nasty side effect, namely a warning that is emitted whenever foreach is used with an rvalue and -Wconversion is turned on. Sadly, this warning cannot be ignored by including Boost with -isystem because the code is generated by a macro, obviously. Here is a simple program to reprdouce this: #include <boost/foreach.hpp> #include <iostream> #include <ostream> #include <vector> typedef std::vector< int > int_vector; int_vector const test() { int_vector ret(2, 2); return ret; } int main() { BOOST_FOREACH( int_vector::const_reference ref, test() ) std::cout << ref << '\n'; } This prints the following warning: test.cpp:21:2: warning: choosing ‘boost::foreach_detail_::rvalue_probe<T>::operator boost::foreach_detail_::rvalue_probe<T>::value_type() [with T = const std::vector<int>, boost::foreach_detail_::rvalue_probe<T>::value_type = const std::vector<int>]’ over ‘boost::foreach_detail_::rvalue_probe<T>::operator T&() const [with T = const std::vector<int>]’ [-Wconversion] test.cpp:21:2: warning: for conversion from ‘boost::foreach_detail_::rvalue_probe<const std::vector<int> >’ to ‘const int_vector’ [-Wconversion] test.cpp:21:2: note: because conversion sequence for the argument is better I would be glad if this could be fixed somehow because -Wconversion is a crucial warning option to me.

3 3

Boost.Locale and the standard "message" facet
by Vicente BOTET 05 May '11

05 May '11

Hi, I was wondering how Boost.Locale is related to the standard message facet which is used to translate messages. Note that the facet interface work with integer identifiers avoiding all the issues raised by the get_text/translate functions provided by Boost.Locale. Is there any reason Boost.Locale could not follow the standard design? What are the advantages of the Boost.Locale design? Best, Vicente

4 6

[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

Boost announce mailing list messages
by Edward Diener 04 May '11

04 May '11

My messages to the Boost announce mailing list, despite being the review manager for the Boost.Convert library, are being ignored. Why is this ? I was able to post an initial announcement on the Boost announce mailing list when the review of the Boost.Convert library started, but my message to that mailing list, when the Boost vault was down and I wanted to alert uses to the subversion URL I had created for the Boost.Convert library, never got posted on the Boost announce mailing list. Now that I have sent another message to the Boost announce mailing list, signalling the result of the Boost.Convert library review, it is again being ignored.

2 1

boost in linux repository
by Krzysztof 04 May '11

04 May '11

When the newer version of boost library is expected to be in linux repository? Now, it has version 1.42. -- Regards Krzysztof J.

3 3

[atomic] Status?
by vicente.botet 04 May '11

04 May '11

Hi, There are some libraries that would prefer to be reviewed after Boost.Atomic is reviewed, otherwise them should move the library as an internal detail of the implementation. Could the people working on Boost.Atomic tell us what is the state of the library? Which platforms have been handled? Which part of the standard has been implemented? Could others having knowledge in assembler participate in this project? When we can expect the library to be ready for review? Best, Vicente

10 20

Re: [boost] [asio] Randomly having problems reading from the socket
by Torben Wiggerich 04 May '11

04 May '11

Hi Jinqiang, thanks for your answer. What I forgot to mention was that I'm using the localhost for the socket connection. So there shouldn't be any errors caused by the physical network, I guess. I changed the code to evaluate the 'ignored error'. But an error never occurs there . It just falls asleep for 5 seconds. Kind regards Torben > > > -------- Original-Nachricht -------- > Betreff: Re: [boost] [asio] Randomly having problems reading from the > socket > Datum: Tue, 3 May 2011 08:57:27 +1000 > Von: Jinqiang Zhang <jasonzha(a)gmail.com> <mailto:jasonzha@gmail.com> > Antwort an: boost(a)lists.boost.org <mailto:boost@lists.boost.org> > An: boost(a)lists.boost.org <mailto:boost@lists.boost.org> > > > > Hi Torben, > > Firstly I claim I always use async way of asio, so I don't get the same > problem as yours. But for your code, I might suggest, because you are > transferring big chunk of data, if network condition is bad, you might get > some error, so maybe you want to see the 'error' while not use 'ignored > error' ? > > cheers, > Jinqiang > > On Mon, May 2, 2011 at 10:28 PM, Torben Wiggerich<torben.wiggerich(a)nisys.de > > <mailto:torben.wiggerich@nisys.de> wrote: > > > Hi all, > > > > I have some problems using the boost.asio.read for a TCP-socket. So far it > > works fine, but it randomly stops the transfer for at least 5 seconds. > > To resolve the error I used a simple synchronous server and client from the > > boost examples and modified it too send a larger amount of data. (307400 > > Bytes; this size comes from the program I'm trying to get run). On the > > client side I also changed the reading from the socket to read the complete > > data with boost.asio.read and transfer_all as argument. > > > > Both, server and client, measure the time for sending and reading to the > > socket and will give an error if it needs more than 1 second. > > > > Here is the sourcecode for the server: > > > > #include<iostream> > > #include<string> > > #include<boost/asio.hpp> > > #include<boost/date_time/posix_time/posix_time.hpp> > > > > using boost::asio::ip::tcp; > > using namespace boost::posix_time; > > > > int main() > > { > > try > > { > > boost::asio::io_service io_service; > > > > tcp::acceptor acceptor(io_service, tcp::endpoint(tcp::v4(), 8002)); > > > > tcp::socket socket(io_service); > > acceptor.accept(socket); > > > > unsigned char * array = new unsigned char[307400]; > > > > for (;;) > > { > > boost::system::error_code ignored_error; > > > > ptime startTime = microsec_clock::universal_time(); > > > > boost::asio::write(socket, boost::asio::buffer( array, 307400 ), > > boost::asio::transfer_all(), ignored_error); > > > > time_duration neededTime = microsec_clock::universal_time() - > > startTime; > > > > if ( neededTime.total_milliseconds()> 1000 ) { > > std::cout<< "ERROR needed too much time: "<< > > neededTime.total_milliseconds()<< "ms"<< std::endl; > > } > > } > > } > > catch (std::exception& e) > > { > > std::cerr<< e.what()<< std::endl; > > } > > > > return 0; > > } > > > > > > My client sourcecode: > > > > #include<iostream> > > #include<boost/array.hpp> > > #include<boost/asio.hpp> > > #include<boost/date_time/posix_time/posix_time.hpp> > > > > using boost::asio::ip::tcp; > > using namespace boost::posix_time; > > > > int main(int argc, char* argv[]) > > { > > try > > { > > if (argc != 2) > > { > > std::cerr<< "Usage: client<host>"<< std::endl; > > return 1; > > } > > > > boost::asio::io_service io_service; > > boost::asio::ip::tcp::endpoint endpoint( > > boost::asio::ip::address::from_string( argv[1] ), 8002 ); > > > > tcp::socket socket(io_service); > > boost::system::error_code error = boost::asio::error::host_not_found; > > socket.connect( endpoint, error ); > > if (error) > > throw boost::system::system_error(error); > > > > int counter = 0; > > unsigned char* array = new unsigned char[307400]; > > for (;;) > > { > > boost::system::error_code error; > > > > ptime startTime = microsec_clock::universal_time(); > > size_t len = boost::asio::read( socket, > > boost::asio::buffer( array, 307400 ), > > boost::asio::transfer_all(), > > error ); > > time_duration neededTime = microsec_clock::universal_time() - > > startTime; > > > > if ( error ) { > > printf( "body read error %s\n", error.message().c_str() ); > > } > > > > if ( counter % 5000 == 0 ) { > > std::cout<< "passed: "<< counter<< "\r"; > > } > > ++counter; > > > > if ( neededTime.total_milliseconds()> 1000 ) { > > std::cout<< "ERROR needed too much time: "<< > > neededTime.total_milliseconds()<< "ms"<< std::endl; > > } > > } > > } > > catch (std::exception& e) > > { > > std::cerr<< e.what()<< std::endl; > > } > > > > return 0; > > } > > > > To reproduce the error just let it run for a while. It can take up to 30 > > minutes or even more... > > After a while it will produce the line: "ERROR needed too much time: > > 5007ms". Maybe with slightly different times, but all around 5 seconds. > > I tested it on different machines with Windows Vista and Seven. > > > > So am I'm doing sth. wrong? Is the reading from the socket correct? > > > > I'm using boost version 1.44. > > > > Kind regards > > Torben Wiggerich > > > > _______________________________________________ > > Unsubscribe& other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > > > _______________________________________________ > Unsubscribe& other changes:http://lists.boost.org/mailman/listinfo.cgi/boost > > > ----- > eMail ist virenfrei. > Von AVG uberpruft -www.avg.de <http://www.avg.de> > Version: 10.0.1209 / Virendatenbank: 1500/3610 - Ausgabedatum: 02.05.2011 >

1 0

[config] Regression tests and warnings
by Edward Diener 04 May '11

04 May '11

It appears that the config regression tests treat all warnings as errors. Where is this specified in the jamfiles for config ? I need to run the config regression tests where -Wno-variadic-macros is defined for gcc, so that the warnings for using variadic macros are turned off and therefore no errors occur. What is the best way of modifying the config regression tests to do this ?

2 3

Porting boost::lexical_cast tests to boost::convert
by Jeroen Habraken 03 May '11

03 May '11

Hi, Since boost::convert is promoting itself as an alternative to boost::lexical_cast I decided to port the boost::lexical_cast test suite (which can be found in BOOST_ROOT/libs/conversion/lexical_cast_test.cpp) to boost::convert. I've simply replaced lexical_cast<T>(U) with convert<T>::from(U) and bad_lexical_cast with std::invalid_argument, whether this is a valid approach I'm not sure. To actually get the test suite to compile for boost::convert I had to comment out a lot of them and even then there are quite a few failures. This needs to be looked at (I've attached the code), what are actual boost::convert failures (both at compile- and runtime) and what is caused by my porting? Regards, Jeroen

2 1

[Review] Boost.Convert library has ended
by Edward Diener 03 May '11

03 May '11

The review period for the Boost.Convert library has officially ended. I will continue to read posts about the library while I make my review decision, so please do not stop discussing the library as appropriate because the review period has ended. I have received one personal request for a late review, and I am willing to accept any other requests for a late review to be made through Wednesday and posted to the mailing list, but I will not consider any other late review in my decision unless someone requests it of me personally. I know this is a fine line between an official review and just comments about what others have said before, but I need to make my decision based on some finite set of reviews and their subsequent discussion. I would like to thank everyone who has officially reviewed Boost.Convert as well as all who have made subsequent comments. The more input received, the easier it becomes for me as a reviewer to make a final decision. I would also like to thank the implementer of the Boost.Convert library, Vladimir Batov, for his willingness to address issues, answer criticism, and engage in discussion about his library. My review decision should be made and posted to the mailing list no later than by the end of Sunday, May 8.

4 3

[Review] Boost.Convert library, new subversion URL
by Edward Diener 03 May '11

03 May '11

This is a reminder that formal review of the Boost.Convert library by Vladimir Batov starts today, April 23, and is scheduled to last through May 2. *************** * 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 * ******************* Normally you can find Boost.Convert here: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost-… However because the boostpro web site is having problems and will likely be down for the weekend, I have put the library into the Boost sandbox temporarily, since the Boost sandbox is up. So you can get the library, using Subversion, from https://svn.boost.org/svn/boost/sandbox/convert. This is exactly the same as the vault with the files unzipped. 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

12 19

[Block Pointer] Review Request
by Phil Bouchard 03 May '11

03 May '11

Hi, I made the requested corrections to the Block Pointer, I've added automated tests and its corresponding Jamfile. The tests can be found here: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/test/block… https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/test/block… Once again the documentation can be found here: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/tutori… Now I'm pretty sure I haven't forgotten anything and I am requesting a review. Thanks, -Phil

5 31

Re: [boost] [BOOST CORE C++ Feature] the super or base keyword for C++
by tymofey 03 May '11

03 May '11

>>I was wondering if it makes sense to add the well known super or base keyword to the C++ language in a generic way. C++ has multiple inheritance, while java and C# do not, so super would be ambigous.

8 14