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

[algorithm/string] Patch for BCB2006
by Nicola Musatti 08 Apr '06

08 Apr '06

Hallo, the enclosed patch brings support for the latest Borland compiler to the same level as bcc 5.6.4 . I tested it against bcc 5.8.2, bcc 5.6.4, VC++ 8.0 and g++ 3.4.2 . Cheers, Nicola Musatti ******Index: compare.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/algorithm/string/compare.hpp,v retrieving revision 1.6 diff -d -u -r1.6 compare.hpp --- compare.hpp 6 Mar 2006 18:05:10 -0000 1.6 +++ compare.hpp 8 Apr 2006 07:41:10 -0000 @@ -67,7 +67,7 @@ #if defined(__BORLANDC__) && (__BORLANDC__ >= 0x560) && (__BORLANDC__ <= 0x564) && !defined(_USE_OLD_RW_STL) return std::toupper(Arg1)==std::toupper(Arg2); #else - return std::toupper(Arg1,m_Loc)==std::toupper(Arg2,m_Loc); + return std::toupper<T1>(Arg1,m_Loc)==std::toupper<T2>(Arg2,m_Loc); #endif } @@ -120,7 +120,7 @@ #if defined(__BORLANDC__) && (__BORLANDC__ >= 0x560) && (__BORLANDC__ <= 0x564) && !defined(_USE_OLD_RW_STL) return std::toupper(Arg1)<std::toupper(Arg2); #else - return std::toupper(Arg1,m_Loc)<std::toupper(Arg2,m_Loc); + return std::toupper<T1>(Arg1,m_Loc)<std::toupper<T2>(Arg2,m_Loc); #endif } @@ -173,7 +173,7 @@ #if defined(__BORLANDC__) && (__BORLANDC__ >= 0x560) && (__BORLANDC__ <= 0x564) && !defined(_USE_OLD_RW_STL) return std::toupper(Arg1)<=std::toupper(Arg2); #else - return std::toupper(Arg1,m_Loc)<=std::toupper(Arg2,m_Loc); + return std::toupper<T1>(Arg1,m_Loc)<=std::toupper<T2>(Arg2,m_Loc); #endif } Index: detail/case_conv.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/algorithm/string/detail/case_conv.hpp,v retrieving revision 1.2 diff -d -u -r1.2 case_conv.hpp --- detail/case_conv.hpp 11 May 2005 09:17:14 -0000 1.2 +++ detail/case_conv.hpp 8 Apr 2006 07:35:10 -0000 @@ -33,7 +33,7 @@ #if defined(__BORLANDC__) && (__BORLANDC__ >= 0x560) && (__BORLANDC__ <= 0x564) && !defined(_USE_OLD_RW_STL) return std::tolower( Ch); #else - return std::tolower( Ch, m_Loc ); + return std::tolower<CharT>( Ch, m_Loc ); #endif } private: @@ -53,7 +53,7 @@ #if defined(__BORLANDC__) && (__BORLANDC__ >= 0x560) && (__BORLANDC__ <= 0x564) && !defined(_USE_OLD_RW_STL) return std::toupper( Ch); #else - return std::toupper( Ch, m_Loc ); + return std::toupper<CharT>( Ch, m_Loc ); #endif } private: Index: detail/classification.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/algorithm/string/detail/classification.hpp,v retrieving revision 1.7 diff -d -u -r1.7 classification.hpp --- detail/classification.hpp 11 May 2005 09:17:14 -0000 1.7 +++ detail/classification.hpp 7 Apr 2006 07:45:49 -0000 @@ -46,7 +46,7 @@ return std::use_facet< std::ctype<CharT> >(m_Locale).is( m_Type, Ch ); } - #if defined(__BORLANDC__) && (__BORLANDC__ >= 0x560) && (__BORLANDC__ <= 0x564) && !defined(_USE_OLD_RW_STL) + #if defined(__BORLANDC__) && (__BORLANDC__ >= 0x560) && (__BORLANDC__ <= 0x582) && !defined(_USE_OLD_RW_STL) template<> bool operator()( char const Ch ) const {

1 0

Re: [boost] Sealed C++ class (why this inheritance is virtual)
by Martin Bonner 07 Apr '06

07 Apr '06

----Original Message---- From: Vladislav Lazarenko > I know that virtual inheritance may cause problems in > generally, but I see no possible problems with this code. You mean apart from a standard conforming compiler being required to reject the code? -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

1 0

Sealed C++ class.
by Vladislav Lazarenko 07 Apr '06

07 Apr '06

Dear Boost community, I thank you for such wonderful library, I can not even imagine my life without Boost. Great work, team! I propose to add the small but sometimes very useful class (like boost::noncopyable) I developed it in hope it will be useful and included into the best C++ framework in the world. Note that I have tested this class only with: 1) Microsoft Visual C++ .NET 55537-640-4008961-18142 2) Microsoft Visual C++ .NET 69462-112-0617214-18401 But I think it won't be a problem to compile with gcc and so one. And, surely, sorry if there is already such class in the Boost, I did not found. If it is, please give me the link, I will take a look. Please review and let me know what you think by replying to this message. Thank you very much in advance. // // Copyright (c) 2006 Vladislav Lazarenko <snail(a)b2bits.com> // // Distributed under the Boost Software License, Version 1.0. (See // accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) // #ifndef BOOST_SEALED_HPP #define BOOST_SEALED_HPP // MS compatible compilers support #pragma once. #if defined(_MSC_VER) && (_MSC_VER >= 1020) # pragma once #endif namespace boost { // protection from unintended ADL namespace sealed_ { template <typename T1, typename T2> class sealed_impl { friend typename T1; friend typename T2; private: sealed_impl() {} ~sealed_impl() {} }; } /*! The sealed classes is used to prevent derivation from a class. An error occurs if a sealed class is specified as the base class of another class. A sealed class cannot also be an abstract class. */ template <typename T> class sealed : virtual private sealed_::sealed_impl<sealed, T> { public: //! Constructor. sealed() {} //! Destructor. ~sealed() {} }; // Usage example: /* class UniquePerson : public boost::sealed<UniquePerson> { public: UniquePerson() {} ~UniquePerson() {} }; */ } #endif

4 5

bug: cyclic header dependencies in type_traits
by Scott McPeak 06 Apr '06

06 Apr '06

In Boost 1.33.1, the following headers are involved in an #inclusion cycle: boost/type_traits/is_scalar.hpp boost/type_traits/is_enum.hpp boost/type_traits/is_convertible.hpp boost/type_traits/is_abstract.hpp boost/type_traits/is_class.hpp This causes a problem for standards-compliant compilers because, depending on where you enter the cycle, some template's declaration will not be seen before it is used. For example, entering at is_scalar.hpp (which happens when you include optional.hpp) causes the definition of is_class<> to be seen before the declaration of is_scalar<>, but the former uses the later. The problem was introduced in the change from 1.32 to 1.33, when is_abstract.hpp started being #included by is_convertible.hpp. For reasons I still don't fully understand, this doesn't always actually cause a problem. I think it has to do with the mysterious BOOST_NO_IS_ABSTRACT macro; my understanding of the intricacies of Boost configuration is very limited. The place I ran into this was using an EDG-based front end to parse the preprocessed output of Sun CC 5.7 on solaris-sparc; input is "#include <boost/optional.hpp>"; using Boost 1.33.0 or 1.33.1. I can't repro on linux or with gcc, nor with the latest CVS version of Boost. But regardless, the cycle is still present in the latest CVS, and cyclic header dependencies are usually a bug. -Scott

3 2

Ann: Statistics/Special Functions/Numeric Methods Toolkit
by John Maddock 06 Apr '06

06 Apr '06

Gentlemen, This is to announce a new library added to the file vault, it is a work in progress and is intended to fulfil two needs: 1) To provide a small number of high quality special functions, initially these will be concentrated on functions used in statistical applications (with a strong nod towards Paul Bristow's existing work in this area). The functions currently implemented are the gamma/beta/erf functions along with the incomplete gamma and beta functions (four variants of each). All the implementations are fully generic and support the use of arbitrary "real-number" types, although they are optimised for use with types with known-about mantissa sizes: typically float, double or long double. Use of these functions with interval arithmetic (Boost.Interval) isn't quite supported yet, but it's something I want to investigate soon. 2) To provide at least some of the tools required to implement mathematical special functions, hopefully the presence of these will encourage other authors to contribute more special function implementations in the future. Currently implemented are helpers for the evaluation of infinite series, continued fractions and rational approximations. There are also classes for the manipulation of polynomials, for testing a special function against tabulated test data, and for the rapid generation of test data and/or data for output to an external graphing application. I've been keeping deliberately quiet about this for a while (with apologies to Paul Bristow), as I wanted to be certain that these special function implementations would offer something over and above what is available elsewhere. I still have some way to go here: erf and lgamma in particular still need work, but the incomplete gamma and beta functions already typically have 10 times lower error bounds than Cephes and GSL, and in one spectacular case 10^11 times more accurate (which is to say there is a domain of the incomplete gamma where Cephes and GSL have hardly any significant digits correct). Preliminary documentation is available here: http://www.johnmaddock.co.uk/toolkit and includes quite a lot of information already, including descriptions of implementation methodologies etc. There's also a roadmap of future work, open issues, and what needs to be done before a final release etc: http://www.johnmaddock.co.uk/toolkit/libs/math/doc/html/math_toolkit/status… The actual source code, is available for download in the vault: http://boost-consulting.com/vault/index.php?action=downloadfile&filename=ma… Regards, John Maddock.

6 12

[Bug] Interaction between date_time and filesystem libraries
by Joe Gottman 06 Apr '06

06 Apr '06

When I try to the following code under VC6.0: #include <boost/date_time/gregorian/greg_date.hpp> #include <boost/filesystem/convenience.hpp> I get the following error: error C2955: 'equivalent' : use of class template requires template argument list : see declaration of 'equivalent' If I reverse the order of inclusion there is no error. Joe Gottman

1 0

[tuples] const_tie
by Yuval Ronen 05 Apr '06

05 Apr '06

Hi. In the tuples library there is a function that creates a tuple with auto deduction of types - make_tuple(), and there's also a function that creates a tuple with reference of auto deduction of types - tie(), but there's no function that does the same with const reference. I found that such a function is useful when I have a simple struct with simple members, and I want comparision operators to it. Instead of writing these operators myself, I'd like to use tuples' code that does it. To ease this task (IOW, to save me specifying the tuple type explicitly) a const_tie would be most useful. my code would then look like: #define MY_STRUCT_AS_TUPLE(obj) const_tie(obj.x, obj.y, obj.z) bool operator<(const MyStruct &lhs, const MyStruct &rhs) { return MY_STRUCT_AS_TUPLE(lhs) < MY_STRUCT_AS_TUPLE(rhs); } which is the best I can think of (with typeof I could also turn the macro to a template function). I know I can accomplish the same with make_tuple() and cref(), but this way I can avoid the repetitive cref() calls. Can this be added? Thanks, Yuval

1 1

MSVC doesn't like some high-ASCII characters on non-US systems
by Foster Brereton 05 Apr '06

05 Apr '06

All, We are getting warnings when trying to compile Boost source files with MSVC 2003 and 2005 when there are high-ASCII characters in the sources. The reported problem only shows up when the computer's region is set to Japanese, but there could be other affected regions as well. A viable workaround is changing the setting for non-Unicode programs in the Control Panel/Regional and Language Options from Japanese to English (United States), but this is very inconvenient for members of our staff whose native region is Japanese. One (abridged) example of the warning we get from MSVC is: While compiling boost\type_traits\is_base_and_derived.hpp: warning C4819: The file contains a character that cannot be represented in the current code page (932). Save the file in Unicode format to prevent data loss. A caveat to this problem is that the warning shows up when there are high-ASCII characters in comments, so all copyright symbols and high-ASCII characters used in names have the potential to generate these compilation warnings for us. Another caveat to this problem is not all high-ASCII characters produce this problem. My guess is that some of the high-ASCII characters have a valid code page translation (e.g., the copyright symbol), and so the warning is not emitted. An implication of this would be that some characters will work for some OS regions and not for others, resulting in a varied set of errors based on the region one has chosen. The reason this is a problem is because our projects have warnings-as-errors turned on. We are not interested in disabling warnings-as-errors to mitigate the issue because of the far-reaching side effects of such a change. Has anyone else seen this problem? Are there other potential fixes other than removing all high-ASCII characters from the source files? Blessings, Foster -- Foster T. Brereton - Computer Scientist Software Technology Lab, Adobe Systems Incorporated fbrereto(a)adobe.com -- http://opensource.adobe.com

14 22

Attempting to build doc for sandbox project failure
by Edward Diener 05 Apr '06

05 Apr '06

I have setup BoostBook on my system following the instructions at Boost in the BoostBook documentation. I attempted to generate documentation for one of the sandbox projects, going to the dandbox project's libs/doc directory and executing bjam --v2 there. I received a message saying that "error: Did not find Jamfile or project-root.jam in any parent directory." But I can clearly see a Jamfile in the sandboxes root directory. Does anybod have any idea what has gone wrong ?

3 7

[Serialization] Segfaults on invalid input
by Michael Gebetsroither 05 Apr '06

05 Apr '06

Hi all, I've played a bit with boost::serialize and discoverd two problems (one segfault and one maybe related memeory exhaustion). Segfault: demo_xml from boost::serialize examples. I've changed the output format to text_archiv. If i increase the length of a string in the text_archiv by 2, it gives a segfault. All files could be found at: http://einsteinmg.dyndns.org/projects/boost_segf. - valgrind output (demo_xml.log) - gdb backtrace (demo_xml_gdb_backtrace) - normal input file (demo.txt) - input file which results in segfault (demoin.txt) I changed the length of the string "24th Street" from 11 to 13 same results for other strings. - demo_xml (compiled with -O2 -g3 for x86-32 gnu/linux, gcc 4.0.3-1) - the core file (core.gz) - and the sourcefiles demo_xml.{hpp,cpp} Memory exhaustion: Shows a similar problem, but with a very simple testobject (with just 2 std::string's). The output of this program should only 4 small lines but is 130MB (many printed \0). All files could be found at: http://einsteinmg.dyndns.org/projects/boost_memex - valgrind output (ser.log.gz, is 67MB unzipped) - program output with false input file (ser_false_output.gz, ~130MB unzipped) - normal output file (ser_out.txt) - evil input file (ser_in.txt) the length of the first string ("test1") is incremented by 2 - ser (compiled with -O2 -g3 for x86-32 gnu/linux, gcc 4.0.3-1) Boost version is 1.33.1. Hope that helps, solving this bug. Greetings, Michael Gebetsroither

1 0