July 2012 - Boost - lists.preview.boost.org

[trunk] bootstrap failure
by Tim Blechmann 08 Jul '12

08 Jul '12

hi, just moved my boost source tree from one hd to another. trying to bootstrap leads to: Building Boost.Build engine with toolset gcc... Failed to build Boost.Build build engine Consult 'bootstrap.log' for more details the bootstrap.log contains: rm -rf bootstrap mkdir bootstrap gcc -o bootstrap/jam0 command.c compile.c constants.c debug.c execcmd.c frames.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c option.c output.c parse.c pathunix.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c md5.c w32_getreg.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c execunix.c fileunix.c function.c: In function ‘argument_list_print’: function.c:3126:17: warning: format ‘%s’ expects argument of type ‘char *’, but argument 2 has type ‘struct OBJECT *’ [-Wformat] ./bootstrap/jam0 -f build.jam --toolset=gcc --toolset-root= clean Segmentation fault (core dumped) any idea? tim

2 2

[lockfree/win32] looking for help
by Tim Blechmann 08 Jul '12

08 Jul '12

hi all, i've been trying to sort out some compile problems of boost.lockfree, but now i find myself in a position that for some reasons, the tests on on the windows platform fail ... not only with msvc, but also with gcc/mingw. the main problem that i have is that two test cases compile, but fail at runtime ... unfortunately the error messages are not necessarily expressive: mingw: -- Run [2012-07-04 16:08:25 UTC]: fail EXIT STATUS: -1073741819 -- msvc: -- Running 8 test cases... unknown location(0): fatal error in "spsc_queue_test_buffering": stack overflow ..\libs\lockfree\test\spsc_queue_test.cpp(435): last checkpoint: "spsc_queue_test_buffering" entry. *** 1 failure detected in test suite "Master Test Suite" EXIT STATUS: 201 -- i am pretty clueless, what is happening there ... would it be possible that someone who has a win32 machine can send me a backtrace of this crash? thanks, tim

2 3

[Lockfree] examples with clang
by Rich E 08 Jul '12

08 Jul '12

Hi all, I've been attempting to test Lockfree (while at the same time learning to work with boost from trunk, so bare with me I'm a bit new) using Clang 4.0, the version that will ship with Xcode 4.5. It appears that the preprocessor check is only for gcc. If I change: #if __cplusplus < 201103L to #if __cplusplus < 201103L && ( defined( __clang__ ) && ! __has_include(<atomic>) ) and compile the examples with (from libs/lockfree/examples): ../../../bjam toolset=clang cxxflags="-std=c++0x -stdlib=libc++" linkflags="-stdlib=libc++" Then the examples work correctly (queue output: "produced 40000000 objects. consumed 40000000 objects."). I'm sure there is a more elegant way to check for libc++ existence when compiling with clang, possibly with boost/config.hpp? Also, I think a message in the dummy main would be nice to inform the user that lockfree won't work with their current setup / compile method. Cheers, Rich

2 1

[context] a couple of build fixes for Solaris (10)
by Luke Elliott 07 Jul '12

07 Jul '12

First is to get the definition of mprotect() that takes void * rather than char * by defining _XPG4_2, which causes a compilation failure with Solaris Studio 12.3. Second is a workaround for a bug in their csignal header which uses the same include guard that signal.h uses, which csignal includes (leaving SIGSTKSZ undefined). Attached if of any help. Regards Luke Elliott.

3 3

memory leak in fileiter.cpp
by GAURAV GUPTA 07 Jul '12

07 Jul '12

There is a possible memory leak in fileiter.cpp in Regex component. I have raised a ticket https://svn.boost.org/trac/boost/ticket/7084 along with the patch. Please verify and commit it. -- Regards, Gaurav

1 0

[gil::io_new] Help with gcc compiler
by Christian Henning 07 Jul '12

07 Jul '12

Hi there, I'm in the process of making my gil extension ready for inclusion. The code is now stable and I'm trying to get gcc/clang to work. Since I'm no expert with gcc I would like to ask for some help with various compiler errors. Could someone get the latest from here: http://gil-contributions.googlecode.com/svn/trunk/gil_2 and try to compile the following code: ------------------- #include <boost/gil/extension/io_new/bmp_all.hpp> using namespace std; using namespace boost::gil; int main() { { const char* bmp_filename = ""; const char* bmp_out = ""; rgb8_image_t img; read_image( bmp_filename, img, bmp_tag() ); write_view( bmp_out + "all_formats_test.bmp", view( img ), bmp_tag() ); } } ----------------- It should generate some errors which I don't quite understand. I have posted the errors here: http://pastebin.com/Wps3YH1N I'm using gcc 4.4.1 . The complete test suite compiles with Visual Studio 2010 without any warnings. Thanks a lot! Christian

5 10

noncopyable && C++11
by Ben Pope 06 Jul '12

06 Jul '12

Hi all, boost::noncopyable interferes with the implicit generation of move construction and move assignment, so I was wondering if anybody had any thoughts on something like this: class noncopyable { protected: noncopyable() = default; noncopyable(noncopyable&&) = default; noncopyable& operator=(noncopyable&&) = default; noncopyable(noncopyable const&) = delete; noncopyable& operator=(noncopyable const&) = delete; }; Which would replace the existing technique when C++11 support is on. I guess it could be argued that non copyable should imply non moveable. However, you won't hear me defending that position; plenty of thought went into move semantics with the defaults chosen to have sa[f|n]e behaviour. The derived class will still be subject to that criteria, I'm just trying to prevent noncopyable from artificially inhibiting move semantics. Would anybody want nonmovable? nonmoveable? Any thoughts / comments / omissions gratefully received. Ben

2 2

[iostreams] cin wrapper
by Daniel Larimer 06 Jul '12

06 Jul '12

I am attempting to 'wrap' std::cin such that all 'blocking' occurs in a dedicated 'cin' thread. This is required because in a cooperatively scheduled thread, no fiber can call cin and block. So I went about attempting a boost::iostreams::source: class cin_source : public boost::iostreams::source { streamsize read( char* s, streamsize n ) { if( n == 0 ) return n; auto r = std::cin.readsome(s,n); if( r <= 0 ) { // post read request to another thread. // cooperatively wait for it to finish... return n; } return r; } }; The problem I have is that this code causes read to be called with 'n == 0'; boost::iostreams::stream<cin_source> my_cin; char buf[100]; my_cin.read( buf, 100 ); It doesn't matter how I attempt to read from the stream, n always equals 0. What am I doing wrong? Dan

1 0

[format] Any interest in decoupling it from std::basic_string?
by news.gmane.org 06 Jul '12

06 Jul '12

I.e. such that alternative string implementations could be used (GCC's vstring, boost's...). I've attempted two methods, both pretty simple. First is to simply template basic_format on the string type and propagate that change throughout the library (including similar for the altstream/stringbuf classes). Second was to add a template template parameter for the string, e.g.: template <class Ch, class Tr, class Alloc, template <typename, typename, typename> class StringT = std::basic_string> class basic_format; and propagate that. I would assume the first method is definitely out due to breaking the interface (especially the altstream classes which I would guess are supposed to look like the std ones). I've not looked at whether something such as templatizing the str() method on the string implementation is possible, as either of the above is sufficient for my own purposes and trivial which I suspect a templatized str() wouldn't be... Anyway, if there's any interest I can post a patch for either or both and if not continue using the first method (simpler diff from the original)! Best regards Luke Elliott.

5 11

[Range] Range adaptor approach for temporary range lifetime issue
by Michel Morin 06 Jul '12

06 Jul '12

When an rvalue range is adapted in range-based for loop, the lifetime of the rvalue range ends before the loop body begins. For example, the following code produces dangling references. for (auto x : std::string("Hello world!") | reversed) { /*...*/ } This is the temporary range lifetime issue. When I proposed BOOST_FOREACH extension for this issue, ( http://lists.boost.org/Archives/boost/2011/04/180591.php ) a solution with "moving an rvalue range into range adaptors" was suggested in the thread. I implemented this approach as a range adaptor (with the aid of rvalue references and decltype C++11 features): for (auto x : std::string("Hello world!") | moved | reversed) { /*...*/ } When an rvalue range is piped to `moved` adaptor, it returns `moved_range`. `moved_range` stores the following data: * Moved rvalue range: The rvalue range is moved and stored in `moved_range`. * Applied adaptors: When range adaptors are applied to`moved_range`, they are not invoked immediately; they are stored in fusion vector. The stored adaptors are invoked when `begin` or `end` member functions of `moved_range` are called. (To prevent repeated applications of the stored range adaptors, begin and end iterators are cached when they are first computed.) For example, in `std::string("Hello world!") | moved | reversed`, 1. By applying `moved` adaptor, `moved_range` is created. It stores `std::string` object moved from `std::string("Hello world!")`. It doesn't store any adaptors. 2. By applying `reversed` adaptor, another `moved_range` is created. It stores `std::string` object moved from the previous `moved_range`. It also stores `reversed` adaptor in fusion vector. Step 2 is repeated if more adaptors are applied. Then, in "for-init-statement" of range-based for loop, the stored adaptors are actually applied (and the result is cached). The free function version (`boost::adaptors::move`) supports `std::initializer_list`: for (auto x : move( {1, 2, 3, 4, 5} ) | reversed) { /*...*/ } Note that we cannot support it in the pipe syntax `{1, 2, 3, 4, 5} | moved` because the C++11 Standard does not allow to use list initializers in binary operators. Code attached. Comments? Regards, Michel

7 40

[exception] [type_traits] warning: unrecognized #pragma GCC system_header
by Krzysztof Czainski 06 Jul '12

06 Jul '12

Hello, Below is a list of files, that contain: #if defined(__GNUC__) #pragma GCC system_header #endif which causes a warning on my TI compiler. E:\boost\include\boost-1_50_0\boost\exception\all.hpp E:\boost\include\boost-1_50_0\boost\exception\current_exception_cast.hpp E:\boost\include\boost-1_50_0\boost\exception\detail\error_info_impl.hpp E:\boost\include\boost-1_50_0\boost\exception\detail\exception_ptr.hpp E:\boost\include\boost-1_50_0\boost\exception\detail\is_output_streamable.hpp E:\boost\include\boost-1_50_0\boost\exception\detail\object_hex_dump.hpp E:\boost\include\boost-1_50_0\boost\exception\detail\type_info.hpp E:\boost\include\boost-1_50_0\boost\exception\diagnostic_information.hpp E:\boost\include\boost-1_50_0\boost\exception\errinfo_errno.hpp E:\boost\include\boost-1_50_0\boost\exception\exception.hpp E:\boost\include\boost-1_50_0\boost\exception\get_error_info.hpp E:\boost\include\boost-1_50_0\boost\exception\info.hpp E:\boost\include\boost-1_50_0\boost\exception\info_tuple.hpp E:\boost\include\boost-1_50_0\boost\exception\to_string.hpp E:\boost\include\boost-1_50_0\boost\exception\to_string_stub.hpp E:\boost\include\boost-1_50_0\boost\throw_exception.hpp E:\boost\include\boost-1_50_0\boost\type_traits\is_virtual_base_of.hpp In other files, i.e. boost\integer.hpp, I've found this #pragma guarded against __GNUC__ >= 4: #if defined(__GNUC__) && (__GNUC__ >= 4) #pragma GCC system_header #endif which doesn't cause a warning on my compiler, because it defines __GNUC__ to 3. Could this be fixed in the files on the list above, or are there some __GNUC__ 3 compilers, that need this pragma to be enabled? Regards, Kris

3 5

[1.50.0] Release candidates available for testing
by Beman Dawes 05 Jul '12

05 Jul '12

Release candidate files for 1.50.0 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, --Beman --PS: I tested the 7z version, and it built without errors on Win7/VC++ Express 2010 sp1

8 16

Re: [boost] [cfe-dev] Using c++11 features in clang
by Marshall Clow 05 Jul '12

05 Jul '12

On Jul 5, 2012, at 12:41 PM, Joseph Galbraith wrote: > On 07/05/2012 12:29, Marshall Clow wrote: >> In response to a some questions on the boost-users list (and boost bug reports), I wrote up this: >> http://marshall.calepin.co/llvmclang-and-standard-libraries-on-mac-os-x.html >> >> I don't know if this should be a FAQ entry for Boost, or for clang. >> Suggestions/comments/edits welcome. > > Isn't one of both of -std=c++11 and -stdlib=libc++ an ABI change? > > If so, it should probably be noted that all code should be build with > the same settings for these flags. Yes. > In particular, I think that you can't pass a std:: classes from libstdc++ > built code to libc++ code without bad things happening. I would expect that also, but libc++ has versioned namespaces that _should_ prevent that from happening (I.e, cause linker errors). > I'm not sure whether just turning whether the following is safe or not: > > clang++ -c -stdlib=libc++ x.cpp > clang++ -c -stdlib=libc++ -std=c++11 y.cpp > clang++ -stdlib=libc++ x.o y.o I would expect either: * It would "just work" * It would fail to link depending on what the contents of x.cpp and y.cpp were. If you can come up with a good way of explaining this, I'll be happy to add it to my post. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

1 0

[interprocess] Problem building i386 binary on x86_64 MacOSX machine
by Walter Horsten 05 Jul '12

05 Jul '12

Hello, I have a program that uses boost::interprocess::message_queue, it used to compile correctly as a universal binary (i386 & x86_64) with boost version 1.47, however compiling for i386 fails with version 1.49 and 1.50. The most important parts of the error message are: - no matching function for call to 'boost::interprocess::message_queue_t<boost::interprocess::offset_ptr<void, int, long unsigned int, 0u> >::try_receive(void*, size_t, size_t&, unsigned int&)' - no matching function for call to 'get_rounded_size(long unsigned int, const unsigned int&)' ... is this a bug or is my code incorrect? (I suspect the size of the void* might have something to do with it?) The sample code in the attachment reproduces the problem on my MacBook Pro running OSX Snow Leopard (edit the boost prefix variable in the scripts to your own needs). Kind regards, Walter

1 0

[fusion] g++-4.6, deque, and c++0x compile error
by Karsten Ahnert 05 Jul '12

05 Jul '12

The following trivial program does not compile with g++-4.6.1 and std=c++0x enabled. #include <boost/fusion/container.hpp> int main( int argc , char *argv[] ) { } Seems like a bug, or should I configure something via macros?

3 5

[stratified] library for micro-/userland-threads
by Oliver Kowalke 04 Jul '12

04 Jul '12

Hi, some of the community members ask me to provide a micro-/userland-thread library based on boost.context - I hope boost.stratified is a sufficient implementation. The library contains classes and interfaces similar to boost.thread. Examples and documentation (not finished and needs some updates/correction) is included. I hope I get some feedback from you. best regards, Oliver source: http://olk.bplaced.net/boost-stratified.zip documentation: http://olk.bplaced.net/boost/libs/stratified/doc/html/

9 24

[c++11] compile_if utility
by Lorenzo Caminiti 04 Jul '12

04 Jul '12

Hello all, I was thinking how to program assertion requirements in C++11. I need to program something like this if "has_equal_to<T>" then "assert(back() == value)" else do nothing, don't even compile "assert(back() == value)" Using C++11 lambdas, I was able to program a compile_if utility to do the following: compile_if< boost::has_equal_to<T> >([&]() { assert(this->back() == value); // compiled and executed iff has_equal_to<T> }); Any interest in adding compile_if to Boost.Utility? It could be renamed exec_if if compile_if is too "strong". I didn't play with compile_if much so there might cases where it doesn't work... but I wanted to share it with the ML anyway: #include <boost/type_traits.hpp> #include <cassert> #include <vector> #include <iostream> template< bool Boolean > struct compile_if_c { template< typename UnaryFunc > compile_if_c ( UnaryFunc f ) { std::cout << "compiling" << std::endl; f(); } }; template< > struct compile_if_c <false> { compile_if_c ( ... ) { std::cout << "not compiling" << std::endl; } }; template< class BooleanMetafunc, class UnaryFunc > void compile_if ( UnaryFunc f ) { compile_if_c<BooleanMetafunc::value> compile(f); } template< typename T > class vector { public: typedef typename std::vector<T>::const_reference const_reference; public: void push_back ( T const& value ) { vector_.push_back(value); compile_if< boost::has_equal_to<T> >([&]() { assert(this->back() == value); }); } public: const_reference back ( void ) const { return vector_.back(); } private: std::vector<T> vector_; }; struct x {}; // no operator== int main ( void ) { vector<x>().push_back(x()); // no == so skip assertion back() == value vector<int>().push_back(123); // has == so assert back() == value return 0; } Thanks. --Lorenzo P.S. Eh, if C++11 lambda had constant captures [const&](){ assert(this->back() == value; } I could have even made the assertion constant-correct...

3 4

[Review Request] Inclusion of the Boost.Polygon Voronoi Library
by Andrii Sydorchuk 04 Jul '12

04 Jul '12

Boost community, It has been two years since I started development of the Voronoi library as part of the Google Summer of Code 2010. Finally I feel that the library is ready to become public and would like to request a review for the inclusion into the Boost.Polygon library. Features: - Robust and efficient implementation of the sweepline algorithm that allows to construct Voronoi diagram, Delaunay triangulation and medial axis of a set of points and line segments. - Coordinates of the output geometries are computed within the 64 machine epsilon relative error (6 mantissa bits). - Voronoi diagram data structure that allows efficient traversal and data association with the output Voronoi graph. - No 3rd party dependencies (e.g. GMP, MPFR), all the required multiple precision types are implemented as part of the library. - The input and output coordinate type domains are configurable via coordinate type traits, thus allowing to compute coordinates of the Voronoi vertices within any required precision. - The full construction of the Voronoi diagram of 100 000 points takes only 0.27 seconds (see benchmarks). The full list of features could be found here: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_main.htm Limitations: - Input geometries should have integer coordinates; - Input segment data sets should not contain intersection points, except segment's endpoints. Information on why the first limitation is not sufficient is explained here: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_advanced_tutorial.htm The second limitation could be waved using native Boost.Polygon functionality: http://svn.boost.org/svn/boost/sandbox/gtl/doc/gtl_polygon_set_concept.htm Resources: The code is already merged with the Boost.Polygon sandbox branch. All the Voronoi related files are prefixed with "voronoi". - Code location: http://svn.boost.org/svn/boost/sandbox/gtl - Main documentation page: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_main.htm or http://svn.boost.org/svn/boost/sandbox/gtl/doc/index.htm - Benchmarks: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_benchmark.htm - Examples: http://svn.boost.org/svn/boost/sandbox/gtl/libs/polygon/example/output_data/ - Tests: http://svn.boost.org/svn/boost/sandbox/gtl/libs/polygon/test/ - Tutorials: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_basic_tutorial.htm and http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_advanced_tutorial.htm - Official Google+ page: https://plus.google.com/b/109395909314556242008/ Review manager: I would kindly ask Simonson, Lucanus J. the author of the Boost.Polygon library to be my review manager. PS. The library was designed in a user friendly way, so I would invite everyone to give it a try! No configuration of the geometric or predicate kernels is required. Simply follow the basic tutorial: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_basic_tutorial.htm Thanks and have fun, Andrii

11 86

[ratio] error in template specialization: template parameter n1 depends on another template parameter
by Krzysztof Czainski 04 Jul '12

04 Jul '12

Hello, In order to use Boost.Ratio with my poor compiler from TI, I had to apply the attached fix. I suspect a more general fix would be desirable, should such a fix be added to Boost. However, before investigating further, I'd like to ask, if such a fix would be welcome, or is my compiler too poor to be supported by Boost.Ratio? Regards, Kris

2 3

boost.stratified -> boost.fiber
by Oliver Kowalke 04 Jul '12

04 Jul '12

Hi, as requested I've renamed boost.stratified to boost.fiber. archive is avialble at : http://olk.bplaced.net/boost-fiber.zip for those in Japan, Korea, etc please use http://www.hidemyass.com/ (proxy) to circumvent http 403 from the web-hoster. regards, Oliver

1 0

[type_index] C++03 implementation in boost?
by Agustín K-ballo Bergé 03 Jul '12

03 Jul '12

After crafting my own `type_info_ptr` as a thin wrapper to be able to use `std::type_info` as key in maps, I found out about the new `std::type_index` in C++11. It seems that a C++03 implementation would be trivial, except for the hashing functionality. Could that functionality be built by leveraging implementation specific details like whether there is only one `type_info` instance for each type, or whether the name member function returns distinct values? I believe it would be a nice addition to Boost, perhaps as part of the utility library. It would be useful for those wanting to use C++11 features while still writing C++03 compatible code. Agustín K-ballo Bergé.- http://fusionfenix.com

3 6

Large Integer Library
by Michael Tryhorn 03 Jul '12

03 Jul '12

Dear Boosters, I have written a Boost-compatible library for the representation and manipulation of integers of large or arbitrary size (including 128bit and above). I would like to make a preliminary submission of this library for your review and input, for potential inclusion into Boost v1.51.0 or later, as per the Boost Library Submission Process. The library and all its files are publicly available on github, at: http://github.com/mjtryhorn/Boost.LargeInt A tagged .zip of these files (v1.0.0) is available for download at: http://github.com/mjtryhorn/Boost.LargeInt/tags This library has been written for strict conformance to C++03 and the Boost coding guidelines. This library is also header-only, and as such may be directly merged into existing Boost installations without the need for recompilation. All files are distributed under the Boost Software License, Version 1.0. Now a quick explanation of why I've written this library and what it does: I have found myself on several occasions to be working with unsigned 64bit numbers, mostly for the sizes of files or C++ collections. Where I had a need to perform a calculation upon those numbers, there was often the possibility of overflow. 128bit integers would have been an appropriate fix, but these are either entirely unavailable, non-portable, or in a library which I preferred not to use either due to its complexity or incompatible licensing. Floating-point arithmetic is also a means around the problem, but is inherently inaccurate. I decided to fix this problem once-and-for-all by writing a new integer arithmetic library, making judicious use of C++'s template-metaprogramming and Boost to make my solution both as simple and as transparent as possible. Now, what started out as 128bit integers for my own use has grown into a fully- functional library which has the ability to compose any two integer or integer- like types into a new, larger, signed or unsigned integer type, including all the standard integral operators and a number of utility functions to support them. Thus, Boost.LargeInt supports not only signed and unsigned 128bit integer arithmetic but 24bit, 64bit, 160bit, 192bit, 256bit, 512bit and more. Boost.LargeInt is compatible and has been tested with the following compilers and platforms: GNU GCC 4.6.1, 4.6.2 (Linux, Ubuntu 11.10 (64bit) & openSUSE 12.1 (32bit)) Borland C++ 5.6.4 (Windows XP SP3, Borland C++ Builder 6) Microsoft Visual C++ 2010 (Windows XP SP3, Microsoft Visual Studio 2010) (I have also tried to add compatibility for Microsoft Visual C++ 6, but unfortunately this compiler's support for template-metaprogramming is insufficient and the tests for Boost.LargeInt fail to compile.) Documentation is included in BoostBook format (.qbk), but a pre-compiled version is available alongside the library code itself for your convenience. Please, if you have the time, download this library and give it a try. Any comments, or information upon its compatibility (or lack thereof) with compilers which are or are not listed would be greatly appreciated. If no-one has any comments (I think that unlikely ;-) ), then I shall resubmit this library for formal review. Thanks, Michael J. Tryhorn

9 20

CRC 16 Bit Implementation
by GAURAV GUPTA 03 Jul '12

03 Jul '12

Hi, In my application I need to use crc_64_type. I did not find its implemetation in crc.hpp. Anyone implemented it? -- Regards, Gaurav

2 1

[range] treating N-ary function with N-1 default args as unary
by Nathan Ridge 03 Jul '12

03 Jul '12

Hi, Some Boost.Range adaptors, such as 'transformed' or 'filtered', require a unary function. The documentation does not formally define "unary function", but it's pretty clear what it ought to be: a function (object) that's callable with one argument. Thus, to me, the following is a perfectly valid unary function: int foo(int a, int b = 0); as it is callable with one argument. However, Boost.Range does not accept such a function as an argument to 'transformed' or 'filtered'. For example, the following code: #include <boost/range/adaptor/transformed.hpp> int foo(int a, int b = 0); int main() { int A[5]; A | boost::adaptors::transformed(foo); } produces the following compiler errors (recent Boost trunk, with GCC 4.7): In file included from boost/preprocessor/iteration/detail/iter/forward1.hpp:52:0, from boost/utility/result_of.hpp:113, from boost/iterator/transform_iterator.hpp:23, from boost/range/adaptor/transformed.hpp:16, from test.cpp:1: boost/utility/detail/result_of_iterate.hpp: In instantiation of 'struct boost::detail::cpp0x_result_of_impl<int (* const(int&))(int, int)>': boost/utility/detail/result_of_iterate.hpp:46:8: required from 'struct boost::result_of<int (* const(int&))(int, int)>' boost/mpl/eval_if.hpp:38:31: required from 'struct boost::mpl::eval_if<boost::is_same<boost::use_default, boost::use_default>, boost::result_of<int (* const(int&))(int, int)>, boost::mpl::identity<boost::use_default> >' boost/iterator/iterator_adaptor.hpp:160:12: required from 'struct boost::detail::ia_dflt_help<boost::use_default, boost::result_of<int (* const(int&))(int, int)> >' boost/iterator/transform_iterator.hpp:50:17: required from 'struct boost::detail::transform_iterator_base<int (*)(int, int), int*, boost::use_default, boost::use_default>' c++/4.7.0/bits/stl_iterator_base_types.h:143:1: recursively required from 'constexpr const bool std::__has_iterator_category_helper<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >::value' c++/4.7.0/bits/stl_iterator_base_types.h:143:1: required from 'struct std::__has_iterator_category<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' c++/4.7.0/bits/stl_iterator_base_types.h:160:12: required from 'struct std::iterator_traits<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/detail/iterator.hpp:81:8: required from 'struct boost::detail::iterator_traits<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/iterator/iterator_traits.hpp:30:75: required from 'struct boost::iterator_value<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/range/iterator_range_core.hpp:139:49: required from 'class boost::iterator_range<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/range/adaptor/transformed.hpp:25:16: required from 'struct boost::range_detail::transformed_range<int (*)(int, int), int [5]>' test.cpp:8:41: required from here boost/utility/detail/result_of_iterate.hpp:69:5: error: too few arguments to function In file included from boost/range/iterator_range_core.hpp:22:0, from boost/range/iterator_range.hpp:13, from boost/range/adaptor/transformed.hpp:15, from test.cpp:1: boost/iterator/iterator_traits.hpp: In instantiation of 'struct boost::iterator_value<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >': boost/range/iterator_range_core.hpp:139:49: required from 'class boost::iterator_range<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/range/adaptor/transformed.hpp:25:16: required from 'struct boost::range_detail::transformed_range<int (*)(int, int), int [5]>' test.cpp:8:41: required from here boost/iterator/iterator_traits.hpp:30:75: error: no type named 'value_type' in 'struct boost::detail::iterator_traits<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/iterator/iterator_traits.hpp: In instantiation of 'struct boost::iterator_difference<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >': boost/range/iterator_range_core.hpp:143:54: required from 'class boost::iterator_range<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/range/adaptor/transformed.hpp:25:16: required from 'struct boost::range_detail::transformed_range<int (*)(int, int), int [5]>' test.cpp:8:41: required from here boost/iterator/iterator_traits.hpp:49:80: error: no type named 'difference_type' in 'struct boost::detail::iterator_traits<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/iterator/iterator_traits.hpp: In instantiation of 'struct boost::iterator_reference<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >': boost/range/iterator_range_core.hpp:157:53: required from 'class boost::iterator_range<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/range/adaptor/transformed.hpp:25:16: required from 'struct boost::range_detail::transformed_range<int (*)(int, int), int [5]>' test.cpp:8:41: required from here boost/iterator/iterator_traits.hpp:36:74: error: no type named 'reference' in 'struct boost::detail::iterator_traits<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' Would it be possible to treat N-ary functions with N-1 default arguments as unary? Thanks, Nate

6 8

[Trac] New components
by Daniel James 03 Jul '12

03 Jul '12

Hello, Please can someone with the appropriate trac permissions add two new components "functional/overloaded function" and "local function", both have maintainer "lcaminiti". Maybe also "utility/identity type", or does that come under "utility"? thanks, Daniel

3 4