May 2011 - Boost - lists.boost.org

[Opaque] Request for interest in Opaque typedefs library emulation
by vicente.botet 27 Jul '11

27 Jul '11

Hi, I have started to play with a class to define opaque typedefs on funcdamental types. It is based on the C++ proposal " Progress toward Opaque Typedefs for C++0X" by Walter E. Brown http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1891.pdf and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1706.pdf Please take a look on the preceding links to understand the motivation. Boost.Sericalization provide a BOOST_STRONG_TYPEDEF already, but in my opinon the implementation is not complete,as only the order operators are defined (But maybe I'm wrong). Evidently it can not provide everything we can have with a language approach, but IMO this could yet be useful. The library include two class templates (CRTP) to define opaque types: * public_opaque_type<OT,UT> : implicit conversion from OT to UT * private_opaque_type<OT,UT> : no conversion from OT to UT An opaque type (OT) is a new type, different from the underlying type (UT) and other OT. It defines explicit constructor from the UT, and defines all the operators the UT support but this time applied to the OT. To define a new OT with this mixin classes struct serial_number: public_opaque_type<serial_number, unsigned> { BOOST_OPAQUE_PUPLIC_FORWARD_CONSTRUCTORS(serial_number,unsigned); }; struct game_score: private_opaque_type<game_score, unsigned> { BOOST_OPAQUE_PRIVATE_FORWARD_CONSTRUCTORS(game_score,unsigned); }; In addition, defines macros that make this simpler BOOST_OPAQUE_PUBLIC_TYPEDEF(unsigned, serial_number); BOOST_OPAQUE_PRIVATE_TYPEDEF(unsigned, game_score); Next follows the definition of the public_opaque_type template <typename Final, typename T> class public_opaque_type : boost::totally_ordered< Final , boost::integer_arithmetic< Final , boost::bitwise< Final , boost::unit_steppable< Final , boost::totally_ordered< T, Final // public specific conversions , boost::integer_arithmetic< T, Final // public specific conversions , boost::bitwise< T, Final // public specific conversions > > > > > > > { protected: T val_; typedef public_opaque_type opaque_type; public: typedef T underlying_type; explicit public_opaque_type(const T v) : val_(v) {}; public_opaque_type() {}; public_opaque_type(const opaque_type & rhs) : val_(rhs.val_) {} public_opaque_type & operator=(const opaque_type & rhs) { val_ = rhs.val_; return *this; } public_opaque_type & operator=(const T rhs) { val_ = rhs; return *this; } T const& underlying() const { return val_; } T& underlying() { return val_; } operator const T & () const { return val_; } operator T & () { return val_; } #if 0 bool operator==(const opaque_type & rhs) const { return val_ == rhs.val_; } #endif bool operator<(const Final & rhs) const { return val_ < rhs.val_; } Final& operator+=(const Final & rhs) { val_ += rhs.val_; return static_cast<Final&>(*this); } Final& operator-=(const Final & rhs) { val_ -= rhs.val_; return static_cast<Final&>(*this); } ... }; I have started to make some tests and it works well for the moment. Limitations: * As we can not specialize the behaviour of static_cast/dynamic_cast the library sould provide two specific casts opaque_static_cast and opaque_dynamic_static_cast (Not yet implemented). * As operator.() can not be overloaded, it works transparently only for underlying types that don't defines member functions (C++ fundamental types, as int, char, ...). For the others an explicit use of the underlying() member function is needed :( * Others I have not catched yet :( Do you think it is worth continuing? Please, let me know if you see a error on the design. _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

4 8

[filesystem] home_directory_path
by Jeff Flinn 24 Jul '11

24 Jul '11

In looking at implementing a portable home_directory_path function a few questions arise. Based on http://en.wikipedia.org/wiki/Home_directory, POSIX and other UNIX flavors 'appear' to be a straight forward use of the "HOME" environment variable. Does anyone have any experience where the "HOME" variable is not the proper source of the user's home directory? Windows NT and above have the "USERPROFILE" environment variable. Using this would be the easiest to use. But I've seen discussion that this may not always be properly defined, in particular if the user has reset their home directory to a non-system drive. I haven't tracked down it's availability on WinCE. Does anyone have experience with this platform? There is the windows GetUserProfileDirectory api function also available since NT4. This is in the Userenv.lib/dll, obviously adding a link dependancy. How are these sorts of system link dependencies handled? Through bjam? Or is it acceptable/better to use #pragma comment(lib,"Userenv.lib")? In looking at some client code using home_directory_path, I see that they generally are looking for the user's Desktop directory(Mac & Windows). Obviously this only makes sense on GUI platforms. The issue with merely getting this path via home_directory_path() / "Desktop" is IIRC, that at least on windows "Desktop" is localized and may not exist with that name on non-english localized systems. Windows has the SHGetFolderPath api. I need to look into Mac's native support. Any thoughts on the general usefulness of a portable desktop_directory_path? Thanks, Jeff

16 60

RFC: type erasure
by Steven Watanabe 20 Jul '11

20 Jul '11

AMDG Over the last few months I've re-done my type erasure library from scratch, fixing a lot of the bad design decisions I made originally. Here's a basic sample of what you can do with it: simulate boost::any: type_erasure::any< mpl::vector<copy_constructible<>, typeid_<> > > x(10); simulate boost::function<void(int)>: type_erasure::any< mpl::vector<copy_constructible<>, typeid_<>, callable<void(int)> > > f(foo); The code is available from the Vault: http://tinyurl.com/3z9jcwp The library is nearly complete. I've included pre-built html documentation in the zip. Questions, comments, and criticism are welcome. In Christ, Steven Watanabe

7 22

[local] Review request
by Lorenzo Caminiti 18 Jul '11

18 Jul '11

Hello all, I happy to announce that I have released Boost.Local 0.2.0 incorporating the many valuable suggestions that I have received from this mailing list. I would like to request to add Boost.Local to the review schedule and for any volunteer to be the review manager. Thank you! Boost.Local supports local functions, local blocks, and local exits for C++. For example: #include <boost/local/function.hpp> #include <boost/local/block.hpp> #include <boost/local/exit.hpp> #include <algorithm> #include <iostream> #include <cassert> int main() { double sum = 0.0; int factor = 10; void BOOST_LOCAL_FUNCTION_PARAMS(double num, const bind factor, bind& sum) { sum += factor * num; std::cout << "Summed: " << sum << std::endl; } BOOST_LOCAL_FUNCTION_NAME(add) add(100.0); size_t size = 2; double* nums = new double[size]; BOOST_LOCAL_EXIT(const bind& size, bind nums) { if (size && nums) delete[] nums; std::cout << "Freed array: " << nums << std::endl; } BOOST_LOCAL_EXIT_END nums[0] = 90.5; nums[1] = 7.0; std::for_each(nums, nums + size, add); // `add` as template parameter BOOST_LOCAL_BLOCK(const bind& sum) { assert(sum == 1975.0); // so far `sum` is 10*100+10*90.5+10*7=1975 std::cout << "Asserted summation: " << sum << std::endl; } BOOST_LOCAL_BLOCK_END return 0; } Documentation: http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/index.html Source code: http://svn.boost.org/svn/boost/sandbox/local/ Release Notes for Version 0.2.0 (2011-05-14) 1. Replaced parenthesized syntax with variadic and sequencing macro syntaxes. 2. Profiled library performances against other approaches. 3. Replaced virtual functor trick with casting functor trick (for smaller run-time). 4. Optimized library run-time (rearranging code and not using casting functor trick on compilers that accept local classes as template parameters). 5. Added BOOST_LOCAL_FUNCTION_NAME(inline ...) and BOOST_LOCAL_FUNCTION_NAME(recursive ...). 6. Added BOOST_LOCAL_TYPEOF. 7. Added bind(type) to specify bind type explicitly (skipping Boost.Typeof type deduction). 8. Removed boost::local::function (use boost::function instead). 9. Added boost::local::function::overload to overload local functions (and functors in general). 10. Implemented support for nesting local functions, blocks, and exits into one another. Boost.Local was used by Gregory Crosswhite in one of his project: https://github.com/gcross/CodeSearch -- Lorenzo

6 28

[BGL] Contribute to the Boost Graph Library
by Camillo Anania 15 Jul '11

15 Jul '11

Hi all, I used BGL for around 6 months for my thesis (write a routing algorithm). I highly appreciate the BGL and I'm glad someone did it and generously gives their time to maintain/improve it. So now I would like to contribute to the development of the library and so give back something. Just a brief introduction to my profile: - a bachelor and a master in Computer Engineering - six months of experience using the BGL - good knowledge of C++ - great wish to improve my programming skills and master generic programming technique Can you please indicate me the steps I should do to start to actively help the development process? Thanks Camillo Anania

3 4

[mpl] string to type conversion
by Bartosz Marcinkiewicz 19 Jun '11

19 Jun '11

Hello, I would like to have a macro which could be used like this: STRING_TO_TYPE( MyType ) which would yield: typedef mpl::string<'M','y','T','y','p','e'> MyType_id_t; Any ideas how to implement something like that? Thanks for any help, bma. -- Bartosz Marcinkiewicz tel. (+48) 516 034 243 e-mail: bma(a)epcon.pl, bartosz.marcinkiewicz(a)epcon.pl EPCON Sp. z o.o. www.epcon.pl adres: 53-407 Wrocław, ul. Gajowicka 114/116 tel. (+48) 71 361 75 55 ext.36 fax (+48) 71 361 74 44 NIP PL 899-24-92-498 KRS 0000190187 REGON 932963731 Kapitał zakładowy: 500 000 PLN

4 4

[unordered] equal_range is O(bucket_count()), not O(size())
by Brad Higgins 18 Jun '11

18 Jun '11

TR1 specifies that unordered_multimap::equal_range(k) worst case complexity is O(size()). However, in practice, I find that the worst case performance of boost unordred_multimap's equal_range is O(bucket_count()). Is this known? I believe the issue is with the second iterator returned by equal_range(). Specifically, if there are sparse elements in the hash table, the implementation may have to traverse many buckets to find the second iterator. I have a test that demonstrates the issue. The test makes 2 runs over an unordered_multimap, each using the same number of elements. In the second run, it calls rehash() in order to grow the bucket count by a large amount. Notice that the first run is quite fast, while the second run takes more than 10 seconds. Here are the results from my test: ---- $ ./main rehash(0) insert 1000 elements built hash, with 1543 buckets and 1000 elements. Now, get some ranges time to obtain 1000 elements: 00:00:00.001366 rehash(5000000) insert 1000 elements built hash, with 6291469 buckets and 1000 elements. Now, get some ranges time to obtain 1000 elements: 00:00:10.818002 ---- Here is my code for the test: ---- #include <iostream> #include <boost/unordered_map.hpp> #include <boost/date_time/posix_time/posix_time.hpp> typedef boost::unordered_multimap<size_t, size_t> hash_int_type; typedef hash_int_type::iterator hash_int_itr; typedef std::pair<size_t, size_t> hash_insert_type; void run_test(const size_t data_size, const size_t rehash_size) { hash_int_type hash; std::cout << "rehash(" << rehash_size << ")\n"; hash.rehash(rehash_size); std::cout << "insert " << data_size << " elements\n"; for (size_t i=0; i<data_size; i++) { hash_insert_type ins(i,i); hash.insert(ins); } std::cout << "built hash, with " << hash.bucket_count() << " buckets and " << hash.size() << " elements. Now, get some ranges\n"; boost::posix_time::ptime start(boost::posix_time::microsec_clock::local_time()); for (size_t i=data_size-1; i!=0; i--) { typedef std::pair<hash_int_itr, hash_int_itr> ret_pair; ret_pair ret = hash.equal_range(i); if (ret.first != ret.second) { hash.quick_erase(ret.first); } } boost::posix_time::ptime stop(boost::posix_time::microsec_clock::local_time()); boost::posix_time::time_duration diff_time(stop-start); std::cout << "time to obtain " << data_size << " elements: " << diff_time << "\n"; } int main(int argc, char* argv[]) { run_test(1000,0); run_test(1000,5000000); return 0; } ----- Thanks, Brad

2 3

clang type traits
by Bryce Lelbach 13 Jun '11

13 Jun '11

John, Clang has supported GCC style type trait intrinsics (__is_pod, etc) for awhile. The <boost/type_traits/intrinsics.hpp> header doesn't detect this. May I fix this? -- Bryce Lelbach aka wash boost-spirit.com px.cct.lsu.edu github.com/lll-project

4 7

[review] Heaps
by Andrew Sutton 07 Jun '11

07 Jun '11

All, I'd like to announce the beginning of the review of the Heap library, written by Tim Blechmann, and resulting from Tim's 2010 Google Summer of Code project The library implements a number of different heaps (or priority queues) including, a binary heap, d-ary heap, binomial heap, fibonacci heap, pairing heap, and skew heap. The library also provides an adaptor to make heaps mutable, allowing a programmer to modify a value and update its position within the heap. The library also also supports stability, ensuring that elements pushed into a heap with the same priority are popped in the same order. The library is not targeted in any specific domain nor directly related to any specific libraries, but intended to be a collection of general purpose data structures (not unlike the Boost.Unordered library). The documentation and source code can be downloaded from here: Documentation: http://tim.klingt.org/boost_heap Code: http://tim.klingt.org/git?p=boost_heap.git;a=snapshot;h=HEAD;sf=tgz Unlike previous reviews, this review will be assisted by a code review application, Code Collaborator (by SmartBear). The product was tested during a BoostCon session, and we are eager to see how well it scales to a community review. You can use the link below to access and review the Heap library. http://demo.smartbear.com/boost/go?page=ReviewDisplay&reviewid=4 The application allows line-by-line comments of the submitted source code in addition to providing features for general defect and issue reporting. If you are interested in using this system, we will have to register you as a user of the site. You can request access by replying to this message. I'm still learning my way around the system, so there are bound to be some missteps along the way :) If you are not interested in using the system, then feel free to send email like any other review. Reviews of the library should address the following questions. What is your evaluation of the design? What is your evaluation of the implementation? What is your evaluation of the documentation? What is your evaluation of the potential usefulness of the library? Did you try to use the library? With what compiler? Did you have any problems? How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Are you knowledgeable about the problem domain? And finally, every review should answer this question: Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Please note that some questions may be easier to answer in email than with the review tool. As always, reviews are important to the continued quality of the Boost C++ Libraries. Thank you in advance for your comments and contributions. Andrew PS. The review was slated to start on Sunday, but I was not able to make the announcement until today.

7 38

[Review] Boost.Convert review decision
by Edward Diener 07 Jun '11

07 Jun '11

Because Vladimir Batov has expressed himself by saying that he does not want to continue to offer his Boost.Convert library as a library for Boost, I am respecting his decision and his library is NOT accepted into Boost. I am still going to reserve the right to do an analysis of the various viewpoints and offer some way forward for the Boost.Convert library, if Vladimir Batov wishes to pursue it, or for any other library which wishes to present a convert-like interface. I will post this analysis sometime later in the week. There is also still one person who had asked me personally to do a late review by the end of Wednesday, and if that person still wants to do so I would still appreciate his input. I would like to thank Vladimir Batov for offering the library to Boost and all those who did reviews or offer comments about the library even if they did not do an actual formal review. Edward Diener

3 2