- Boost - lists.boost.org

Re: [boost] Re: [review results] hash functions accepted
by brangdon＠cix.compulink.co.uk 22 Mar '05

22 Mar '05

In-Reply-To: <d1na66$6p2$1(a)sea.gmane.org> daniel(a)calamity.org.uk (Daniel James) wrote (abridged): > > 5. change implementation of hash values for pointers so undefined > > behavior is gone (and consider adding x + (x >> 3) ) > > I'm going to do that. Is it worth considering using x + x / sizeof(*p) instead? -- Dave Harris, Nottingham, UK

2 1

Re: [boost] [review results] hash functions accepted
by brangdon＠cix.compulink.co.uk 22 Mar '05

22 Mar '05

In-Reply-To: <d1mq8d$b5q$1(a)sea.gmane.org> nesotto(a)cs.auc.dk (Thorsten Ottosen) wrote (abridged): > 7. the hash_ptr<> suggestion is better done with general indirected > function Did I miss where this was discussed? To recap, we were talking about adding something like: template<typename T> struct hash_ptr { size_t operator()(const T *p) const { return hash_value( *p ); } }; template<typename T> struct equal_ptr { bool operator()( const T *a, const T *b ) const { return *a == *b; } }; to the hash library for use as, eg: unordered_set< MyType *, hash_ptr<MyType>, equal_ptr<MyType> > What do you mean by using a "general indirected function" instead? -- Dave Harris, Nottingham, UK

2 1

[filesystem] symbolic_link_exists naming AND is_file
by Jeff Garland 22 Mar '05

22 Mar '05

I'm writing a small program with filesystem and I needed to check for symbolic links so I can avoid processing them. I noticed the symbolic_link_exists method and, like all good programmers, didn't read the docs b/c I was sure it didn't do what I needed. So I set about writing a function that would and when I looked at the filesystem implementation I realized I was wrong. I was thinking that symbolic_link_exits would check that a symbolic link points to a valid file -- essentially following the symlink. Any reason why this funtion isn't called is_symlink to match the is_directory call? Also, in the code I'm writing I need to only process regular files. So it would be nice to write: if (is_file(my_path)) { //do stuff } where is_file is defined as follows: // equivalent of if (-d path) in perl // returns !is_directory(p) && !is_symlink(p); bool is_file(fs::path p); Or maybe it could be is_regular_file or is_plain_file if we want to be verbose. Seems like this would be handy to have in the filesystem lib. I can probably be talked into supplying patches ;-) Thoughts? Jeff

2 5

BOOST_CHECK_EQUAL again
by Stefan Slapeta 21 Mar '05

21 Mar '05

Hi, attached are the test cases for BOOST_CHECK_EQUAL on strings. I don't know which of the combinations are actually supported, but as you can see in the comments, it's quite mixed at the moment what does work and what not for Intel and VC. (the comments show failing test cases) Gennadiy, shall I add these test cases or are there some we definitely don't support? BTW, the (commented) results are for 1.32 as the code still doesn't work for Intel at all because of the numeric_limits problem! I tested with VC 7.1 and Intel 8.1. Cheers, Stefan #include <boost/test/test_tools.hpp> int test_main( int, char *[] ) { char const *buf_ptr_cch = "abc"; char const buf_array_cch[] = "abc"; char *buf_ptr_ch = "abc"; char buf_array_ch[] = "abc"; std::string buf_str("abc"); BOOST_CHECK_EQUAL(buf_ptr_cch, buf_ptr_cch); BOOST_CHECK_EQUAL(buf_ptr_cch, buf_array_cch); BOOST_CHECK_EQUAL(buf_ptr_cch, buf_ptr_ch); // VC BOOST_CHECK_EQUAL(buf_ptr_cch, buf_array_ch); BOOST_CHECK_EQUAL(buf_ptr_cch, buf_str); BOOST_CHECK_EQUAL(buf_array_cch, buf_ptr_cch); BOOST_CHECK_EQUAL(buf_array_cch, buf_array_cch); BOOST_CHECK_EQUAL(buf_array_cch, buf_ptr_ch); // VC+Intel BOOST_CHECK_EQUAL(buf_array_cch, buf_array_ch); // Intel BOOST_CHECK_EQUAL(buf_array_cch, buf_str); BOOST_CHECK_EQUAL(buf_ptr_ch, buf_ptr_cch); // VC BOOST_CHECK_EQUAL(buf_ptr_ch, buf_array_cch); // VC+Intel BOOST_CHECK_EQUAL(buf_ptr_ch, buf_ptr_ch); BOOST_CHECK_EQUAL(buf_ptr_ch, buf_array_ch); // VC+Intel BOOST_CHECK_EQUAL(buf_ptr_ch, buf_str); BOOST_CHECK_EQUAL(buf_array_ch, buf_ptr_cch); // Intel BOOST_CHECK_EQUAL(buf_array_ch, buf_array_cch); // Intel BOOST_CHECK_EQUAL(buf_array_ch, buf_ptr_ch); // VC+Intel BOOST_CHECK_EQUAL(buf_array_ch, buf_array_ch); BOOST_CHECK_EQUAL(buf_array_ch, buf_str); BOOST_CHECK_EQUAL(buf_str, buf_ptr_cch); BOOST_CHECK_EQUAL(buf_str, buf_array_cch); BOOST_CHECK_EQUAL(buf_str, buf_ptr_ch); BOOST_CHECK_EQUAL(buf_str, buf_array_ch); BOOST_CHECK_EQUAL(buf_str, buf_str); return 0; }

2 3

RE: [boost] Re: google going open source
by Brian Braatz 21 Mar '05

21 Mar '05

Just quickly- I am making good progress on app integration and adding to the Profiler library by Chris Diggins. I will be mailing out more info in the next few weeks. Additionally- a quick look at below looks like it would be something that would add value to profiler lib. I plan on taking a deeper look at that and will report back what I see. I want to REALLY spend some time with below to understand it better\ see how it could fit in with current profiler being worked on. THANK YOU for sending this out, very interesting.... > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Martin Wille > Sent: Friday, March 18, 2005 12:50 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: google going open source > > Thorsten Ottosen wrote: > > "Bronek Kozicki" <brok(a)rubikon.pl> wrote in message > > news:4239ED44.5090508@rubikon.pl... > > | under BSD 2.0 license > > | http://code.google.com/ > > | > > > > Hm...would anyone volenteer to boostify > > https://sourceforge.net/projects/goog-perftools/, > > Can't be done, due to the license. > > Regards, > m > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Mersenne Twister seed fix
by Daniel van der Zee 21 Mar '05

21 Mar '05

I was wondering if the fix to mersenne twister as suggested in http://lists.boost.org/MailArchives/boost/msg78304.php made it into the random number library for the next release. Thanks, Daniel

1 0

RE: [boost] Re: google going open source
by Brian Braatz 21 Mar '05

21 Mar '05

I would also like to request anyone who looks at this or spends time with it share on the list what they have learned. So far, it looks like it is gcc only as shipped, so porting is one area that needs analysis > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Brian Braatz > Sent: Monday, March 21, 2005 9:22 AM > To: boost(a)lists.boost.org > Subject: RE: [boost] Re: google going open source > > Just quickly- I am making good progress on app integration and adding to > the Profiler library by Chris Diggins. > > I will be mailing out more info in the next few weeks. > > Additionally- a quick look at below looks like it would be something > that would add value to profiler lib. I plan on taking a deeper look at > that and will report back what I see. I want to REALLY spend some time > with below to understand it better\ see how it could fit in with current > profiler being worked on. > > THANK YOU for sending this out, very interesting.... > > > > -----Original Message----- > > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] > > On Behalf Of Martin Wille > > Sent: Friday, March 18, 2005 12:50 AM > > To: boost(a)lists.boost.org > > Subject: Re: [boost] Re: google going open source > > > > Thorsten Ottosen wrote: > > > "Bronek Kozicki" <brok(a)rubikon.pl> wrote in message > > > news:4239ED44.5090508@rubikon.pl... > > > | under BSD 2.0 license > > > | http://code.google.com/ > > > | > > > > > > Hm...would anyone volenteer to boostify > > > https://sourceforge.net/projects/goog-perftools/, > > > > Can't be done, due to the license. > >

1 0

[filesystem] include_pathes?
by David Abrahams 21 Mar '05

21 Mar '05

Seems to me that this should be "include_paths," no?? -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 5

How much should I care about allocators?
by Dan Rosen 21 Mar '05

21 Mar '05

Hi all, I'm in the process of putting together my own submission for a boost::tree<>, which has been discussed here on occasion before. Without getting into much detail about the tree itself, I have two nuts-and-bolts questions about conventions using allocators in containers. First: The standard allocator concept has several distinct typedefs: "value_type", "pointer", "reference", etc. My understanding is that the main motivation for allocators was the necessity to abstract out differences in pointer types on different platforms. So I assume this implies that to use an allocator properly, one can't necessarily expect that "pointer" is identical to "value_type*". I hope this assumption is correct so far. What I take this to further imply is that in my container, I need to write code of this nature: template <typename T, typename A = std::allocator<T> > class tree { public: typedef A allocator_type; typedef typename A::value_type value_type; typedef typename A::pointer pointer; typedef typename A::reference reference; // etc. private: class node_t; typedef typename A::template rebind<node_t>::other node_allocator; typedef typename node_allocator::value_type node; typedef typename node_allocator::pointer node_pointer; class node_t { pointer t_; node_pointer parent_; // etc. }; // etc. }; In other words, to respect the allocator I've been given, I need to make sure my internal node structure uses the rebound node allocator's pointer and value types, and so forth. So my first question is, is this assumption correct? The reason I ask is that looking over the standard library implementation that comes with gcc 4.0, I noticed that their implementation of std::list<> has nodes which contain straight pointers, rather than the allocator typedef equivalents. To me that seems to contradict my assumption, assuming the gcc implementation is correct. My second question is about allocator's construct() method. The implementation of std::allocator has construct() invoking the copy ctor using placement new(). That much is self-explanatory. It also seems reasonable to me that allocator does not have construct() methods taking arbitrary parameters. But I'm not sure I understand the reason why it does not have a construct() method to invoke an object's default ctor. What that implies to me, and seems to be supported by gcc's list implementation, is that the nodes in my tree mustn't have a default ctor that actually does anything, because the only way to properly initialize objects using an allocator is through copying. Is that correct? What this boils down to is, using allocators seems to dictate some aspects of how I design and implement this tree (or any container). So how much should I strive to operate within their limitations, and am I understanding these limitations correctly? I hope this is an appropriate forum for these questions. Thanks very much, dr

1 0

[Post review] Pointer Container
by Thorsten Ottosen 20 Mar '05

20 Mar '05

Dear all, The Pointer Container library is very almost finished. Since the review, the following major changes has been made - improved docs with new tutorial and improved browsing - new indirect functions - new Cloneable and Clone Allocator concepts - support for null values - refactored template interface off all classes - implementation guarantees to only instantiate std::container<void*> - rewritten iterators - improved tests The new docs, and code can be downloaded from the files section: http://groups.yahoo.com/group/boost/files/pointer%20container/ptr_container… The test runs with vc7.1 and gcc.3.3.3. Comments, suggestions and portability fixes are welcome. There are one major issue and one minor I need to have resolved during the post-review. Minor issue: allocation in map:operator[] ---------------------------------------- should a default allocated object use operator new or heap_clone_allocator::allocate_default(); ? This happens in ptr_map<string,int> m; m["foo"] = 5; // will allocate an int with new Normally the use can control all allocations because he always add objects manually or via cloninin (which he also controls). But the default object is just allocated with operator new inside ptr_map::operator[]. Should some hook be provided in a new allocator concept, map_heap_allocator? Major issue: ptr_iterator implementation. ----------------------------------------- So what is the problem? Well, since void* is used internally, the iterators must cast to the proper type in operator*; that is no problem for the default indireted iterators; the problem is with the iterators from ptr_iterator ptr_begin(); ptr_iterator ptr_end(); One way to define would be to say typedef internal_container::iterator ptr_iterator; Then the reference type would be void*& and not T*& as we would like. So if the user wanted to sort the container, he would do std::sort( cont.begin(), cont.end(), void_ptr_indirect_fun< std::less<T>, T>() ); This give us a rather insecure interface where you have to cast manually to T* inside the functor. So I wish we could get a T*& reference type. I think, from discussion with David Abrahams, that the current implementation is non-portable even though my test works: typedef T*& reference; reference dereference() const { // void_type is void* or const void* // I'm not sure why this is needed, but it seems to be return reinterpret_cast<reference>( const_cast<void_type&>( *iter_ ) ); } Does anybody knows how to rewrite this crappy code propoerly? I think we're faced with three options 1. keep the current behavior and describe in the docs that it is non-portable 2. go back to making ptr_iterator the default iterator with void*& reference type; 3. add a small subset of algorithms to the classes themselves; I'm thinking that the subset from std::list is appropriate: - sort - remove_if - remove - unique - reverse - merge Let me hear what you think best regards -- Thorsten Ottosen ---------------------------- www.dezide.com www.cs.aau.dk/index2.php?content=Research/bss www.boost.org www.open-std.org/JTC1/SC22/WG21/

2 4