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

[Boost-bugs] [ boost-Bugs-1464566 ] uniform_01 copies engine instead of using a reference
by SourceForge.net 05 Apr '06

05 Apr '06

Bugs item #1464566, was opened at 2006-04-04 19:31 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=1464566&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: random Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hubert Chan (uhoreg) Assigned to: Jens Maurer (jmaurer) Summary: uniform_01 copies engine instead of using a reference Initial Comment: In the uniform_01 class, the constructor takes a base_type (i.e. the random number generator) as its argument, and the _rng member is just a base_type. This results in uniform_01 copying the random number generator, along with its state. Thus if one creates several uniform_01 objects (e.g. one at the beginning of each of several functions), they will all return the same random numbers. The constructor should take a reference (i.e. base_type&) as its argument, and the _rng member should be a base_type&. (Indeed, the documentation at http://www.boost.org/libs/random/random-distributions.html#uniform_01 says that the constructor takes a base_type&.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1464566&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

2 1

[review] promotion traits - reminder
by Tobias Schwinger 05 Apr '06

05 Apr '06

Dear users & members of Boost, half of the scheduled review period is over and there were no reviews, so far. Therefore I want to welcome you, once again, to evaluate the proposed Boost software. The end of the review period is scheduled for April 6, so please try to post your review before then. Download URL ============ http://cpp-experiment.sourceforge.net/promote-20050917.tar.gz About the submission ==================== The Promotion Traits extend Boost.TypeTraits with templates that compute the type after promotion has been applied. Example: // given template<typename T> struct some_algorithm; template<> struct some_algorithm<int> { [...] }; // [...] more specializations // , [...] some_algorithm< typename integral_promotion<T>::type > [...] // makes some_algorithm work for any type T that promotes to an integer // (that is enums and smaller integral types) without the need for // additional specialization It's a small submission so you probably won't notice that you're working before you're done... Review questions ================ Please always explicitly state in your review, whether you think the library should be accepted into Boost. You might want to comment on the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards, Tobias (Review Manager)

3 2

[review] promotion traits
by Tobias Schwinger 05 Apr '06

05 Apr '06

The review of Alexander Nasonov's Promotion Traits start today. Since it's a small contribution it will be fast-track reviewed and the end of the review period is scheduled for April 6. Download URL ============ http://cpp-experiment.sourceforge.net/promote-20050917.tar.gz About the submission ==================== The Promotion Traits extend Boost.TypeTraits with templates that compute the type after promotion has been applied. Example: // given template<typename T> struct some_algorithm; template<> struct some_algorithm<int> { [...] }; // [...] more specializations // , [...] some_algorithm< typename integral_promotion<T>::type > [...] // makes some_algorithm work for any type T that promotes to an integer // (that is enums and smaller integral types) without the need for // additional specialization Review questions ================ Please always explicitly state in your review, whether you think the library should be accepted into Boost. You might want to comment on the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards, Tobias (Review Manager)

6 13

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