January 2008 - Boost - lists.boost.org

[regex] unknown escape sequence in libs/regex/test/regress/test_perl_ex.cpp
by Boris Gubenko 14 Jan '08

14 Jan '08

regex library tests regex_regress[_threaded] fail to compile on gcc-4.2.1_hpux_ia64 because for a character string "(?<=*|\B)" gcc 4.2.1 emits a hard error "unknown escape sequence". gcc 3.4 series issues a warning, as well as EDG-based compilers. See reproducer below. The character string in question should, probably, be: "(?<=*|\\B)". Ok to change? Thanks, Boris x.cpp ----- char s[] = "\B"; bash-2.03$ g++ --version | head -1 ; g++ -c x.cpp g++ (GCC) 4.2.1 x.cpp:1: error: unknown escape sequence '\B' bash-2.03$ bash-3.00$ g++ --version | head -1 ; g++ -c x.cpp g++ (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3) x.cpp:1:12: warning: unknown escape sequence '\B' bash-3.00$ bash-2.04$ eccp --version -c x.cpp Edison Design Group C/C++ Front End, version 3.5 (Dec 20 2004 13:57:48) Copyright 1988-2004 Edison Design Group, Inc. "x.cpp", line 1: warning: unrecognized character escape sequence char s[] = "\B"; bash-2.04$

2 3

TR1 beta for MSVC 9 RTM
by Peter Dimov 13 Jan '08

13 Jan '08

http://blogs.msdn.com/vcblog/archive/2008/01/08/q-a-on-our-tr1-implementati… Sounds like some pretty nice work.

3 2

[Intel 10.1] Needs to be configured
by Beman Dawes 13 Jan '08

13 Jan '08

I'm getting this from Intel 10.1: Unknown compiler version - please run the configure tests and report the results I'm traveling for the next two days and can't do anything about it. I'd appreciate it if someone could make the needed config changes. --Beman

2 2

[random] failure of random_test on Red Hat Linux 2.6.9 ia64
by Boris Gubenko 13 Jan '08

13 Jan '08

Boost.Random library test random_test fails on linux_ia64_gcc: see <http://tinyurl.com/32hqlu> . It fails with the similar errors on Sandia-pathscale: see <http://tinyurl.com/2va9tz>. Both platforms are Red Hat Linux 2.6.9 ia64: . linux_ia64_gcc is Red Hat Linux 2.6.9-42.EL . Sandia-pathscale is Red Hat Enterprise Linux 2.6.9-34.0.2.ELsmp The test does NOT fail on Sandia-gcc-64 which is a Red Hat Enterprise Linux 2.6.18-8.el5. x.cpp below is a reduced reproducer. It passes on every platform I tried it on, including Debian GNU/Linux ia64, except Red Hat Linux 2.6.9-42.EL. On the latter, it fails for long double which is how the original test random_test fails on linux_ia64_gcc. On the platforms where it passes it outputs: *** testing float *** g = 1.353399e+00 g2 = 1.353399e+00 *** passed *** *** testing double *** g = 1.353399e+00 g2 = 1.353399e+00 *** passed *** *** testing long double *** g = 1.353399e+00 g2 = 1.353399e+00 *** passed *** On Red Hat Linux 2.6.9-42.EL it outputs: *** testing float *** g = 1.353399e+00 g2 = 1.353399e+00 *** passed *** *** testing double *** g = 1.353399e+00 g2 = 1.353399e+00 *** passed *** *** testing long double *** g = nan g2 = 1.000000e+00 *** failed *** The comment in explicit-failures-markup.xml for random_test for intel-linux-9.0 toolset says: Reported to Intel as issue 409291, and confirmed as a problem. Probably this relates to a specific Linux-Kernal or GLibC version." I'm wondering: is this problem specific to a Linux Red Hat 2.6.9 ia64 Kernal or GLibC version on this platform? Thanks, Boris x.cpp ----- #include <cmath> #include <stdio.h> #include <boost/random.hpp> template<class URNG, class Dist> void instantiate_dist(URNG& urng, const Dist& dist) { boost::variate_generator<URNG, Dist> gen(urng, dist); boost::variate_generator<URNG&, Dist> genref(urng, dist); long double g = gen(); long double g2 = genref(); printf("g = %Le g2 = %Le\n", g, g2); if ( std::abs(g - g2) < 1e-6 ) puts("*** passed ***"); else puts("*** failed ***"); } template<class T> void test() { boost::rand48 urng; urng.seed(); instantiate_dist(urng, boost::triangle_distribution<T>(1, 1.5, 7)); } int main() { puts("*** testing float ***"); test<float>(); puts("*** testing double ***"); test<double>(); puts("*** testing long double ***"); test<long double>(); }

1 2

Re: [boost] [Boost-users] Review: Switch library
by Hartmut Kaiser 13 Jan '08

13 Jan '08

Joel de Guzman wrote: > Richard wrote: > > [Please do not mail me a copy of your followup] > > > > boost(a)lists.boost.org spake the secret code > > <fmblls$ees$1(a)ger.gmane.org> thusly: > > > >> I also urge Steven to pursue the dynamic_switch idea I > posted which > >> employs perfect hashing at compile time whereby allowing > equivalent > >> or faster than a switch dispatch at runtime where the cases are > >> dynamic (instead of compile time constants). > > > > I just want to say that I think this approach is so > amazingly cool, my > > socks are not only blown off, but orbiting the planet :-). > > Yes, it's so cool. I believe it can be done. A well designed > compiler implements switch using perfect (or near perfect) > hashing anyway. Seems though that some compilers still don't. > > Here's the relevant link (with attached experiment code): > > http://lists.boost.org/Archives/boost/2004/08/69787.php FWIW, I did a lot of work related to perfect hash generation lately (up 100 million entries in the hash table) and I second Joels request. Perfect hashs are a _very_ fast alternative to sequenced if/else if chains. The beauty of this is, that it is possible to generate perfect hashs for any type of key, not only for integer values, which again is of particular interest in dynamic switch scenarios. And I'ld be happy to help with this. Regards Hartmut

1 0

Re: [boost] [Boost String Algorithms library] ireplace_all bug with character arrays
by Thorsten Ottosen 13 Jan '08

13 Jan '08

shunsuke skrev: > Richard Turrin wrote: >> Hi, >> >> I've encountered a bug with ireplace_all from the Boost String Algorithms library for version 1.35. If I pass a character array for the Format argument, the function ignores the null terminator and instead uses the entire array minus the last character to replace the occurrences of the Search string in the Input parameter. However, if I provide a pointer to a character array, the string replacement is done as expected. >> >> When I stepped into the code, I came across the following lines (excerpt from /trunk/boost/range/as_literal.hpp): >> >> template< class Char, std::size_t sz > >> inline iterator_range<const Char*> as_literal( const Char (&arr)[sz] ) >> { >> return boost::make_iterator_range( arr, arr + sz - 1 ); >> } >> >> There is no check for a null terminator. Nor did I find one after this function returned. I think the author here assumed that a caller would always pass in a character array of the right size. > > Character array seems to have three views. > > 1. array: SIZE("ab\0c") == 5; > 2. literal: SIZE("ab\0c") == 4; > 3. null-terminated: SIZE("ab\0c") == 2; > > Both 2. and 3. is forced into boost::as_array. > "One name, two facilities" usually makes trouble. > IMO, `as_c_str` should have been added for 3. I agree we could add a new function. Can we come up with a better name than as_c_str()? Or should we simply make as_literal() scan the array? -Thorsten

1 0

Re: [boost] Review: Switch library
by Joel de Guzman 13 Jan '08

13 Jan '08

Tobias Schwinger wrote: > Joel de Guzman wrote: >> Richard wrote: >>> [Please do not mail me a copy of your followup] >>> >>> boost(a)lists.boost.org spake the secret code >>> <fmblls$ees$1(a)ger.gmane.org> thusly: >>> >>>> I also urge Steven to pursue the dynamic_switch idea I posted >>>> which employs perfect hashing at compile time whereby allowing >>>> equivalent or faster than a switch dispatch at runtime where >>>> the cases are dynamic (instead of compile time constants). >>> I just want to say that I think this approach is so amazingly cool, my >>> socks are not only blown off, but orbiting the planet :-). >> Yes, it's so cool. I believe it can be done. A well designed >> compiler implements switch using perfect (or near perfect) >> hashing anyway. Seems though that some compilers still >> don't. > > Another interesting approach could be "adaptive switch" as explained here: > > http://osdir.com/ml/parsers.spirit.devel/2006-05/msg00025.html > > (a self-optimizing alternative parser). Maybe it can be combined with > hashing techniques. Yeah, it's a very interesting idea! Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

1 0

Re: [boost] Review: Switch library
by Joel de Guzman 13 Jan '08

13 Jan '08

Joel de Guzman wrote: >> 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. > > Not at the moment. I think we need a more thorough discussion on > alternative interfaces. We also need to discuss the issues > that were raised in the review. I'm eager to hear Steven's > replies. He seem to be a bit too quiet? > > I'm really tempted to say "yes" and let Steven address the concerns > raised (including mine). I'm very confident in Steven's abilities. > He's one of those who still gives me the "oooh" feeling with his > code. And, I really *NEED* such a switch utility now and not later. > > So, please take this as a soft "no" vote for now. I encourage > Steven to get more involved in the discussion and consider > all the issues raised. As soon as these matters are ironed out, > fire up another review ASAP. Oh, perhaps I'd like to ask a review extension. If Steven can reply to my concerns and is willing to address them, I might still change my vote to a yes. I really need this facility now! Bottom line: more discussion please! This is a small library, yet it is (to me) very important. Let's get the design correct. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

2 3

Re: [boost] [Range] Misc comments
by bwood 13 Jan '08

13 Jan '08

Thorsten Ottosen wrote: >brass goowy skrev: >> utility_class.html says, "Recall that many default >> constructed iterators are singular..." >> >> I didn't find other uses of the word singular in the >> documentation and am not sure what you mean. Are you >> saying they are not meant to be range endpoints? > > From the standard 24.1: > >"Iterators can also have singular values that are >not associated with any container. [ Example: After the declaration of >an uninitialized pointer x (as with int* x;), x >must always be assumed to have a singular value of a pointer. ?end >example ] Results of most expressions are undefined >for singular values; the only exceptions are destroying an iterator that >holds a singular value and the assignment of a >non-singular value to an iterator that holds a singular value. In this >case the singular value is overwritten the same way >as any other value. Dereferenceable values are always non-singular." > OK, thanks. >> I think the "sub" in the class name sub_range is kind of >> misleading. The documentation has the following: >> "Imagine that we have an algorithm that searches for a >> sub-string in a string. The result is an iterator_range, >> that delimits the match. We need to store the result from >> this algorithm. Here is an example of how we can do it with >> and without sub_range >> >> std::string str("hello"); >> iterator_range<std::string::iterator> ir = find_first( str, "ll" ); >> sub_range<std::string> sub = find_first( str, "ll" );" >> >> The docs also say, "The iterator_range class is templated on an >> Forward Traversal Iterator and should be used whenever fairly >> general code is needed. The sub_range class is templated on an >> Forward Range and it is less general, but a bit easier to use >> since its template argument is easier to specify. The biggest >> difference is, however, that a sub_range can propagate >> constness because it knows what a corresponding const_iterator is." >> >> The sample code that has a sub-string with either an >> iterator_range or sub_range and the description of the >> two classes don't give much basis for sub being in the >> name. > >So you would just call it range? Possible, but difficult to do now. > I prefer range to sub_range. It isn't that important to me, but I suggest you make some comment in the documentation about the matter. That might lead to some further ideas. >> I didn't find anything about serialization in the docs. >> iterator_range has an operator<<, but understandably no >> operator>>. Do you plan to add something in this area? > >No. Don't Boost.Serialization have support for serializing a [begin,end) >range? Not to my knowledge. Even if B.Ser had that, I think using it would require what you are encouraging people to get away from with the Range library: passing around iterators. Brian Wood Ebenezer Enterprises www.webebenezer.net

1 0

Switch library review - summary of discussion so far
by Stjepan Rajko 12 Jan '08

12 Jan '08

I will try to summarize the discussions happening so far on the Switch library under review - maybe this will be helpful to those considering joining the discussion and submitting a review. * Documentation All reviewers have noted that the documentation could be improved - e.g., additional examples, performance stats, as well as more explanation of the types involved and how they are used. * Return type Tobias Schwinger suggested that the return type should be specified explicitly in the switch_ call, rather than inferring it from the function object, and this is now a part of the recent designs being discussed. Joel de Guzman also suggested that if a version of switch_ should infer the return type, that return type should be a Boost.Variant of the types returned by each of the cases. * Default default behavior If the default behavior is left unspecified, switch_ should invoke the default constructor of the return type in the default case, rather than throwing an exception. This was suggested by Tobias Schwinger after the issue was raised by Dan Marsden. Alexander Nasonov has also indicated that a throwing default case can cause inefficiency, even when it is guaranteed not to be invoked. * Fall-through Alexander Nasonov pointed out the lack of fall-through capability in the submitted implementation. Fall-through has been incorporated into the recent designs being discussed. * Allowing void-returning function objects for the default case with a non-void returning switch Tobias Schwinger mentioned the possibility of allowing default case function objects of void return type even when the switch return type is non-void, as long as the function object call does not return. This would be useful, for example, if the function object is guaranteed to throw. There is still some discussion on whether determining if the return type is void can be done efficiently. * Design There has been a lengthy discussion on the underlying design of the library, what it should offer, and whether the name of the library is appropriate. There are two types of designs that have been put forward as being appropriate and/or necessary for a Boost.Switch library. On one hand, there is the submitted design (labeled "A" in recent postings), which takes the switch cases in an MPL sequence and a single function object containing implementations of all cases. Joel de Guzman has proposed another design (labeled "B"), in which the switch cases are specified separately and allow a different function to be used for each case. Design "A" is better suited for situations in which the number of cases is determined by a compile time constant, while "B" is more appropriate for many use cases, and provides more flexibility and a more familiar syntax. It seems that a consensus has been reached that this library could offer either both interfaces in different layers, or an interface that can be used in different ways for different uses (based on a common concept capturing case sequences). (Apologies if I have missed or misinterpreted something) More reviews/votes would be extremely welcome! Regards, Stjepan

2 2