- Boost - lists.boost.org

[vc6] LNK1179 Workaround Found
by David Abrahams 24 May '06

24 May '06

http://tinyurl.com/moxw8 (http://groups.google.com/group/microsoft.public.vc.language/ browse_frm/thread/811cc53a3d36d276/44768de68d91a640) describes a long list of vc6 bugs along with workarounds, but the workaround for this message's title bug is not transparent: the static member of the function will not necessarily be constructed during the program's dynamic initialization. This problem has reared it's ugly head many times for the serialization library, but I've just found a fix: http://tinyurl.com/ljdp8 (http://groups.google.com/group/microsoft.public.vc.language/ browse_frm/thread/90354d2e722c7d99/d42bff533ccdf364) Just to make sure this information doesn't get lost, I'm also posting a copy of the workaround as applied to the OP's example here. Enjoy, (if you run into this problem). -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

[serialization] vc6 and Header Ordering
by David Abrahams 24 May '06

24 May '06

Hi Robert, The header ordering issue is solved... except on vc6. Unfortunately the technique depends on instantiating static members of templates with more than two dependent types, which leads ultimately to the same problem described here: http://www.boost.org/libs/serialization/doc/implementation.html#vc6. I've made lots of clever attempts at workarounds, but this compiler bug is etremely stubborn. If you're interested in a fix for the issue that doesn't work on vc6, or if you're ready to drop support for vc6, then I'll proceed. Otherwise, please let me know and I'll check my work in on a branch for posterity. Thanks, -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 4

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