July 2009 - Boost - lists.preview.boost.org

Re: [boost] RFC: interest in Unicode codecs?
by Graham 18 Jul '09

18 Jul '09

Dear Phil, >Having said all that, I must say that I actually use the code that I >wrote quite rarely. I now tend to use UTF8 everywhere and treat it as >a sequence of bytes. Because of the properties of UTF8 I find it's >rare to need to identify individual code points. For example, if I'm >scanning for a matching " or ) I can just look for the next matching >byte, without worrying about where the character boundaries are. Using UTF-8 can work well if you are only targeting American and Western Europe for non-literary use. If you need to support the rest of the world you really need to move to UTF-32 due to the large number of characters and the grapheme and glyph handling [e.g. in Urdu you can type 3 characters and they are displayed as a single combined glyph, and the cursor should never be placed between them]. Even in UTF-8 things can get a bit tricky. For example, where do you break the line if you needed in the middle of: joe)jack -> joe) <br> jack joe(jack -> joe <br> (jack joe+jack -> guess which is the standard ! For programmers we don't mind too much, but when you are writing text editors this can be really important. Now think how many characters there are with special rules on whether they can be split before, after, or never split, and you start to touch on the reason for the Unicode standard and why you need character properties. Yours, Graham

5 4

[graph] Graph and AdjacencyMatrix
by Andrew Sutton 18 Jul '09

18 Jul '09

There was a bug reported (#3266) that brings up a valid problem with the BGL concept hierarchy and the edge() function. It turns out that virtually every graph defines the edge() function, but only the AdjacencyMatrix concept actually requires it as part of its interface. This means that every algorithms (e.g., Kolomogrov's Max Flow) that uses the edge() function implicitly requires graphs to model the AdjacencyMatrix concept. Since we're addressing edge-related operations, we could also take this time to clean up some of the confusion on source, target, and edge descriptors. Specifically, source() and target() are always defined and that edge descriptors - even those for undirected graphs - imply directionality. Basically, it doesn't matter if the underlying graph implementation defines source and target, the adaptation to the BGL /has to/ in order for even the most basic algorithms to work correctly. I suggest that we modify the Graph concept to define the following valid expressions. edge(u, v, g) -> pair<edge_descriptor, bool> source(e, g) -> vertex_descriptor target(e, g) -> vertex_descriptor And the following semantics: source(edge(u, v, g), g) == u target(edge(u, v, g), g) == v edge, source, target = O(E) // upper bound on an edge list. Basically this requires the edge() function to preserve the source/target ordering of the vertices in the edge that it describes. I don't believe that any graph implementations or adaptors need to be modified in order to support these changes. We can then modify the AdjacencyMatrix concept to document a refinement of the edge function, specifically that it return in O(1) time. Does anybody see any obvious problems with these changes? Andrew Sutton andrew.n.sutton(a)gmail.com

2 4

[xpressive] Performance Tuning?
by Stewart, Robert 17 Jul '09

17 Jul '09

I was experimenting with Xpressive to see how it would compare with some custom, string-based numeric input parsing. The Xpressive code is over 175X slower than the custom code. Have I done anything to make it really slow? Can it be made faster? I have included the Xpressive code and the performance testing code below for your study. Can you spot anything I've done wrong? (BTW, I tried using Spirit.Qi for this -- with Boost 1.37 -- but never could get things to compile. I gave up and decided I'd wait until I can use a newer release before I fight that fight again. :-} ) FYI: bar::numeric_cast winds up calling strtod(), strtol(), etc. It is semantically equivalent to lexical_cast. #include <boost/xpressive/xpressive_static.hpp> #include <boost/xpressive/regex_actions.hpp> namespace foo { namespace op { template <class T> struct numeric_cast { typedef T result_type; template <class Value> T operator ()(Value const & _value) const { return bar::numeric_cast<T>(_value); } }; } struct direct_impl { typedef int64_t result_type; template <class Value> int64_t operator ()(Value const & _value) const { int64_t result(bar::numeric_cast<int64_t>(_value)); result *= 160000; return result; } }; struct to_price_impl { typedef int64_t result_type; template <class Value> int64_t operator ()(Value const & _value) const { int64_t result(0); if (_value) { double const value(bar::numeric_cast<double>(_value)); result = static_cast<int64_t>( std::floor(160000.0 * value + 0.5)); } return result; } template <class Value> int64_t operator ()(Value const & _numerator, Value const & _denominator) const { unsigned const numerator(bar::numeric_cast<unsigned>(_numerator)); unsigned const denominator(bar::numeric_cast<unsigned>(_denominator)); double const fraction((160000.0 * numerator) / denominator); return static_cast<int64_t>(std::floor(fraction + 0.5)); } template <class Value> int64_t operator ()(Value const & _whole, double const _fraction) const { int const whole(bar::numeric_cast<int>(_whole)); double const value(160000.0 * whole + _fraction); return static_cast<int64_t>(std::floor(value + 0.5)); } }; int64_t parse(std::string const & _value); boost::xpressive::function<direct_impl>::type const direct = {{}}; boost::xpressive::function<to_price_impl>::type const to_price = {{}}; BOOST_PROTO_DEFINE_FUNCTION_TEMPLATE( 1 , numeric_cast , boost::proto::default_domain , (boost::proto::tag::function) , ((op::numeric_cast)(typename)) ) } int64_t foo::parse(std::string const & _value) { using namespace boost::xpressive; if (_value.empty()) { return 0; } int64_t result; bool negative(false); sregex zero = as_xpr('0'); sregex sign = as_xpr('-') [ ref(negative) = true ] | as_xpr('+'); // ignore // ignore leading zeroes to avoid octal parsing sregex fraction = ( !zero >> (s1= +_d) >> !blank >> '/' >> !blank >> !zero >> (s2= +_d) ) [ ref(result) = to_price(s1, s2) ]; sregex real = ( *_d >> '.' >> *_d >> !((set= 'E', 'e', 'G', 'g') >> +_d) ) [ ref(result) = to_price(_) ]; // ignore leading zeroes to avoid octal parsing sregex whole_number = ( !zero >> (s1= +_d) >> +blank >> fraction ) [ ref(result) = to_price(s1, ref(result)) ]; // ignore leading zeroes to avoid octal parsing sregex integer = ( !zero >> (s1= +_d) ) [ ref(result) = direct(s1) ]; sregex price = *blank >> !sign >> (real | whole_number | fraction | integer) >> *space; smatch match; if (!regex_match(_value.begin(), _value.end(), match, price)) { throw price_parsing_failed(_value); } if (negative) { result = -result; } return result; } void test_performance() { Timer timer; std::string const input("1234.5678e10"); int64_t total(0); foo::parse(input); // prime the cache timer.start(); for (int i(0); i < 10000000; ++i) { int64_t price(foo::parse(input)); price += i; total += price; } timer.stop(); std::cout << timer.elapsed() << "s elapsed (total = " << total ')' << std::endl; } _____ Rob Stewart robert.stewart(a)sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

9 34

Boost filesystem get_temporary_file()
by Craig Henderson 17 Jul '09

17 Jul '09

I cannot find any function in the Boost.Filesystem library to get a temporary filename. There has been some discussion about this functionality on the lists many years ago - did anything come of this? I need a cross-platform way to do this and was hoping boost would provide it :) Thanks -- Craig Craig Henderson <http://craighenderson.co.uk/> http://www.craighenderson.co.uk http://www.siteupdatenotification.com

2 1

[smart_ptr] copyable_ptr?
by Ross Levine 17 Jul '09

17 Jul '09

I was wondering if boost has considered a smart pointer that is similar to scoped_ptr but supports deep copy semantics. This would be useful in classes which use the pimpl idiom, as a common way to program these classes is with a scoped_ptr or auto_ptr, but then a copy constructor and copy assignment operator needs to be defined. Herb Sutter worked on an implementation at http://www.gotw.ca/gotw/062.htm, so there's precedent. Is there any interest for this?

6 6

[string algo] trim() requirements to high
by Thorsten Ottosen 16 Jul '09

16 Jul '09

Hi Pavol, It seems to me that trim() and its variants that currently take a Sequence argument can be made to work iterator ranges too. For example: boost::sub_range<std::string> foo = ...; trim_left( foo ); The requirement would be trim_left: forward range trim_right: bidirectional range trim: bidirectional range Am I missing something? -Thorsten

1 0

[Progress]
by Pierre 16 Jul '09

16 Jul '09

Hello, I have a suggestion over boost/progress.hpp. The class is very good. But I have a critic to announce. If we want to use the class to just keep an eye of the evolution of the process (we do not can just say we don't want a stream output (i'm right??)). I.E : to send the progress pourcentage to a graphical progress bar. So I purpose something like the following : A basic class to manage the evolution of a process. A class to display the evolution of the process that use the precedent one. It's possible I misunderstanding the progress_display class to tell it that we don't want stream output (example to feed a graphical progress bar). The body of the functions and classes will be something like : #include <iostream> #include <string> using namespace std; // CProgress --------------------------------------------------------// // CProgress manage the appropriate count_step of progress // Usage : // CProgress progress( COUNT ); // for(int i=0; i < COUNT; ++i, ++progress) //{ // ... //do something //} //-- you can access to internal data : // //cout<< "Count : " << my_progress_bar.count() << " pourcent " << my_progress_bar.count()/(float)my_progress_bar.expected_count()*100; class CProgress { public: explicit CProgress ( unsigned long expected_count=1 ) { restart ( expected_count ); } virtual void restart ( unsigned long expected_count ) // Effects: display appropriate scale // Postconditions: count()==0, expected_count()==expected_count { _count = _next_tic_count = _tic = 0; _expected_count = expected_count; if ( !_expected_count ) _expected_count = 1; // prevent divide by zero } // restart unsigned long operator+= ( unsigned long increment ) // Effects: Increment appropriate progress tic if needed. // Postconditions: count()== original count() + increment // Returns: count(). { if ( ( _count += increment ) >= _next_tic_count ) { inc_tic(); } return _count; } unsigned long operator++() { return operator+= ( 1 ); } //-- Accessor unsigned long count() const { return _count; } unsigned long expected_count() const { return _expected_count; } protected: unsigned long _count, _expected_count, _next_tic_count; unsigned int _tic; private: virtual void inc_tic() { _next_tic_count = static_cast<unsigned long> ( ( _tic/50.0 ) *_expected_count ); } // inc_tic }; // CProgress_display --------------------------------------------------------// // CProgress_display displays an appropriate indication of // progress at an appropriate place in an appropriate form. // Usage : // CProgress_display my_progress_bar( fileList.size() ); // for (list<string>::const_iterator it = fileList.begin(); it != fileList.end(); ++it, ++my_progress_bar) // the CProgress_display::operator++ take in charge the display of the progression (***) // { // const string & filename = *it; // ... // do something // } // //0% 10 20 30 40 50 60 70 80 90 100% //|----|----|----|----|----|----|----|----|----|----| //************************** ... class CProgress_display : public CProgress { public: explicit CProgress_display ( unsigned long expected_count, std::ostream & os = std::cout, const std::string & s1 = "\n", //leading strings const std::string & s2 = "", const std::string & s3 = "" ) // os is hint; implementation may ignore, particularly in embedded systems : m_os ( os ), m_s1 ( s1 ), m_s2 ( s2 ), m_s3 ( s3 ) { restart ( expected_count ); } void restart ( unsigned long expected_count ) // Effects: display appropriate scale // Postconditions: count()==0, expected_count()==expected_count { CLTU_Progress::restart ( expected_count ); //-- Initialize the base class m_os << m_s1 << "0% 10 20 30 40 50 60 70 80 90 100%\n" << m_s2 << "|----|----|----|----|----|----|----|----|----|----|" << std::endl // endl implies flush, which ensures display << m_s3; } // restart private: std::ostream & m_os; // may not be present in all imps // string is more general, safer than const char *, and efficiency or size are not issues const std::string m_s1, m_s2, m_s3; // formatting display void inc_tic() { // use of floating point ensures that both large and small counts // work correctly. static_cast<>() is also used several places // to suppress spurious compiler warnings. unsigned int tics_needed = static_cast<unsigned int> ( ( static_cast<double> ( _count ) /_expected_count ) *50.0 ); do { m_os << '*' << std::flush; } while ( ++_tic < tics_needed ); _next_tic_count = static_cast<unsigned long> ( ( _tic/50.0 ) *_expected_count ); if ( _count == _expected_count ) { if ( _tic < 51 ) m_os << '*'; m_os << std::endl; } } // display_tic }; _________ I'm sure the community will be open to discuss about it. Talk to you, Best, Pierre

2 2

boost.uuid is_pod failure
by Tim Blechmann 16 Jul '09

16 Jul '09

hi all, using boost.uuid from uuid_alt_v13_pod.zip, i get some static assertion failures of is_pod<boost::uuid> --- test_uuid.cpp~ 2008-12-06 02:27:38.000000000 +0100 +++ test_uuid.cpp 2009-07-15 10:59:01.016387917 +0200 @@ -22,6 +22,8 @@ #include <string> #include <vector> + +BOOST_STATIC_ASSERT(boost::is_pod<boost::uuid>::value); int test_main(int, char*[]) { i am not sure, whether it is a problem of is_pod or uuid, though ... best, tim -- tim(a)klingt.org http://tim.klingt.org Lesser artists borrow, great artists steal. Igor Stravinsky

3 3

Bug sprint aftermath questions.
by Marshall Clow 16 Jul '09

16 Jul '09

Now the bug sprint is over - I have a few questions..... * Was the bug sprint worth doing? * If so, is it worth doing again? How soon? Regularly? How often? * What worked really well? * What didn't work well? I'm also looking for general comments.... Facts: * We went from 797 open tickets to 706. (that's a change of 12%) * A lot of very old tickets were dealt with; the oldest Trac ticket is now from 2005 (instead of 2001). * There's still several tickets that have patches waiting to be applied. * The Trac system had a few problems ("locked database") and is still having spam problems, but worked reasonably well. -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

10 13

Behavior change in path operator /
by Gérald Fauvelle 16 Jul '09

16 Jul '09

Hi all, I'm updating my boost version from 1.33 to 1.38... That's a big step, and I've found a difference in operator / of filesystem::path. In 1.33, when I was doing : path a = path("d:/toto/titi"); path b = path("d:/tata/tutu"); path c = a/b; I had c == "d:/tata/tutu" So if b was a complete (or absolute) path, the result was b, whatever value has "a". I don't know if this behavior was correct or not, but we were using it this way, it was fine. Now with 1.38, I have : c == "d:/toto/titi/d:/tata/tutu" That is at first different from previous behavior, and also obviously wrong for a path syntax on Windows at least. It seems also that in 1.33 a path like this would raise an exception. I've tried to find when, in what version, this change occured, but couldn't find it in release notes. Was this change made intentionanly, if yes, what is the reason for that? And if I want previous behavior, I have 2 solutions. Fix my code, of fix boost code. I'm afraid that if I fix boost code I could break some boost functionnalities, or can I do it with no problem ? Thanks, Gérald

2 2