- Boost - lists.boost.org

[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

[thread]link problem with ibboost_thread-vc71-mt-gd-1_38.lib
by WANG Xuewen 16 Feb '09

16 Feb '09

Hello, I had a dll using MFC as shared library which works fine with boost 1.35. Recently, I've started to look at 1.38 and got the following link problem: libboost_thread-vc71-mt-gd-1_38.lib(tss_pe.obj) : error LNK2005: __pRawDllMain already defined in mfcs71d.lib(dllmodul.obj) libboost_thread-vc71-mt-gd-1_38.lib(tss_pe.obj) : warning LNK4006: __pRawDllMain already defined in mfcs71d.lib(dllmodul.obj); second definition ignored I've searched on internet and mailing list archive and didn't find a solution to the problem. Does anyone have an idea? Thanks, Xuewen

2 1

Seeking writers to develop quarterly digests of Boost newsgroups
by Brian Wood 16 Feb '09

16 Feb '09

I'm planning to start an on line magazine called C++ Quarterly. *http://tinyurl.com/df6hn2 or **http://preview.tinyurl.com/df6hn2 * If you are interested in writing a quarterly digest of Boost Users and/or Boost Developers, please let me know. Alternatively, if you're interested in writing a non-digest article, I'd be happy to hear from you. Just to clarify something from the above link. I want to set things up so that advertisers send money directly to authors. Advertisers would send ads to us but money to authors. Brian Wood Ebenezer Enterprises www.webEbenezer.net <http://www.webebenezer.net/>

1 0

Releases and EOLS
by Rene Rivera 15 Feb '09

15 Feb '09

In the past there's been confusion as to what the release packages contain with regards to EOLs <https://svn.boost.org/trac/boost/ticket/2641>. My idea for dealing with the confusion is to tag the packages with an EOL indicator (as explained in the bug). Any other ideas? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

3 6

boost::ptr_container: seems bug in erase_if
by Anton Ivanov 15 Feb '09

15 Feb '09

Hi! In ptr_sequence_adapter.hpp we have function: template< class Pred > void erase_if( iterator first, iterator last, Pred pred ) { range_check(first,last); this->base().erase( std::remove_if( first.base(), last.base(), void_ptr_delete_if<Pred,value_type>(pred) ), this->base().end() ); } If we call this function with second parameter not equal to this->base().end() then function remove not only elemets for wich pred return true, but also all alement from last.base() to the end of container (this->base().end()). This is seems bug due to function documentation: template< class Pred > void erase_if( Pred pred ); template< class Pred > void erase_if( iterator begin, iterator end, Pred pred ); * Requirements: Pred must take an const T& argument * Effects: removes all elements t for which pred(t) returns true from the entire container or the specified range -- Yours sincerely, Anton Ivanov (ai(a)drweb.com)

3 4