- Boost - lists.boost.org

[gil][ublas] Point2DConcept and ublas vector concept
by Christoph Heindl 23 Feb '09

23 Feb '09

Hi, I'd like to use my boost::ublas::bounded_vector types interchangeable with boost::gil::point2 which from my point of view makes totally sense: A convex hull algorithm for 2D would only need to be implemented once (for world coordinates and pixel coordinates) for example. This, however, seems impossible right now because of the differences in their concepts. Is it possible to somehow make a bridge between them (without copying structures)? Any plans to unify those concepts and reuse ublas types? Best regards, Christoph

1 0

Trac tickets: fixed in trunk vs. fixed in release
by Steve M. Robbins 22 Feb '09

22 Feb '09

Hi, For each bug, there are really two levels of "fixed": roughly speaking, the developer considers the issue fixed when it is committed to trunk, while the user considers the issue fixed when it is commited to the release branch. At present, the trac ticket is closed at the first gate. Unfortunately, sometimes the second gate gets forgotten. Could another state be added to the ticket lifecycle to track when it gets merged to release? My aim is to be able to identified "fixed" tickets that are not actually released and, hopefully, to decrease them in number. Maybe there are other ways to achieve this? Regards, -Steve

5 10

[Iterator] Two sets of docs?
by John Maddock 22 Feb '09

22 Feb '09

The iterator library seems to have two sets of docs: one in quickbook format and one in restructured text. Which is the correct up-to-date version, and can we get rid of the other to avoid confusion? Thanks, John.

2 2

[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