February 2009 - Boost - lists.boost.org

Re: [boost] Formal Review Request: Boost.String.Convert
by Vladimir.Batov＠wrsa.com.au 18 Feb '09

18 Feb '09

I am not sure I can answer all the questions sent so far individually. Some of the questions have been discussed/answered and hopefully this email might be of some help also. RE: convert() and directionality I've decided to stick with Robert's convert() (and his op>> as well. Thank you, Robert) as I agree with his view to leave the door open for possible extensions. That attitude has already proven useful to extend the conversions onto string-to-string (that I did not anticipate). With convert() it'll be easy to extend the existing functionality onto wstring<->u8string, etc. In string-to-string context the directionality issue is mute and I personally find convert() as very much appropriate. Even with string-to/from-type conversions directionality is still present (via types). I agree that with convert() the directionality is somewhat more subtle compared with to/from (or whatever the alternatives). RE: to/from: Yes, I understand quite a few people are not exactly thrilled with to/from. However, it is still here. Apologies. There are two (and a half) reasons for that -- 1) conceptual. Even though I am getting to like convert() more and more, I am still occasionally longing to express explicitly the direction of the conversion with to/from. 2) technical. This to/from-based interface is used in my current project and I am reluctant to needlessly disturb it in any way to avoid code reviews, etc. etc. 2.5) I happen to still like its terseness and directness as my code simply reads "string::to<int>" for string-to-int. I am getting more and more comfortable with convert() though. However, I've been using to/from for about 5 years and it feels like old shoes. Just give me some time to get used to something new. RE: to_string/from_string Somehow I did not like to_string/from_string from the start. I dunno. Just irrational primal dislike. I am sorry. Now it seems I might try putting some smoke-n-mirrors around that by justifying it by the functionality that Hartmut mentioned -- conversion from one symbol/character set to another. I've implemented it (v0.14) and it it like this: string encrypted = boost::string::convert(naked_str) >> my_cypher; string decrypted = boost::string::convert(encrypted) >> my_cypher; That is, we are converting from a string to again a string. In such context I very much like the direction-less nature of convert(). >> My problem is that I can't think of a case when I would be writing >> code that doesn't "know" if it is going "to" or "from" string. Again, string-to-string (or string-from-string) comes to mind. Any directionality seems superfluous and I personally find the code above quite appropriate. Any other suggestions are always welcome as hartmut only brought it up yesterday and I only gave it a cursory thought (can I say a "cursory" thought? it kinda does not feel right). >> I've needed to convert things specifically to std::string plenty of >> times to justify a simple interface where to_string returns >> std::string. I want to be able, in a header file, to just say: >> struct foo; >> std::string to_string( foo const & ); >> std::string to_string( foo const &, fmt ); >> and be done with it. I hope that the suggested interface and implementation allow enough flexibility and simplicity without limiting one to std::string only: namespace bstring = boost::string; std::string s1 = bstring::convert(foo); std::string s1 = bstring::convert(foo) >> std::hex; // add formatting std::Wstring s1 = bstring::convert(foo, std::wtring()); // convert to wide string std::Wstring s1 = bstring::convert<std::wstring>(foo); // same as above RE: convert("5").to<int>(), I like Scott's suggestion of the above. It looks cute. OTOH I am not sure where to stick it into though. Thanks, Vladimir.

4 3

[foreach] HELP NEEDED: intel-vc9-win-11.0
by Eric Niebler 18 Feb '09

18 Feb '09

Boost.Foreach is failing its tests on trunk on the intel-vc9-win-11.0 platform. If there is anyone with access to this platform who would like to run a couple of quick tests, you will be generously rewarded in your next life. Can't beat that. All you have to do is run foreach's tests 4 times with a slightly different config each time. In foreach.hpp, comment out all the config preprocessor gunk (everything between #include <boost/detail/workaround.hpp> and #include <boost/mpl/if.hpp>) and replace it with one of the following: #define BOOST_FOREACH_COMPILE_TIME_CONST_RVALUE_DETECTION or #define BOOST_FOREACH_RUN_TIME_CONST_RVALUE_DETECTION or #define BOOST_FOREACH_NO_CONST_RVALUE_DETECTION or #define BOOST_FOREACH_NO_RVALUE_DETECTION Report the number of test failures each time. Your karmic reward awaits. Thanks in advance, -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 3

Re: [boost] [Boost-commit] svn:boost r51307 - trunk/libs/ptr_container/test
by Juergen Hunold 18 Feb '09

18 Feb '09

Hi Thorsten ! On Tuesday 17 February 2009 23:42:41 nesotto(a)cs.aau.dk wrote: > Author: nesotto > Date: 2009-02-17 17:42:39 EST (Tue, 17 Feb 2009) > New Revision: 51307 > URL: http://svn.boost.org/trac/boost/changeset/51307 > > Log: > updated for nasty erase() bug.. > Text files modified: > trunk/libs/ptr_container/test/Jamfile.v2 | 3 ++- > trunk/libs/ptr_container/test/associative_test_data.hpp | 5 ++++- > trunk/libs/ptr_container/test/ptr_set.cpp | > trunk/libs/ptr_container/test/ptr_unordered_set.cpp +++++++-------------- 5 files changed, 70 insertions(+), > 18 deletions(-) > > Modified: trunk/libs/ptr_container/test/Jamfile.v2 > =========================================================================== >=== --- trunk/libs/ptr_container/test/Jamfile.v2 (original) > +++ trunk/libs/ptr_container/test/Jamfile.v2 2009-02-17 17:42:39 EST (Tue, > 17 Feb 2009) @@ -38,5 +38,6 @@ > [ sc-test ptr_unordered_set ] > [ sc-test ptr_unordered_map ] > [ sc-test ptr_circular_buffer ] > - > + [ sc-test ptr_multi_index_container ] > + It seems you forgot to "svn add ptr_multi_index_container.cpp" . Can you please add it as this completely breaks regression testing... Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 1

autolinking
by James Mansion 18 Feb '09

18 Feb '09

I'd like to build a boost subset using my own build system. I'd like to turn off autolinking and control the names of the libraries, but it seems I can't. Is that intentional? I tried to use BOOST_AUTO_LINK_NOMANGLE as a starting point but setting that only helped for the first inclusion of auto_link.hpp, since it undefines it. Can I offer this trivial patch, or at least suggest something similar? Index: include/boost/config/auto_link.hpp =================================================================== --- include/boost/config/auto_link.hpp (.../ref/boost) (revision 758) +++ include/boost/config/auto_link.hpp (.../src/boost) (revision 758) @@ -304,6 +304,9 @@ && defined(BOOST_LIB_RT_OPT) \ && defined(BOOST_LIB_VERSION) +// JGM: provide global disable for autolink of Boost libraries. +#if !defined(BOOST_NO_AUTOLINK) + #ifndef BOOST_AUTO_LINK_NOMANGLE # pragma comment(lib, BOOST_LIB_PREFIX BOOST_STRINGIZE(BOOST_LIB_NAME) "-" BOOST_LIB_TOOLSET BOOST_LIB_THREAD_OPT BOOST_LIB_RT_OPT "-" BOOST_LIB_VERSION ".lib") # ifdef BOOST_LIB_DIAGNOSTIC @@ -316,6 +319,8 @@ # endif #endif +#endif // !BOOST_NO_AUTOLINK + #else # error "some required macros where not defined (internal logic error)." #endif @@ -355,14 +360,3 @@ #if defined(BOOST_AUTO_LINK_NOMANGLE) # undef BOOST_AUTO_LINK_NOMANGLE #endif - - - - - - - - - - -

2 1

[spirit] trunk failures due to wrong namespaces
by Juergen Hunold 17 Feb '09

17 Feb '09

Hi ! I've stumbled across some spirit test failures like http://tinyurl.com/bwkgvu The obvious fix seems to be to adjust "boost::math" to "boost::spirit::math" in all places. The attached patch tries to do that. Okay to commit ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 2

interprocess: error in boost::interprocess::file_lock::swap
by Anton Ivanov 17 Feb '09

17 Feb '09

Hi! current code of function boost::interprocess::file_lock::swap (in boost 1.38.0) is: #if !defined(BOOST_INTERPROCESS_RVALUE_REFERENCE) && !defined(BOOST_INTERPROCESS_DOXYGEN_INVOKED) void swap(detail::moved_object<file_lock> mother) { this->swap(mother.get()); } void swap(file_lock &other) #else void swap(file_lock &&other) #endif { file_handle_t tmp = m_file_hnd; other.m_file_hnd = other.m_file_hnd; other.m_file_hnd = tmp; } Seems, line: other.m_file_hnd = other.m_file_hnd; is wrong. Right version: m_file_hnd = other.m_file_hnd; Ticket https://svn.boost.org/trac/boost/ticket/2766 created. -- Yours sincerely, Anton Ivanov (ai(a)drweb.com)

2 1

[accumulator][minmax_element] Perfomance comparsion different min max algorithm
by Hansi 17 Feb '09

17 Feb '09

Hi, I have made today a few tests to compare the different possibilities to search min,max of a value. I had some really strange results which I don't have expected. As environment I use VS2008 Express edition,not managed, defines are SECURE_SCL=0 and NDEBUG=1. In the comparsion I got the following timings: <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< min_element,max_element:73 minVal=0,maxVal=9999999 min_max: accumulator:2338 minVal=0,maxVal=9999999 min_max: minmax_element:86 minVal=0,maxVal=9999999 min/max handcoded:135 minVal=0,maxVal=9999999 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< For me the strange things are: - that std::min_element and std::max_element is faster as boost::minmax_element - the accumulator library seems in this example really slow Best regards Hansjörg The source code was: #include <algorithm> #include <boost/accumulators/accumulators.hpp> #include <boost/accumulators/statistics.hpp> #include <boost/algorithm/minmax_element.hpp> #include <boost/array.hpp> #include <boost\chrono\chrono.hpp> using namespace boost; using namespace boost::chrono; using namespace std; typedef array<int,10000000> dataarray; dataarray data;

5 8

Website news, 1.39 and Boost.Build
by Vladimir Prus 17 Feb '09

17 Feb '09

I have two questions about the news from website: 1. beta.boost.org does not list any 1.39 news, so it's not possible to validate that any addition to boost_1_39_0.qbk are ok. Can that file be somehow included? 2. How do I document Boost.Build changes? This is not exactly a "library". Thanks, Volodya

2 1

Re: [boost] Review Request: Introduction of boost::string, namespace and string-conversion functions
by Vladimir.Batov＠wrsa.com.au 17 Feb '09

17 Feb '09

> That would be: > > string s = boost::string::convert(-1); // to string > int i = boost::string::convert<int>(str); // from string Yes, or string s = boost::string::convert(-1, default_str); // to string int i = boost::string::convert(str, -1); // 'int' deduced from the second parameter > And with that we're almost back at the interface of boost::lexical_cast > once again. Yes, in fact my very first request was to extend lexical_cast. However, it was collectively decided to start a separate library to accommodate formatting, locales, etc. > Also the user might want to convert between std::wstring and > std::string, and in C++0x, std::u8string, std::u16string, and > std::u32string. Yes, now I am coming to realize that accommodating all that additional conversion-related functionality is better done without disturbing the existing lexical_cast. I am hoping the proposed boost::string::convert() "library" is sufficiently flexible to accommodate future growth including the conversions you mentioned. They will be implemented as specializations/overloads of that same boost::string::convert(). Although I have a suspicion that std::string<->std::wstring is not such an easy task. It is because (at present anyway) in my program I do not know if std::string is, say, UTF8 ot MBCS (which might happen to be UTF8 as on Linux or might not as on Windows, Solaris). With std::u8string, std::u16string, and std::u32string it certainly will be easy as we know what we are converting from/to. So, I suspect it'll be as easy as having std::wstring convert(std::u8string) std::u8string convert(std::wstring) Thanks, Vladimir.

1 0

What else shall I do before reuse a stringstream for date parsing?
by Bill David 17 Feb '09

17 Feb '09

To accelerate date parsing, I have writen a class to encapsulate the date parsing logic as following. But the second call to CDateParser::parseDate(str) always failed to parse the date string. What else shall I do before reuse the stringstream object? #include <stdio.h> #include <iostream> #include <sstream> using namespace std; #include "boost/date_time/posix_time/posix_time.hpp" using namespace boost::gregorian; using namespace boost::posix_time; class CDateParser { public: static void initialize(); static time_t parseDate(const string& s); private: static stringstream m_ss; //!< stringstream object used internally for date parsing }; stringstream CDateParser::m_ss; time_t CDateParser::parseDate(const string& str) { ptime p; m_ss.clear(); m_ss << str; m_ss >> p; if (m_ss.fail()) { cout << "do not understand: " << str << endl; return 0; } tm t = to_tm(p); return mktime(&t); } void CDateParser::initialize() { time_input_facet* timefacet = new time_input_facet("%a, %d %b %Y %H:%M:%S %z"); // will be automatically deleted by related locale object m_ss.imbue(locale(locale::empty(), timefacet)); } int main() { CDateParser::initialize(); string str; time_t t; str = "Fri, 18 Jul 2008 11:53:14 GMT"; t = CDateParser::parseDate(str); cout << ctime(&t) << endl; str = "Sat, 19 Jul 2008 11:53:14 GMT"; t = CDateParser::parseDate(str); cout << ctime(&t) << endl; }

3 6