- Boost - lists.boost.org

Re: [boost] [spirit] Ternary Search Tree (TST) revisited
by rasmus ekman 24 May '06

24 May '06

Joel de Guzman wrote: > > As many of you might not know, there's a nice TST(*) > implementation in the Spirit CVS written by Steve Rowe > I would want to use it as the basis for Spirit-2's symbol > table. The objective is to optimize the code and do some > benchmarks with it. You may want to look at http://www.abc.se/~re/code/tst It's not finished, but may be usable in present state. The unfinished interface bit is: defining subkey iterators, and rewrite the imprecise matching algorithms as nonmember functions. I define the TST containers as Associative Sorted with internal structure in the keys - the keys are Forward Containers. (hence the name Structured Containers, but this may be an overstatement, suggestions welcome) So iterators should perhaps use a variant of segmented iterators - though not for performance purposes. I haven't found time to finish it (I just use it as is), but with some suggestions for interface and implementation I could perhaps get going again. The implementation is needlessly messy in spots, as I tried to do without Boost.Iterator and MPL. > (*) > Ternary Search Tree implementation. The data structure is faster than > hashing for many typical search problems especially when the search > interface is iterator based. Searching for a string of length k in a > ternary search tree with n strings will require at most O(log n+k) > character comparisons. TSTs are many times faster than hash tables > for unsuccessful searches I have not found this to be generally true, at least not the "many times faster" claim, at least not for the implementations I've seen. "About as fast as hashed containers" is a more reasonable statement. Please see http://www.abc.se/~re/code/tst/tst_docs/tst_perf.html re

3 2

Google Summer of Code -- 10 Projects Assigned!
by Jeff Garland 24 May '06

24 May '06

Hi All - Just a quick note to let everyone know that Boost has been assigned 10 SOC projects! This is more than we expected and I'm hopeful will result in some great work. Even so, there are many excellent students and projects that applied for Boost projects and were NOT selected. The competition for these 10 slots was quite brutal. The choices were extremely difficult to make. It was often very hard to decide between a totally novel, high risk, project proposal and a fairly straight-forward extension to a current library. As you'll see, we ended up with some of both. The mentors have been trying to reach everyone with a notification one way or another, but it's a large list. All applicants should have heard from Google by now. If you have questions you can post to boost_soc2006(a)crystalclearsoftware.com and someone should get back to you. I'm not going to publicy share the details of the list just yet -- until we are sure all the administrative items are confirmed (google apparently accidently informed 1800 people they were accepted and then had to retract). Eventually the list should show up here: http://code.google.com/soc/boost/about.html Jeff

2 1

[range] atl/mfc support
by Shunsuke Sogame 24 May '06

24 May '06

Hi, I wrote an "interest" version of Boost.Range support for ATL/MFC: http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam… or http://tinyurl.com/evddv There are *40* ranges. The test is problematic... It is possible to fail to complete. :-( They are roughly tested under: VC7.1 + ATL7 + MFC7 VC8 + ATL3 and Boost.Range at cvs BTW, I found a bug: <boost/range/concepts.hpp> seems to apply 'boost::size' to Forward Range. Thanks! -- Shunsuke Sogame

3 10

[SoC][misc] Project Accepted!
by Matias Capeletto 24 May '06

24 May '06

Boost.Misc, (M)ulti (I)ndex (S)pecialized (C)ontainers, is in SoC 2006! I want to thank boost mentors for trust in me, I will work very hard! Good luck to the other applicants! (accepted and rejected ones) I have set up some online resource to start my project. MC++ Blog [ matiascpp.blogspot.com ] ---------------------------------------------------------------------- This is my blog, and I will use it to post no so technical information about the project. Online Docs [ h1.ripway.com/mcape/boost/libs/misc ] ---------------------------------------------------------------------- The original proposal docs will be filled with new stuff during the project. The idea is that in the end it will be the user manual, a SoC project related information repository and library history reference. Discussion Group [ groups.google.com/group/boostMiscSoC ] ----------------------------------------------------------------------- In order to avoid polluting the boost developer list, I have created a group where to discuss technical details about the project. Please join the group if you are interested in the project, I will really appreciate your comments. When a thread is interesting enough I will post it here for a deeper and broader discussion. I have already post my mentor ( Joaquin Lopez Muñoz) questions and my responses to start discussing. boost rocks! Best Regards Matias Capeletto

1 0

[for_each] suggestion for new macro
by Thorsten Ottosen 24 May '06

24 May '06

Hi Eric, Here's an idea for a macro to complement BOOST_FORACH. Use example: BOOST_ITER_FOREACH( i, get_range() ) { std::cout << *i; } It shoul be quite easy to generate a for-loop behind the scene. The motivation for having this macro would be that often you actually need access to the iterator because it provides much more details than the value-type, eg. - the base-iterator - index etc. With the upcoming range adaptors, the creation of ranges/iterators of unknown type could be much more common. -Thoorsten

4 6

[asio][filesystem] system error handling
by Christopher Kohlhoff 24 May '06

24 May '06

Hello all, I have been thinking about how to reconcile Boost.Asio error handling with the system error classes defined in the TR2 filesystem proposal N1975. I have some concerns which I'll outline in the context of how I plan to use them. The current plan is as follows: - Synchronous functions would by default throw a system_error exception. - An overload of each synchronous function would take an error_code& as the final argument. On failure these functions set the error_code to the appropriate error. On success, the error_code is set to represent the no error state. These functions do not throw exceptions. - Callback handlers for asynchronous functions would take an error_code as the first parameter. For example: void handle_read(error_code ec) { ... } - Since many error codes in socket programming are "well-known" and often tested for explicitly, they need to be defined somewhere. The current errors in the asio::error::code_type enum would be replaced by constants of type error_code: namespace boost { namespace asio { namespace error { const error_code access_denied = implementation_defined; const error_code message_size = implementation_defined; ... } // namespace error } // namespace asio } // namespace boost (Note that in practice boost::asio::error might actually be a class with static members rather than a namespace). The issues I have run into so far are: - The error_code class seems to assume that there is a single "namespace" for the system_error_type values. This is not necessarily the case for the errors in socket programming. For example on UNIX most socket functions use errno values, but the netdb functions (gethostbyname and friends) use a different set of error values starting from 1, and the getaddrinfo/getnameinfo functions use another set of error values starting from 1. Would it be possible for the error_code class to have a category value (which is probably an integer with implementation-defined values) to allow the creation of unique error_code values for each type of system error? A category value would also allow implementors and users to extend the system error classes for other sources of system error (e.g. SSL errors, application-specific errors, etc). - A common idiom in code that uses asio, when you don't care about a specific error type, is to simply treat the error as a bool: void handle_read(asio::error e) { if (e) { // take action because of error } else { // success } } Can the error_code class be made convertible-to-bool and also have operator! to support this style? - Are these classes available in CVS somewhere so they can be reused by other boost libraries? Cheers, Chris

5 7

[math : special functions] Borland 5.8 fail of hypot test
by AlisdairM 24 May '06

24 May '06

The test is currently failing on the following line: ( BOOST_ROOT/boost/math/special_functions/hypot.hpp line 32) BOOST_ASSERT(std::numeric_limits<T>::is_specialized); I believe the problem is Borland's traditional bad handling of const parameters with templates. In the case of this test, T deduces as const double, so of course numeric limits is not specialized. I believe the workaround will be to detect Borland compiler, and do a remove_const on T for the whole function, or perhaps detect const and forward to an explicit call to the non-const function. A similar patch would be applied to: expm1.hpp log1p.hpp Are the library maintainers interested in supporting such a patch? Should we introduce the type_traits dependency (Checking for the Borland platform first?) Should we look to patch mainline, or 1.34 branch. The only active regression testing on Borland is on the 1.34 branch at the moment. -- AlisdairM

2 1

Re: [boost] Random Access to Files (RAF) - any interest ?
by Martin Bonner 24 May '06

24 May '06

----Original Message---- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Slava, Alex Sent: 23 May 2006 22:32 To: boost(a)lists.boost.org Subject: Re: [boost] Random Access to Files (RAF) - any interest ? >> On 5/22/06, Tomas Puverle <Tomas.Puverle(a)morganstanley.com> wrote: > ... >>> There are filesystems out there that support 128 bits for file >>> sizes. So I think there needs to be a more general solution. >>> > > Totally agree about more general solution. Another reason for wanting a more general solution, is coping with the user wanting many RAF objects at once. That also means that the user needs to be able to specify whether to map the whole file or a window. (The implementation might think there is nothing wrong with mapping the whole of this 1G file on a 32-bit operating system, but the user may be about to open another three such files - which won't fit!) > > That does not change anything, but just out of curiosity some > calculations were made: the number of atoms in the graphite of a > pencil is < 2^72, > > http://www.madsci.org/posts/archives/oct98/905633072.As.r.html > > so the storage providing capacity to hold files with 128-bit offset > would have to contain at least as many atoms as 8*2^56 = 2^59 pencil > leads ! Hundreds of tons of material that should be. And this is with > just 1 atom per bit of information. Seems a bit too much for any > conceivable technology... What FS would need to provide support for > such capacities ? -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

1 0

[serialization] Header Ordering tests for Borland
by David Abrahams 24 May '06

24 May '06

As far as I can tell, in the current CVS state (even after my patch) none of the test_exported_xxx tests will build for Borland... Fatal F1003 ..\..\..\boost/spirit/core/config.hpp 56: Error directive: "Compiler not supported. See note in <boost/spirit/core/config.hpp>" *** 1 errors in Compile *** ...of course, I don't have Spirit 1.6 installed, but even msvc 6 and 7 will run enough of the test_exported_xxx tests to verify that things are working. So, is this a problem? I don't think I can test against Borland. -- Dave Abrahams Boost Consulting www.boost-consulting.com

4 8

[serialization] array problems and patch (cont'd)
by David Abrahams 23 May '06

23 May '06

...and I'm seeing the following array-related problems: testing.capture-output ..\..\..\bin.v2\libs\serialization\test\test_exported_array_binary_archive.test\msvc-7.1\debug\test_exported_array_binary_archive.run ====== BEGIN OUTPUT ====== Assertion failed: NULL != bpos_ptr, file ..\..\..\boost/archive/detail/oserializer.hpp, line 419 testing.capture-output ..\..\..\bin.v2\libs\serialization\test\test_exported_array_binary_archive_dll.test\msvc-7.1\debug\test_exported_array_binary_archive_dll.run ====== BEGIN OUTPUT ====== Assertion failed: NULL != bpos_ptr, file ..\..\..\boost/archive/detail/oserializer.hpp, line 419 Not to mention quite a few vc6-bug-specific problems (just about every test fails with this error): test_exported.cpp ..\..\..\boost/serialization/array.hpp(69) : error C2265: '<Unknown>' : reference to a zero-sized array is illegal These problems are making it hard for me to know that I haven't broken anything. -- Dave Abrahams Boost Consulting www.boost-consulting.com

5 11