- Boost - lists.boost.org

CVS update
by Victor A. Wagner Jr. 05 Apr '06

05 Apr '06

# Updating sources from CVS (2006-04-04T21:15:00Z)... # Executing CVS command "cvs -d:ssh:vawjr@cvs.sourceforge.net:/cvsroot/boost -z9 update -dPA -r RC_1_34_0" this actually connected and did the update (nothing interesting was retrieved) Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

Boost.Test: violation of min/max guidelines
by John Maddock 04 Apr '06

04 Apr '06

I've just been hit by Boost.Test not following the min/max coding guidelines, the patch is trivial: Index: boost/test/floating_point_comparison.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/test/floating_point_comparison.hpp,v retrieving revision 1.26 diff -r1.26 floating_point_comparison.hpp 66c66 < return std::numeric_limits<FPT>::max(); --- > return (std::numeric_limits<FPT>::max)(); Needs to be applied to the release branch as well now of course :-) Thanks, John.

8 12

[conversion] lexical_cast size optimization
by Alexander Nasonov 04 Apr '06

04 Apr '06

I noticed that instantiated lexical_cast functions are parameterized with array types. It's not optimal as array_to_pointer_decay is applied to argument type immediately and original type is not user anywhere else. My idea is to define inlined lexical_cast that just transforms the argument type and forward a call to detail::lexical_cast: template<typename Target, typename Source> inline Target lexical_cast(const Source &arg) { typedef typename detail::array_to_pointer_decay<Source>::type NewSource; return detail::lexical_cast<Target,NewSource>(arg); } The detail::lexical_cast is almost an original lexical_cast except that it doesn't transform the argument type. Additionally, call_traits<>::value_type can be applied to the argument type: namespace detail { template<typename Target, typename Source> Target lexical_cast( BOOST_DEDUCED_TYPENAME boost::call_traits<Source>::value_type arg) { detail::lexical_stream<Target, Source> interpreter; Target result; if(!(interpreter << arg && interpreter >> result)) throw_exception(bad_lexical_cast(typeid(Source), typeid(Target))); return result; } } I tested lexical_cast_test.cpp with gcc 3.4.4 [FreeBSD] 20050518. Code was generated with bjam --v2 release. Original size: 220316 Optimized: 201940 -17.95K ( 8.34% ) Optimized & call_traits: 197108 -22.66K ( 10.54% ) Additional transfomations can be applied. For example, enums can be promoted to integral types. I'm a bit unsure about this, though. This change could break enum types that have overloaded operator<<. What is expected behavior in this case? -- Alexander Nasonov

1 0

[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