- Boost - lists.boost.org

explicit-failure-markups.xml broken
by JOAQUIN LOPEZ MU?Z 20 May '06

20 May '06

A recent change has broken this file, according to xmlvalidation.com the problem is: 390: 20 Open quote is expected for attribute "name" associated with an element of type "test". and the offending 390th line is <test name=limits_test""> I don't have CVS write access right now, so I can't fix this myself, would be grateful is someone did it. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] Random Access to Files (RAF) - any interest ?
by Jonathan Ray 20 May '06

20 May '06

Olaf van der Spek <olafvdspek(a)gmail.com> wrote: >Is it possible to read a range of bytes with a single function call? >Or would that require one function call per byte? One function call per byte would be extremely inefficient because of I/O latency unless the library, the driver, or the drive itself does a lot caching with some prefetching. Generally drivers will work faster when you declare what you want to do in as few calls as possible rather than splitting it up into many sequential function calls, because the all-at-once approach gives the driver more latitude in which to optimize the operation. I read the Performance section of the RAF paper and it seems they forgot to declare the units of the table and omitted any discription of the hardware that they ran the tests on. Those details are crucial. Cheers, Jonathan Ray

2 1

1.34
by Reed Kotler 20 May '06

20 May '06

Probably this question has been asked but I did not see any info on the web site.... Is there a projected date for boost 1.34

2 1

compressed_pair initialization
by David Abrahams 19 May '06

19 May '06

I find myself creating this class member: compressed_pair< storage , compressed_pair< Lookup , compressed_pair< GetUnstored , SetUnstored > > > members; I imagine this sort of usage is pretty common. The problem is that it's hard to initialize this member efficiently: you have to build and copy too many compressed_pairs. I propose to extend compressed_pair with overloaded ctors, as follows: compressed_pair( first_param_type f , typename second_type::first_param_type sf , typename second_type::second_param_type ss); compressed_pair( first_param_type f , typename second_type::first_param_type sf , typename second_type::second_type::first_param_type ssf , typename second_type::second_type::second_param_type sss ); ... etc. If SFINAE doesn't take out these declarations when the second type is not a (compressed_)pair, we can always template them. Thoughts? -- Dave Abrahams Boost Consulting www.boost-consulting.com

7 12

Infinite precision integer
by Maarten Kronenburg 19 May '06

19 May '06

Currently I'm working for LWG on a spec for tr2 for an infinite precision integer, which is almost finished. When it is finished I will put it here for you all to read and comment. Also I have a C++ implementation that will be submitted to boost some time. It will be a version that is pure C++, but that can also link in assembler code for performance. Currently I have the assembler for 32-bit x86 processors using MMX/SSE. The implementation compiles with Borland C++ Builder, Visual C++ and Gnu C++, with matching assemblers. Assembler speeds up the implementation considerably. So my implementation should bring together the best of C++ and assembler. Regards, Maarten.

6 9

Re: [boost] [review][pimpl_ptr] Pimpl Pointer review begins
by Martin Bonner 19 May '06

19 May '06

----Original Message---- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Asger Mangaard Sent: 19 May 2006 09:28 To: boost(a)lists.boost.org Subject: Re: [boost] [review][pimpl_ptr] Pimpl Pointer review begins > Tobias Schwinger wrote: >>> Could you give an example? >>> >> >> Let's see (untested and incomplete code for illustration only): >> .... > > It seems like you assume that two pimpl_ptr instances can hold the > same pointer. This is _not_ the case. Each instance of pimpl_ptr > will have its own instance of T, thus the COW (copy on non const > access) isn't needed. I thought Tobias' code was supposed to be an example of how to use a putative COW_pimpl_ptr, not an example of how to use the current code. For such a class obviously two instances _can_ hold the same pointer (that would be the whole POINT of the class!) -- 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

boost shmem with file descriptors
by Ryan, Paul L. 19 May '06

19 May '06

Ion, We've spoken earlier about a couple of bugs an associate and I found in the shmem library and I was wondering if you had any suggestions for an interesting problem I've encounterd. My current project requires that my use of the shared memory segment that we're using be selectable with either select or poll, which in effect means that the segment (or portions of it) need to have file descriptor associated with it. I know of ways that I can hack this by sending the file descriptor outside of the shmem segment and maintaing a fake file for each portion of shmem that I need to access but I was wondering if you (or any other boost list members) know of a better way to do this using the boost::shmem functionality. Thank you for your time, Paul Ryan SAIC - Tactical Systems

2 1

[cvs] It's back...
by Rene Rivera 19 May '06

19 May '06

Not that SF bothered to point out they cleared out all the stale locks. But I just managed to do some complete checkouts. So I thought people would like to know :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

1 0

Binding a bitset to a specific integral variable instance
by Baranowski, Daniel 19 May '06

19 May '06

Being relatively new to the Boost community, I'm not sure if this has already been brought up, but after searching the mailing list archives, I couldn't find anything, so my apologies if I'm bringing up an old subject... I really enjoy the syntax and ease of use of std::bitset and therefore boost::dynamic_bitset, but I don't see a way, unless I'm missing something, to perform those same operations on an int or long that exists outside of the bitset object. Specifically, in having to deal with legacy code that uses a bitmask, it would be nice to be able to operate on the int or long without doing copies to/from a bitset object. Has any consideration been given to a bitset-like object that will do such things? Or is this problem too trivial to consider? Once again, forgive me if I'm just repeating someone else, or if this functionality already exists and I just missed it! V/R, Daniel PS. A BIG high-five to all the developers who have contributed to Boost! My life expectancy has increased by at least 5 years because of you! ********************************************************************************************** Disclaimer - This email and any files transmitted with it are proprietary and may contain privileged or copyright information. You must not present this message to another party without gaining permission from the sender. If you are not the intended recipient you must not copy, distribute or use this email or the information contained in it for any purpose other than to notify us. If you have received this message in error, please notify the sender immediately, and delete this email from your system. We do not guarantee that this material is free from viruses or any other defects although due care has been taken to minimize the risk. eSafe scanned this email for viruses, vandals and malicious contentAny views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of LSI. **********************************************************************************************

1 0

progress_display templated
by Brannon King 18 May '06

18 May '06

Currently progress_display is hard-coded to an unsigned long value. There is a note in the code about an attempted use of intmax_t instead. I think that is overkill. What we should do, however, is template the function so that the user can use any dataset they want. We can default the template to unsigned long and it will work just as it does now. Any complaints? ______________________________ Brannon King ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

1 0