May 2006 - Boost - lists.boost.org

[type_traits][result_of] Handling of cv-qualified function pointers/references
by João Abecasis 31 May '06

31 May '06

Hi! While fixing some issues with fusion::unpack_args I noticed that cv-qualified function pointers are not handled by result_of and type_traits::is_function doesn't handle cv-qualified functions. Here's a simple test case for result_of: #include <boost/utility/result_of.hpp> typedef int (* const c_func_ptr)(int); typedef boost::result_of<c_func_ptr(int)>::type return_type; and a slightly more convoluted for type_traits::is_pointer: #include <boost/type_traits/is_function.hpp> #include <boost/static_assert.hpp> void foo (); template <class F> void bar(F &) { BOOST_STATIC_ASSERT(boost::is_function<F const>::value); } template <class F> void baz(F const & f) { bar(f); } int main() { baz(foo); } Both failing with gcc-4.x. The first test case also fails with gcc-3.2.3. while the second case fails for a completely different reason in overload resolution. For unpack_args I worked around these issues by applying remove_cv to pointers in general and also before testing with is_function. In either case cv-qualification shouldn't affect the type of the arguments or the result, which is what I'm interested in. Anyway I'm thinking that the solution could be moved upstream so others won't stumble upon the same issues. Thoughts? Best regards, João

2 2

[SoC][tree] Theoretical foundations etc.
by Bernhard Reiter 30 May '06

30 May '06

Dear all, just a quick note to * say thanks for accepting my application for the Generic Tree Container * point everyone to my freshly set-up blog at http://www.unet.univie.ac.at/~a0057324/php/blog/ * ask everybody to read the (admittedly pretty lengthy) blog post there on trying to distill a powerful tree interface * and, most importantly, invite everybody to comment on it as that blog is supposed to be the place where i'd like to get in touch with people on technical details without burdening the dev list initially. Kind Regards Bernhard Reiter

2 1

Re: [boost] [multi_index] benchmarking
by JOAQUIN LOPEZ MU?Z 30 May '06

30 May '06

Hello Maxim, ----- Mensaje original ----- De: Maxim Yegorushkin <maxim.yegorushkin(a)gmail.com> Fecha: Domingo, Mayo 28, 2006 12:54 pm Asunto: [boost] [multi_index] benchmarking > As a part of a project I needed to compare performances of > boost::multi_index hashed_unique/ordered_unique indexes > with those of std::tr1::unordered_set, > __gnu_cxx::hash_set, std::set. multi_index performance > documentation page does not provide this kind of > information, Main reason being that std::tr1::unordered containers are not generally available in current environments, although this seems to be improving fast. > so I had to write my own test. I thought > it might be a good idea to add the results to the > documentation page. Source code for the test is provided. > > Here is a sample run: [...] Thank you for sharing your data. Figures show that hashed indices have ample room for improvement with respect to implementations of unordered containers. I have a question, an open question, a request and an invitation. * Which compiler/environment have you run this with? I guess GCC 4.x since you've got tr1 containers. * From the figures on memory consumption of mi_set looks like you're using Boost 1.33.1 (which still doesn't have the spatial optimization suggested by you and described at http://tinyurl.com/rwvvt) right? If so, I cannot find a reason why mi_set performs in general sensibly better than std_set, since the data structures and algorithms are basically equivalent, and B.MI introduces some metaprogramming overhead that the optimizer usually doesn't clean away entirely. I'd have hoped for a small decrease in performance for B.MI, though not as high as that observed in mi_hash wrt std_hash. Do you have an idea anout this? * I'd be grateful if you could rerun the tests for the RC_1_34_0 branch, since mi_set should perform quite better, and erase test(mi_hash) should also improve. If you do this, please report your results back. I must say that B.MI does not intend to outperform single-index std containers since in general the data structures are equivalent; it is when multi-indexing comes into play that I expect a large impact in favor of B.MI. That said, I do what I can in order to optimize the internal algorithms, and your data shows that there's room for improvement in hashed indices --I know you've got good knowledge of the internals of B.MI, so if you feel like contributing to this task or have some ideas to increase performance, you are most welcome. Best regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 7

Problem with range (make_iterator_range)?
by Neal Becker 30 May '06

30 May '06

#include <boost/range.hpp> #include <vector> template<typename in_t, typename out_t> void copy (in_t const& in, out_t &out) {} int main() { std::vector<int> out (2); copy (boost::make_iterator_range (out.begin(), out.begin()+2), boost::make_iterator_range (out.begin(), out.begin()+2)); } wrap/test.cc:12: error: invalid initialization of non-const reference of type 'boost::iterator_range<__gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int> > > >&' from a temporary of type 'boost::iterator_range<__gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int> > > >' wrap/test.cc:6: error: in passing argument 2 of 'void copy(const in_t&, out_t&) [with in_t = boost::iterator_range<__gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int> > > >, out_t = boost::iterator_range<__gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int> > > >]'

4 12

Errors in source
by Silex 30 May '06

30 May '06

In compiler_config.hpp, I found the following line: #include "boost/date_time/locale_config.hpp" Maybe it'd be more conventionnal if it used <> instead of "" but that's a minor issue, the problem is when I open this include file I see : #ifndef DATE_TIME_LOCALE_CONFIG_HPP___ #define DATE_TIME_LOCALE_CONFIG_HPP____ This could maybe lead to linker errors as multiple inclusions could occurs. Philippe

2 3

[filesystem] xlC error compiling operations.hpp
by K. Noel Belcourt 30 May '06

30 May '06

Hi, The xlC compiler on the IBM issues a severe error when compiling operations.hpp. The compile error appears to be legitimate (use of an undefined class). Unfortunately I don't have a patch to offer, just the bug report. Thanks. -- Noel Belcourt vacpp.compile.c++ ../../../bin.v2/tools/regression/build/vacpp/ release/link-static/process_jam_log.o "../../../boost/filesystem/operations.hpp", line 732.72: 1540-1118 (S) The declaration of "end_itr" uses the undefined class "boost::filesystem::basic_directory_iterator<boost::filesystem::basic_pa th<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,boost::filesystem::path_traits> >" when the class must be complete. "../../../boost/filesystem/operations.hpp", line 730.21: 1540-0700 (I) The previous message was produced while processing "boost::filesystem::detail::remove_all_aux<boost::filesystem::basic_path <std::basic_string<char,std::char_traits<char>,std::allocator<char> >,boost::filesystem::path_traits> >(const basic_path<std::basic_string<char,std::char_traits<char>,std::allocator< char> >,boost::filesystem::path_traits> &)". "../../../boost/filesystem/operations.hpp", line 473.11: 1540-0700 (I) The previous message was produced while processing "boost::filesystem::remove_all<boost::filesystem::basic_path<std::basic_ string<char,std::char_traits<char>,std::allocator<char> >,boost::filesystem::path_traits> >(const basic_path<std::basic_string<char,std::char_traits<char>,std::allocator< char> >,boost::filesystem::path_traits> &)". "../../../boost/filesystem/operations.hpp", line 689.16: 1540-0700 (I) The previous message was produced while processing "boost::filesystem::remove_all(const path &)". mpCC -c -DBOOST_ALL_NO_LIB=1 -DNDEBUG -O3 -qstrict -qinline -qeh - qrtti -I"../../.." -o "../../../bin.v2/tools/regression/build/vacpp/ release/link-static/process_jam_log.o" "../process_jam_log.cpp"

1 0

Re: [boost] Infinite precision integer draft
by Jarrad Waterloo 30 May '06

30 May '06

Thanks for the welcome of all the other enhancements, especially in the area of conversion, to make your integer library easy to use for everyone. Further, don't get discouraged as your colleagues discuss the meaning of 0, life and the universe while people who actually would use it already understand what 0 means because we have been without, 0, this library for so long. 'Feed a mouse a cookie and he will ask for a glass of milk.' > Creating integers with variable size on the stack, > that is in any case something that I will not > specify, but users that want to use these tricks > can just override the integer_allocator. Currently you have an integer class which takes an integer_allocator base class. Even though the spec doesn't mention this or I glossed over reading it but you probably are going to provide a heap_integer_allocator class that could be named whatever but exists as the default integer_allocator for the integer class. This way users can just start using the library right away instead creating there own allocator the first time they use this library. What I was suggesting was not a change to the integer, integer_allocator base class or the currently unnamed heap_integer_allocator! Rather the addition of a stack_integer_allocator<size_t> : public integer_allocator. The reasons for the library to provide this instead of the end user is as follows: 1) Performance, stack based allocations are faster than heap based and in some field domains one will know the upper limit on size. This generates the need for multiple people wanting to do this especially when performance matters. 2) Standardization, if you foresee that many people are going to need this functionality than your library becomes easier because you can go ahead and provide the class instead of a large unsigned integer of people having to reinvent the wheel and create the exact same class themselves. 3) Maintain ease of use as complexity increases, in just this one area this library could suffer from the opposite problem of the standard library. The standard library algorithms was all passing 2 iterators around which allows for maximum flexibility for more complicated scenarios but lacked the overrides like boost Range where you could pass the collection and the algorithm uses begin and end for the more common and simple scenarios. Integer library does the opposite which is mostly good, it provides the heap allocator for the most common and general use but as complexity increases and someone needs stack based allocator the user is left in the lurch and have to right there own, over and over again from user to user. I just believe this library would be more feature complete if it would just go ahead and provide the both implementations up front. 4) Architectural consistency, this library is designed to behave like existing integer types that can be created both on the stack and on the heap.

1 0

Problem with range?
by Neal Becker 30 May '06

30 May '06

STL iterators are designed so that ordinary pointers can be iterators. Can we do the same with boost::range? With STL we can do: int x; std::copy (&x, &x+1, output); Does this work for range? #include <boost/range.hpp> template<typename in_t> void F (in_t const& in) { typename boost::range_const_iterator<in_t>::type i = boost::begin (in); for (; i != boost::end (in); ++i) ; } int main() { int x; F (boost::sub_range<int*> (&x, &x+1)); } usr/local/src/boost.cvs/boost/range/sub_range.hpp:26: instantiated from ‘boost::sub_range<int*>’ test.cc:11: instantiated from here /usr/local/src/boost.cvs/boost/range/mutable_iterator.hpp:37: error: ‘int*’ is not a class, struct, or union type How do I turn the 'int x' into a 'range'?

3 3

Physical quantities (was re: Infinite precision integer draft)
by Jonathan Ray 30 May '06

30 May '06

>> Here's three: >> 1. Counting *anything* >This is more a case where you restrict yourself to addition, >and therefore never *need* negative numbers. But why would you want >a type for which operator- is not defined? I was neither supporting unsigned intergers nor supporting a type for which - is not defined. I was just pointing out flaws in the form of your argument. There are plenty of physical quantities that are always natural numbers and can be ridiculously large. For example, the number of microstates in a hot cup of tea. The unsigned integer might me useful if it asserted something on underflow to help the programmer debug, but barring that it's just a hack to save a bit. Refusing to define - on a numerical type wouldn't save anybody any trouble except the library writer. > Quantum states are solutions to equations. Those solutions are > discrete and therefore countable. Literally everything that can be represented on a computer in a finite space (e.g. Earth) is one of a finite number of possible values, so that line of reasoning is irrelevant.

1 0

[Boost-bugs] [ boost-Patches-1489352 ] evc4 port: Interlocked*-functions without volatile
by SourceForge.net 30 May '06

30 May '06

Patches item #1489352, was opened at 2006-05-16 10:20 Message generated for change (Settings changed) made by pdimov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1489352&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Resolution: Accepted Priority: 5 Submitted By: Michael Fink (vividos) Assigned to: Peter Dimov (pdimov) Summary: evc4 port: Interlocked*-functions without volatile Initial Comment: This patch fixes the definition of the Interlocked*-functions when using Windows CE (_WIN32_WCE is defined). The functions use the "old" (VC6 without platform SDK) forms of the functions without the volatile keyword. The patch can be applied to both CVS HEAD and the 1_34 branch, since the file wasn't modified since then. ---------------------------------------------------------------------- Comment By: Peter Dimov (pdimov) Date: 2006-05-18 01:41 Message: Logged In: YES user_id=305912 Applied to 1.34 and HEAD. ---------------------------------------------------------------------- Comment By: Michael Fink (vividos) Date: 2006-05-17 10:57 Message: Logged In: YES user_id=124874 I added a new version of the patch that avoids WINAPI (replaced by __cdecl, as used by the BOOST_MSVC part of the file. Including <windows.h> is not needed here, I think. In evc4 there are no intrinsics for the Interlocked-functions and the pragmas produce errors telling so. The _WIN32_WCE part of the file provides the BOOST_INTERLOCKED_ macros in its own section now. ---------------------------------------------------------------------- Comment By: Peter Dimov (pdimov) Date: 2006-05-16 13:42 Message: Logged In: YES user_id=305912 The patch doesn't look correct to me. Using WINAPI would require inclusion of <windows.h>; in this case just defining BOOST_USE_WINDOWS_H would be a better approach. It also patches the intrinsic section without also declaring the functions as intrinsics; is this intended? Does evc4 have intrinsic support for these functions? If it doesn't, we need to disallow the intrinsic path for _WIN32_WCE and patch the WIN32 section instead. ---------------------------------------------------------------------- Comment By: Michael Fink (vividos) Date: 2006-05-16 10:40 Message: Logged In: YES user_id=124874 Changed summary: it's only evc4 of course, since evc3 is too non-standard to support boost. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1489352&group_… _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0