April 2006 - Boost - lists.boost.org

pqs: Physical Quantities pqs_3_0_7 in the vault
by Andy Little 04 Apr '06

04 Apr '06

Hi, The latest version of pqs , pqs_3_0_7 is now in the vault. For this version I spent some time in cleaning up, reorganising and extending the documentation. I have added some information on creating ones own quantities but its not complete yet. The tests have been reorganised so that emphasis is now on testing the interface and tests are more systematic and comprehensive too. I have also added an implementation of angles(radians, steradians, degrees, minutes,seconds etc) and added two sub namespaces of pqs; two_d and three_d, where can be found various geometry entities, such as vectors and matrices, that can be used directly with quantities. Unfortunately I havent had time to document these or write significant tests yet. Some clues as to proposed useage style for angles (which is based on the same style as for quantities) can be seen in <libs/pqs/test/angle/ange_test1.cpp> BTW. For anyone interested in the VC8_0 ADL bug, the vector class in <boost/pqs/three_d/vect.hpp> exhibits the behaviour too, but only when the value_type is a quantity (or any UDT???) IIRC. Because its a simpler class than the physical quantity that earlier showed the bug it might be easier to isolate it which I will try to do at some stage. regards Andy Little

1 0

using boost/detail/atomic_count.hpp and scope locking
by george 03 Apr '06

03 Apr '06

hi! class someclass { public: bool a_writer(...); bool a_reader(...); bool another_reader(...); .... private: .... boost::mutex mutex; boost::detail::atomic_count locked; }; someclass::someclass():locked(0) { } bool someclass::a_writer(.....) { boost::mutex::scoped_lock scoped_lock(mutex,true); ++locked; if(something) { ........... --locked; return true; } ............ --locked; return false; } bool someclass::a_reader(.....) { boost::mutex::scoped_lock scoped_lock(mutex,(locked!=0)); if(something) { ......... return true; } ............ return false; } bool someclass::another_reader(.....) { boost::mutex::scoped_lock scoped_lock(mutex,(locked!=0)); if(something) { ........... return true; } ............ return false; } I wanna combine atomic_count and scope locking so I can avoid locking on every operation. writers will get the lock,blocking all others,readers is able to go on. the method a_writer(....) is not used very often... I know that what I am doing is not recommended,atomic_count.hpp is for internal use only, but is so usefull!! would this work as I expect? does it worth it? thanks!

2 3

CVS problem
by Robert Ramey 03 Apr '06

03 Apr '06

For the last 24 hrs, I've been getting the following when I try to update from CVS. Is this just me or is there some general problem? Robert Ramey $ cvs update -r RC_1_34_0 cvs update: warning: unrecognized response `ssh: connect to host cvs.sourceforge ' from cvs servernection timed out cvs [update aborted]: end of file from server (consult above messages if any)

5 4

Re: [boost] [Boost-bugs] [ boost-Bugs-1461533 ] Non-basic-source-character-set characters conflict with MSVC
by Foster Brereton 03 Apr '06

03 Apr '06

I have attached a list to this email (There are 354 in the list as of this writing). I couldn't figure out how to attach the file to the bug report after-the-fact. Note that these are the most likely candidate source files to cause an error when building the Boost sources -- some test cases and example sources were omitted. Blessings, Foster On 3/30/06, Marshall Clow <marshall(a)idio.com> wrote: > At 9:43 AM -0800 3/30/06, SourceForge.net wrote: > >Bugs item #1461533, was opened at 2006-03-30 09:43 > >Message generated for change (Tracker Item Submitted) made by Item Submitter > >You can respond by visiting: > >https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1461533&group_… > > > > [ snip ] > > >Initial Comment: > >There exist high-ascii characters in the Boost sources that cannot > >be converted to the local region for a given computer because the > >context of the originating region of the source is not known. Thus, > >these high-ascii characters may not have a proper mapping, and a > >warning will be emitted by MSVC 2003 and 2005. This should be > >considered a failure case because, though low, it is still emitting > >an alert. Thus, without the correct region set on your system, the > >Boost sources fail to build. > > To whoever entered this bug (Foster? Nigel?) - please provide a list > of offending files in the bug report. > -- > -- Marshall > > Marshall Clow Idio Software <mailto:marshall@idio.com> > > It is by caffeine alone I set my mind in motion. > It is by the beans of Java that thoughts acquire speed, > the hands acquire shaking, the shaking becomes a warning. > It is by caffeine alone I set my mind in motion. > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > -- Foster T. Brereton - Computer Scientist Software Technology Lab, Adobe Systems Incorporated fbrereto(a)adobe.com -- http://opensource.adobe.com

7 12

Boost.Build Version 1 Jamfiles required for boost releases?
by Roland Schwarz 03 Apr '06

03 Apr '06

For every library that needs a bjam build of some source files there are two kinds of Jamfiles in the repository. The default is set to use version 1 Jamfiles. While trying to reorganize the threading library it looks like I could make good use of a feature that is only available in Boost.Build v2. I.e. having toolset specific source files. Unfortunately there is no work around available for the v1 Jamfiles. So my question is as whether v1 support is a requirement for boost releases. If yes, are there plans to drop this requirement at any time in the future? Roland

2 1

Re: [boost] [threading] rewrite (was: Bug list status)
by Martin Bonner 03 Apr '06

03 Apr '06

----Original Message---- From: Roland Schwarz > There is a new team that will try to handle the threading library. > We are currently busy trying to do a rewrite of the library on a > separate branch. Interesting. Why do you feel it needs a rewrite? (I'm not for a moment suggesting it doesn't, I'm just curious - I know very little about boost::thread). -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

8 15

Is there a preferred order of include files? Boost or std first?
by Paul A Bristow 03 Apr '06

03 Apr '06

I have been wondering if there is a preferred order of include files? Should I write (for example): #include <iostream> #include <boost/test/unit_test.hpp> or #include <boost/test/unit_test.hpp> #include <iostream> Or does it not matter? There seems no clear consistency in Boost files Paul PS IMO It would helpful to those reading code to have a consistent order. -- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow(a)hetp.u-net.com http://www.hetp.u-net.com/index.html http://www.hetp.u-net.com/Paul%20A%20Bristow%20info.html

4 3

[Boost-bugs] [ boost-Patches-1430820 ] [thread] [tss_hook.cpp] Suppress MSVC CRT memory leak report
by SourceForge.net 03 Apr '06

03 Apr '06

Patches item #1430820, was opened at 2006-02-13 18:49 Message generated for change (Settings changed) made by speedsnail You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1430820&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Open Resolution: None Priority: 5 Submitted By: Kevin J Bluck (kbluck) Assigned to: Roland Schwarz (speedsnail) Summary: [thread] [tss_hook.cpp] Suppress MSVC CRT memory leak report Initial Comment: MSVC CRT memory debugger pedantically complains about an unreleased singleton allocation. Although the consensus is that this is a harmless annoyance, it does cause some concern for MSVC users who don't know what is happening. Issue discussed in this Boost mailing list thread: http://lists.boost.org/boost-users/2005/08/13538.php Attached is a patch for tss_hook.cpp, which uses the function _CrtSetDbgFlag to temporarily turn off heap allocation tracking for the particular allocation in question. It should have no effect except on MSVC debug builds. On my configuration (msvc-8_0) it eliminates the leak warnings. ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2006-04-02 05:23 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Roland Schwarz (speedsnail) Date: 2006-03-18 21:12 Message: Logged In: YES user_id=541730 I will look into this, since AFAIK Michael Glassford currently is not available. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1430820&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Vault email notification gone crazy
by Jeff Garland 03 Apr '06

03 Apr '06

I'm getting a notification about once a minute right now from the vault...please shut it down if you can. Jeff

4 10

Re: [boost] [filesystem]please help
by Wang Weiwei 03 Apr '06

03 Apr '06

Hello me22, Thanks me22, but fs::path p("d:/temp",fs::path::native); // iirc seems to be fs::path p("d:/temp",fs::native); // iirc B/Rgds Max >On 4/2/06, Wang Weiwei <wwwang(a)ccsdl.org> wrote: >> namespace fs = boost::filesystem; >> fs::path p("d:/temp"); >> >> and I got an exception saying that "d:" in the input path is invalid. >> > >The constructor you're calling in this case expects the portable path >format, not the native one. You need to tell it that it's a >native-format path: >fs::path p("d:/temp",fs::path::native); // iirc > >I think this might be changing in the new and improved version in the >soon-to-be-released 1.34 however, so you might want to start >using/wait for the new version. > >~ Scott >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0