- Boost - lists.boost.org

[test] [gcc-4.3.2] check_is_close and check_is_small issues
by Dean Michael Berris 22 Feb '09

22 Feb '09

Hi Guys, I have recently upgraded to Boost 1.38 from Boost 1.35 and suddenly I get the following warnings from GCC 4.3.2: ../boost_1_38_0/boost/test/floating_point_comparison.hpp:224: error: 'boost::test_tools::<unnamed>::check_is_close' defined but not used ../boost_1_38_0/boost/test/floating_point_comparison.hpp:246: error: 'boost::test_tools::<unnamed>::check_is_small' defined but not used I have warnings treated as errors in my build and I haven't encountered this issue before. Can this be considered a regression and if yes what can I do to work around it? -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com

4 6

[range-ex] generators
by Neal Becker 22 Feb '09

22 Feb '09

I have a question of generate. I believe one usually wants generators to have state. Yet, generator is passed by value. This is awkward, the workaround is to manually specify generate<ForwardRange, Generator&>( rng, gen ); Since Generator is the 2nd template parameter we must specify ForwardRange, which might be complicated. I wonder if we should have: template<class ForwardRange, class Generator> ForwardRange& generate( ForwardRange& rng, Generator & gen );

3 3

[c++0x] OK to merge cpp0x branch config changes to trunk?
by Beman Dawes 22 Feb '09

22 Feb '09

See http://svn.boost.org/svn/boost/branches/cpp0x This branch adds the following config macros: BOOST_NO_CHAR16_T BOOST_NO_CHAR32_T BOOST_NO_CONSTEXPR BOOST_NO_DECLTYPE BOOST_NO_DEFAULTED_FUNCTIONS BOOST_NO_DELETED_FUNCTIONS BOOST_NO_EXPLICIT_CONVERSION_OPERATORS BOOST_NO_EXTERN_TEMPLATE BOOST_NO_RAW_LITERALS BOOST_NO_RVALUE_REFERENCES BOOST_NO_SCOPED_ENUMS BOOST_NO_STATIC_ASSERT BOOST_NO_UNICODE_LITERALS BOOST_NO_VARIADIC_TEMPLATES The particular names were discussed in several threads nearly a year ago. The set of C++0x features detected only covers those available in at least one shipping compiler. Although I've tested locally, I'd appreciate it if someone familiar with Boost.Config could take a look at the branch before the config directories get merged into trunk. --Beman

3 3

[filesystem] security questions
by Sergei Politov 21 Feb '09

21 Feb '09

Hi, In *nix systems it is recommended practice to operate with file descriptors rather than file names. The sample commands sequence is: 1) open file 2) check file status (check symlink for instance) 3) process write operation Unfortunately I cannot find a way to do the same using boost::filesystem API. Is it planned to support such style? Best Regads, Sergei

5 5

[threadpool] new v18
by k-oli＠gmx.de 21 Feb '09

21 Feb '09

Hello, I've uploaded a new version to boost-vault. The new library contains the future library from Anthony Williams (because it seams we don't get boost.future in the next time). regards, Oliver

1 0

Formal Review Request: Boost.String.Convert
by Vladimir.Batov＠wrsa.com.au 21 Feb '09

21 Feb '09

Well, the fishing trip did not work out. :-\ Therefore, I would like to request a formal review for the Boost.String.Convert functionality. I've uploaded the file called boost-string-convert.zip to the Vault (http://www.boostpro.com/vault/index.php) It has the conversion-related header, the test/usage executable and the documentation (MS Word, HTML). Compiled on Linux and Visual Studio 2008. At the bottom is the "motivation" introductory section from the docs. There is very little of actually code, so you might just read it rather that suffering through my document mumble. Currently-known issues. 1) The attention was given to the behavior (to provide simple/advanced conversion-failure check, throw/no-throw behavior, locale, formatting) and not to the efficiency. I am sure people will come up with ways to run this damn thing much faster. I am very much looking forward to your contributions as I do not really feel I am any good at it. 2) I've implemented the recently suggested boost::stirng::convert() interface but that might need some additional work to handle corner cases correctly. I promise to look into it in due course. I would like to thank everyone participated in the lexica_cast and boost::string::convert-related discussions and expressing their views and opinions and coming up with suggestions. All of them were heard, considered and much and truly appreciated. I apologize if in the end it does not look out as you might like to see it. I swear, your contributions were not in vain. Thanks, Vladimir. Motivation I had a need for a convenient and uniform facility to convert values to and from a literal textual form. Such a need is common when converting between internal (to a program) data types and their external representations. Typical applications would be reading of configuration files, packing and unpacking internal data to and from, say, XML, etc. The boost::lexical_cast looked very promising and was the preferred solution compared to others (such as C functions, std::stringstream, etc., see the lexical_cast documentation for more discussion about alternatives). Unfortunately, I needed functionality beyond what lexical_cast was providing (configurable throw/no-throw behavior, formatting support, locale support, etc.). After discussions on the Boost developers list and with the lexical_cast author (Kevlin Henney) and the maintainer (Alexander Nasonov) it was collectively decided that the required functionality extensions were not compatible with the idea of what lexical_cast embodied and a more dedicated family of conversion functions with richer interfaces was needed. That decision resulted in the development of the following header-only string-conversion library described in this document: boost::string::convert() The interface is explicit about its purpose ? string-related -- string-to-type and type-to-string -- conversions. It builds on the lexical_cast past experience, offers the already familiar conversion functionality and more: · throw and no-throw conversion-failure handling behavior; · support for the default value to be returned when conversion fails; · formatting support based on the standard (or user-defined) manipulators (like std::hex, std::scientific, etc.); · locale support; · support for various (boost::range-compliant) char and wchar_t-based containers (std::string, std::wstring, char const*, wchar_t const*, char array[], std::vector<char>, etc.); · no DefaultConstructibility requirement for the Target type; · room to grow.

12 73

GMANE gateway to the Boost Users mailing list seems dead
by Vladimir Batov 21 Feb '09

21 Feb '09

... as its overall traffic

2 1

Re: [boost] Formal Review Request: Boost.Convert
by Andrzej Krzemienski 21 Feb '09

21 Feb '09

Hi, I would like to propose removing the default value for the second argument of convert. I believe it may be insecure. Let me explain it by exemple. What did I mean when I wrote the following code: string str = readInput(); int men = convert_to<string, int>(str); 1. I meant: "if conversion is impossible, return 0", because I read the documentation thoroughly. 2. I am a novice and didn't really think about the situation where someone types a non-int string. In case of the first option it is all fine, but if the latter is the case, it may have been better to throw an exception to the user. I would propose, rather than having a default "fallback" value to provide two overloads for convert: one with two parameters where you can provide the fallback value, and the other, one-parameter, that would indicate that you want to throw an exception on failure. Yo do not loose much of your original interface, because you can write more explicitly: int men = convert_to<string, int>(str, 0); I find it better because: 1. It forces the writer to type more clearly his intentions. (Or explicitly confirm that he is aware that the string may not be convertible to int.) 2. Releaves you from providing the throw_t argument altogether. This in turn removes the possibility of writing: convert<string, int>(str, -1) >> throw_t(); // What does -1 mean here? Regards, &rzej

2 2

[utility] A fix for the const issue of value_initialized
by Niels Dekker - mail address until 2010-10-10 20 Feb '09

20 Feb '09

The boost::value_initialized<T> utility has a major issue regarding const-correctness: It has a const-qualified conversion operator, returning a non-const reference to the T object it owns. I have already created a ticket, <https://svn.boost.org/trac/boost/ticket/2548>, and mailed Fernando Cacciola (the author of value_initialized) on this issue. He agrees that it should be fixed, and he allows me to do so. The patch I've attached to the ticked replaces the current conversion operator by two of them, overloaded for const and non-const access: operator T const &() const { return this->data(); } operator T&() { return this->data(); } The patch also fixes value_initialized::data() in a similar way. Please let me know if you have any problem with the patch. Otherwise I'd like to apply it to the trunk by the end of the week: https://svn.boost.org/trac/boost/attachment/ticket/2548/value_initialized_c… Note that the issue has been discussed here already five years ago: http://lists.boost.org/Archives/boost/2004/01/59987.php At that time, some non-conforming compilers couldn't deal with conversion operators overloaded for const and non-const access. But now I've tested the value_initialized patch on a few compilers (MSVC 2003, MSVC 2008, CodeGear), and they all succeeded. After the commit, I'll keep a close look at the regression page, of course. Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

1 1

[ignore this] Hello?
by Andrey Semashev 20 Feb '09

20 Feb '09

test

1 0