- Boost - lists.boost.org

[Boost-bugs] [ boost-Patches-1464421 ] Explicitly delete registered converter chains
by SourceForge.net 04 Apr '06

04 Apr '06

Patches item #1464421, was opened at 2006-04-04 11:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1464421&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: Python Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kevin J Bluck (kbluck) Assigned to: David Abrahams (david_abrahams) Summary: Explicitly delete registered converter chains Initial Comment: While working with boost.python, I've noted that instantiating most specializations of boost::python::extract<> results in MSVC leak reports. My usual tactic for third-party libraries in such cases is to suppress the CRT tracking for the affected code. This is how I deal with the abundant "leaks" from Python due to not calling Py_Finalize(), for example. In this case, though, the allocations are pre-main() and I can't get a suppression hook in ahead of it. I realize that these aren't true leaks, and that there is some reluctance to ferret out such situations at the moment due to the lack of support for Py_Finalize(), but this generates a *lot* of leak reports and makes it very difficult to recognize true leaks. It was actually making me consider not using extract<> at all. I realized that was an overreaction, so instead I added a destructor for struct boost::python::converter::registration that explicitly walks and deletes the singly-linked list nodes contained therein. This resolved my current flurry of extract<>-related leak reports. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1464421&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

[review] promotion traits
by Daniel Wesslén 04 Apr '06

04 Apr '06

> Please always explicitly state in your review, whether you think the library should be accepted into Boost. Yes, I think it should be accepted. I think it should be applied to lexical_cast as previously suggested, and if it is already included with the distribution for that purpose then making it a public interface does little harm while making a useful feature easily accessible for others to use, who would otherwise probably not bother or think to implement it. > - What is your evaluation of the design? Initially I had some reservations about user-defined types being silently passed through. On second thought, the submission serves a very specific use, and limiting the valid input to the relevant arithmetic types would complicate the common use case with little benefit (it is unclear to me who would be better served by a more strict version.) > - What is your evaluation of the implementation? Looks straightforward enough to me. > - What is your evaluation of the documentation? Minimal but sufficient. The examples could use some tweaking - "int const" is always used as the example of a type that isn't promoted, while none of the promoted types are cv-qualified. I would rather see a plain "int" as non-promoted and "short const" -> "int const". This to demonstrate that cv-qualifiers are kept and to take a way a possible first-glance impression that const inhibits promotion. > - What is your evaluation of the potential usefulness of the library? While of limited use, I believe the submission is valuable enough when it is usable - as a tool to reduce near-identical template instantiations - to justify inclusion in the type_traits library. > - Did you try to use the library? With what compiler? > Did you have any problems? I did not try to use it. > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? A quick reading. > - Are you knowledgeable about the problem domain? Reasonably so, but no expert. -- Daniel Wesslén

2 1

[Regex] Avoid exceptions when using invalid regular expressions
by Anne Martens 04 Apr '06

04 Apr '06

Hi, I'm trying to use boost-regex in my project that doesn't support exceptions. Thus, when constructing a regular expression with boost::regex expression(expr); and passig an invalid regular expression, my program crashes. What can I do to make sure my regular expression is valid before passing it to exception-throwing methods like that one? I already found an older answer that seems to apply to my problem (http://lists.boost.org/Archives/boost/2002/11/39161.php) it is suggested to use the member function set_expression. But how do I do that? I only get a lot of compiler errors. I have the regular expression as a std::string, so I'd like to write something like //string expr holds the regular expression boost::regex expression(); int result = expression.set_expression(expr); //check whether result is 0 -> ok. Thanks in advance for your help! Best regards, Anne Martens

5 5

[asio] Invalidated iterator bug in hash_map
by Felipe Magno de Almeida 04 Apr '06

04 Apr '06

Hi, the file hash_map.hpp has a bug, caught by STLPort checked-STL. The clear member-function is: // Remove all entries from the map. void clear() { // Initialise all buckets to empty. for (size_t i = 0; i < num_buckets; ++i) buckets_[i].first = buckets_[i].last = values_.end(); // Clear the values. values_.clear(); } But the clear member function of values_invalidates all iterators. So, the values recorded in the buckets are all invalidated. Which is caught in a later call to insert. I've swapped the clear call above the for and everything is fine here. best regards, -- Felipe Magno de Almeida

2 2

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