May 2006 - Boost - lists.preview.boost.org

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

Re: [boost] boost::noncopyable
by Sohail Somani 18 May '06

18 May '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Michael Goldshteyn > Sent: Thursday, May 18, 2006 2:25 PM > To: boost(a)lists.boost.org > Subject: [boost] boost::noncopyable > > Is there a reason why the prototype for noncopyable's > operator= is improper. > It is: > > const noncopyable& operator=( const noncopyable& ); > > instead of > > noncopyable& operator=( const noncopyable& ); Isn't this private and not implemented, therefore making the point moot? It should be by my guesstimate. > Also, shouldn't the destructor really be virtual? You can't seriously be deleting pointers to noncopyables...

1 0

boost::noncopyable
by Michael Goldshteyn 18 May '06

18 May '06

Is there a reason why the prototype for noncopyable's operator= is improper. It is: const noncopyable& operator=( const noncopyable& ); instead of noncopyable& operator=( const noncopyable& ); Also, shouldn't the destructor really be virtual? Michael Goldshteyn

1 0

[Announce] Boost Installer for Visual C++ 7.1/8.0
by David Abrahams 18 May '06

18 May '06

Boost Consulting is pleased to announce the availability of a Windows installer for the current Boost release (1.33.1). See: http://www.boost-consulting.com/download.html Thanks to everyone who made this possible, including Rene Rivera, Eric Niebler, Devin Smith, and especially to Daniel Wallin, who applied most of the elbow grease. Enjoy! -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

[WIKI][SoC] Spammed!
by Andreas Huber 18 May '06

18 May '06

There has been some massive spamming of the Boost Wiki roughly 8 hours ago: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?action=rc&da… -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

2 1

Re: [boost] [Announce] Boost Installer for Visual C++ 7.1/8.0
by Greer, Joe 18 May '06

18 May '06

> From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Chris Little > Subject: Re: [boost] [Announce] Boost Installer for Visual C++ 7.1/8.0 > > on 5/17/06 5:46 PM, JOAQUIN LOPEZ MU?Z at joaquin(a)tid.es wrote: > > > It'd be great if the app showed a more sensible explanation > > of the problem; I'm not so sure whether the default installation > > dir should be one accessible to all users (for instance, > > the dir with moniker CSIDL_COMMON_APPDATA, typically > > "C:\Documents and Settings\All Users\Application Data".) > > You need to be at least a Power User to write to All Users\Application > Data > and Program Files so that isn't really a good option either. There is no > directory guaranteed to be writeable by all users. > > Chris I think the default should remain "Program Files". Nearly everything installs there by default and if boost were to do something different then it could potentially be more confusing. Users without permission to write to install programs presumably know that and can change the install directory to some place they have appropriate rights. Of course, the error message should convey the actual problem, if it can be determined. joe

1 0

Re: [boost] [Announce] Boost Installer for Visual C++ 7.1/8.0
by JOAQUIN LOPEZ MU?Z 18 May '06

18 May '06

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Miércoles, Mayo 17, 2006 11:06 pm Asunto: [boost] [Announce] Boost Installer for Visual C++ 7.1/8.0 > > Boost Consulting is pleased to announce the availability of a Windows > installer for the current Boost release (1.33.1). See: > > http://www.boost-consulting.com/download.html > Hello Dave, suggestions for improvement: when the installer is being executed by an user without administrator privileges: 1. The default installation directory (rooted in Program Files) is not allowed for writing. 2. When the installer tries to write there, it (expectedly) fails, but the error message is misleading (see attached snapshot). It'd be great if the app showed a more sensible explanation of the problem; I'm not so sure whether the default installation dir should be one accessible to all users (for instance, the dir with moniker CSIDL_COMMON_APPDATA, typically "C:\Documents and Settings\All Users\Application Data".) HTH, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1