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

Re: [boost] boost::shared_ptr<>::compare_and_swap()--AmIinsaneforwanting this?
by Sohail Somani 14 Nov '06

14 Nov '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Talbot, George > > I also do not have a good answer to the post by Sohail Somani > about what > the compiler will do with this in the future. Actually I think Visual C++ 7.1+ might already do it.

3 3

Re: [boost] [system] Was: Re: [asio] Breaking changes committed tocvs HEAD
by Christopher Kohlhoff 14 Nov '06

14 Nov '06

Hi Johan, Johan Nilsson <r.johan.nilsson(a)gmail.com> wrote: > Boost.Asio as such isn't platform-specific. Wouldn't you (as a > library implementor) prefer to do as much as possible in a > portable way? The interface isn't platform specific, but the implementation at the lowest level is very much so. And an error_code parameter is used in the functions at these lowest levels. [...] > I was looking for something like that, yes. Shouldn't that > part be included (but more exhaustively) in the Diagnostics > proposal? I don't think so, since the globals and requirements on use are specific to the asio proposal. However the text associated with the globals is intended to intend up in the same chapter as the Diagnostics proposal. > Also, I would personally prefer names that are less likely to > clash with others if the containing namespace is brought into > scope by using namespace <ns containing error codes>; > error_access_denied, error_address_family_not_supported etc. So don't do "using namespace <ns containing error codes>" :) I think it's mostly a matter of taste, and I happen to prefer error:: over error_. Using a namespace also has the advantages of letting you alias it (e.g. e:: instead of error::), and you can do a "using <error-name>" into another namespace, etc. Cheers, Chris

1 0

Ann: guid library
by Andy 14 Nov '06

14 Nov '06

I have uploaded a new version of the guid library to the boost vault (guid_v4.zip). (I seem to be unable to change the file description for guid_v3.zip to not say the last version.) Changes: I have written documentation. The create function now just creates a random number based guid instead of pretending to create a time-based one. It uses Boost Build System V2 I plan to add serialization and name-based creation in the near future. I welcome any (and hope to receive many) comments and criticisms. Andy Tompkins

4 6

sha-1
by Andy 14 Nov '06

14 Nov '06

Hi, I am looking for an implementation of the sha-1 algorithm that I can use for the guid library that I am writing. Since I hope to submit this to boost, I need the sha-1 code to conform to the boost license requirements. I have found http://www.packetizer.com/security/sha1/. Here are the contents of the license.txt file: Copyright (C) 1998 Paul E. Jones <paulej(a)arid.us> All Rights Reserved. This software is licensed as "freeware." Permission to distribute this software in source and binary forms is hereby granted without a fee. THIS SOFTWARE IS PROVIDED 'AS IS' AND WITHOUT ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE AUTHOR SHALL NOT BE HELD LIABLE FOR ANY DAMAGES RESULTING FROM THE USE OF THIS SOFTWARE, EITHER DIRECTLY OR INDIRECTLY, INCLUDING, BUT NOT LIMITED TO, LOSS OF DATA OR DATA BEING RENDERED INACCURATE. Would this license prevent the guid library from being accepted as a boost library? If so, does anyone know of code for the sha-1 algorithm that would not prevent the guid library from being accepted as a boost library? Thanks in advance, Andy Tompkins

4 3

[system] Was: Re: [asio] Breaking changes committed to cvs HEAD
by Johan Nilsson 14 Nov '06

14 Nov '06

Beman Dawes wrote: > On 11/8/06, Johan Nilsson <r.johan.nilsson(a)gmail.com> wrote: >> [snip] >> I'm trying to find the documentation for the Boost.System stuff - any >> pointers? >> > > In the CVS Head, see libs/system/doc/error_code.html, and > libs/system/doc/system_error.html > > Also see > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2066.html Ok, so I've made a quick pass though the docs. A few questions and comments: 1) Are there any guarantees for the lifetime of the decoder references as returned by error_code::get_decoders? Could I hold on to them "forever", once retrieved? 2) I've implemented similar code previously, but only designed for portability with linux and Win32. What I very often use, is something corresponding to retrieving errno or calling GetLastError (on Win32). With the current design, it is harder to implement library code throwing system_errors (retrieving error codes) as you'll need to get the corresponding error code in a platform-specific way. Or did I miss something? I'd like something like this in the error_code interface: class error_code { ... static error_code last_error_code(error_category const& ecat); static void last_error_code(error_category const& ecat, error_code::value_type new_error_code); ... }; Which would enable: throw system_error(error_code::last_error_code(native_ecat), "Failed!"); of perhaps even: throw last_system_error("Failed!"); I know it's not 100% natively portable, as e.g. OpenVMS does not have an equivalent of Set/GetLastError - but at least using errno_ecat should be universal, and using native_ecat could be implementation defined (or simply use errno internally when nothing else is available). 3) Don't the static methods new_category and get_decoders belong to the error_category interface, rather than error_code? 4) I'm wondering about best practices for how to use the error_code class portably while maintaining as much of the (native) information as possible. Ideally, it should be possible to check for specific error codes portably, while having the native descriptions(messages) available for as much details as possible. Using native_ecat and compare using to_errno? 5) Ideally, I think having error_code as an additional part of std::runtime_error instead of having the separate system_error class would make sense. A error_code feels more like a property of a runtime_error that might or might not be set. Might not be practical though. 6) A "std::string error_category::description() const" method feels like a good idea to add. Don't ask me for any specific reasons just yet. 7) The error_category management seems very simplistic, just a static new_category(...) method. Did you think anything more about the management? It is not very unlikely that independent components will need to use (and therefore also add) the "same" category (e.g. winsock_category, nt_native_category, getaddrinfo_category, ...). Would it be possible somehow to access information on available error_categories to be able to avoid insertion of new error_categories with equal properties? Just thinking out loud here ... 8) An enumeration (or class with static constants) containing the available standard posix error codes (as referenced in the docs) would be nice, e.g. posix_error::xxx_errno, posix_error::yyy_errno, ... 9) I assume the category management is thread-safe. I saw nothing explicit about that in the docs. 10) I'd also like an explicit guarantee that the implementations of error_category/system_error/error_code should be error neutral - i.e., that they don't affect the current values of e.g errno and GetLastError. 11) With reference to 10 above - a useful addition to the library would be an "error_code_preserver" class, a RAII class that picks up the current error code when created, and restores it on destruction. Very useful when you want to implement your own error-neutral functionality (such as in e.g. a logging framework). Perhaps nothing for the standard, but why not for Boost.System? BTW, if you have implemented error_code::to_errno for native_ecat on Win32, consider me suitably impressed. Overall, this is for a very much awaited addition to Boost (and even more so to the C++ standard, eventually). Looking forward to use it! Regards, Johan Nilsson

2 2

[mpl] MPL_ASSERT unused variable warning on GCC
by Eric Niebler 14 Nov '06

14 Nov '06

The recent change to mpl/assert.hpp on HEAD is causing an unused variable warning on gcc 3.4, 4.0 and 4.1. The megabytes of resulting compiler debug spew is making my xpressive regression tests almost unrunnable. Aleksey? Eg.: ../../../boost/xpressive/detail/static/static.hpp:124: warning: unused variable 'mpl_assertion_in_line_124' -- Eric Niebler Boost Consulting www.boost-consulting.com

3 3

[test] dynamic linking tests 2
by Vladimir Prus 14 Nov '06

14 Nov '06

Looking at: http://tinyurl.com/yfuxmc I see some unresolved symbols, for example to: public: void __thiscall boost::test_tools::tt_detail::print_log_value< char const *>::operator() Looking at the code, the header test_tools.hpp says: template<> struct print_log_value<char const*> { void operator()( std::ostream& ostr, char const* t ); }; there's no BOOST_TEST_DECL. Likewise, test_tools.ipp does not use BOOST_TEST_DECL. So, it looks like this link error is genuine problem with the library. Gennadiy, can you take a look? Thanks, Volodya

3 4

Boost.test thread safety
by Martin Slater 14 Nov '06

14 Nov '06

Hi, After using Boost.Test in a multi threaded scenario and experiencing crashes I checked the latest docs and thread safety is listed as a todo in the open issue section. In general the library has been working well for me but this is limiting where I can use it, is it likely to be resolved soon? thanks Martin

2 2

bug in spirit numerics parsing
by Steve Nutt 13 Nov '06

13 Nov '06

I've encountered a bug in the spirit library's numeric parsing. Deep in boost::spirit::impl is a template extract_int_base which uses the two templates positive_accumulate and negative_accumulate. When a new digit is parsed, it is accumulated to the current value by multiplying the current value by the radix and adding the new digit. Overflow is detected at each stage by comparing the new and old values. The overflow logic is flawed. It assumes that when the number overflows it becomes a smaller number, which is only true if the radix is a power of 2. It also requires that the arithmetic operation does over/underflow. My proposed fix detects overflow before it happens, fixing the parsing of large base 10 numbers, and allowing for non overflowing numeric types. The changes are only to the three classes mentioned. Steve Nutt Changed file: include/spirit/core/primitives/impl/numerics.ipp template <int Radix> struct positive_accumulate { // Use this accumulator if number is positive template <typename T, typename CharT> static bool add(T& n, CharT ch) { // Ensure n *= Radix will not overflow static const T val = std::numeric_limits<T>::max() / Radix; if (n > val) return false; n *= Radix; // Ensure n += digit will not overflow const int digit = radix_traits<Radix>::digit(ch); if (n > std::numeric_limits<T>::max() - digit) return false; n += digit; return true; } }; template <int Radix> struct negative_accumulate { // Use this accumulator if number is negative template <typename T> static T min() { if (std::numeric_limits<T>::is_integer) return std::numeric_limits<T>::min(); return -std::numeric_limits<T>::max(); } template <typename T, typename CharT> static bool add(T& n, CharT ch) { // Ensure n *= Radix will not underflow static const T val = min<T>() / Radix; if (n < val) return false; n *= Radix; // Ensure n -= digit will not underflow const int digit = radix_traits<Radix>::digit(ch); if (n < min<T>() + digit) return false; n -= digit; return true; } }; template <int Radix, typename Accumulate> struct extract_int_base { // Common code for extract_int specializations template <typename ScannerT, typename T> static bool f(ScannerT& scan, T& n) { return Accumulate::add(n, *scan); } };

2 1

Problem with detail/identifier.hpp
by Matthias Troyer 13 Nov '06

13 Nov '06

Hi Beman, hi all Due to recent changes to the filesystem library now, the header detail/identifier.hpp is now included in my projects and contains the dangerous code segment: template <class Ostream, class Id> typename enable_if< is_base_of< identifier< typename Id::value_type, Id >, Id >, Ostream & >::type operator<<( Ostream & os, const Id & id ) { return os << id.value(); } which breaks all of my codes, since I have a type Id, that has a type member Id::value_type which is an abstract base class. My compiler (Apple gcc-4.0) now tries to instantiate identifier< typename Id::value_type, Id >, which fails because Id::value_type is abstract, and the compiler aborts with an error message. This causes all of our codes to fail to compile with the current CVS head Matthias

3 6