- 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: <d1p2mg$mfk$1(a)sea.gmane.org> nesotto(a)cs.auc.dk (Thorsten Ottosen) wrote (abridged): > There is a small utility in the Pointer Container library which is more > general that hash_ptr ect. You can simply say > > unordered_set< MyType*, indirect_fun< boost::hash<MyType> >, > > indirect_fun< std::equal<MyType set; > > for the rare cases where the index is a pointer. OK. It might be worth mentioning in the documentation. -- Dave Harris, Nottingham, UK

1 0

[Boost-bugs] [ boost-Bugs-1168431 ] LEDA graph adaptors do not handle hidden nodes properly
by SourceForge.net 22 Mar '05

22 Mar '05

Bugs item #1168431, was opened at 2005-03-22 10:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1168431&group_… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: LEDA graph adaptors do not handle hidden nodes properly Initial Comment: Hidden nodes are completely ignored by the LEDA graph adaptors. This may cause problems when, for instance, there are hidden nodes but the equivalent of vertex_index is used to construct a (BGL) property map. The LEDA adaptors should probably take the same approach as filtered_graph: let num_vertices() return the number of the nodes in the graph plus the number of hidden nodes, but vertices() filters out the hidden nodes. Similarly for edges. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1168431&group_… ------------------------------------------------------- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-1168424 ] LEDA adaptors for node_array, edge_array
by SourceForge.net 22 Mar '05

22 Mar '05

Bugs item #1168424, was opened at 2005-03-22 10:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1168424&group_… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: LEDA adaptors for node_array, edge_array Initial Comment: LEDA has constructs similar to property maps, called node_array and edge_array, that allow the user to create external mappings from vertices or edges to user-defined data. Both classes are templated over the data type T. The BGL LEDA adaptors should provide a wrapper for these data structures to make them into property maps, so that LEDA graphs and LEDA's form of external property maps can be used with BGL algorithms. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1168424&group_… ------------------------------------------------------- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-1168420 ] LEDA graph adaptors for undirected graphs
by SourceForge.net 22 Mar '05

22 Mar '05

Bugs item #1168420, was opened at 2005-03-22 10:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1168420&group_… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: LEDA graph adaptors for undirected graphs Initial Comment: The LEDA graph adaptors in the BGL seem to work properly for directed graphs (the LEDA type GRAPH<...>), but there are no corresponding adaptors for the undirected LEDA graph type (UGRAPH<...>). Undirected LEDA graphs follow a very different model than the undirected graphs in the BGL, which will require some special machinery. The LEDA type UGRAPH<...> is actually just a class derived from GRAPH<...> that applies the "make_undirected()" member function upon initialization. make_undirected() moves all of the in-edges of each vertex to the out-edges list. This has several unfortunate consequences: 1) The in-degree of an undirected LEDA graph is always zero, even when the out-degree is greater than zero. The in_edges list is therefore empty. 2) When traversing the list of out-edges for a vertex u, the edges returned may have u as their target but not their source. This breaks an important invariant in the BGL, which mandates that source(e, g)==u if e came from out_edges(u, g). Similarly for in-edges. Thus, an undirected LEDA graph adaptor will need to introduce special adaptors for the out_edge_iterator and in_edge_iterator types, which return a new edge_descriptor type for LEDA that can swap the source and target of a LEDA edge as needed. Additionally, graph-mutating operations (such as add_edge) may need to ensure that the graph remains undirected, as if make_undirected() had been called. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1168420&group_… ------------------------------------------------------- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-1168411 ] adjacency_matrix should model BidirectionalGraph
by SourceForge.net 22 Mar '05

22 Mar '05

Bugs item #1168411, was opened at 2005-03-22 10:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1168411&group_… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: adjacency_matrix should model BidirectionalGraph Initial Comment: Class template adjacency_matrix should model the BidirectionalGraph concept. This will require the introduction of an in_edge_iterator that strides across the rows of the adjacency matrix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1168411&group_… ------------------------------------------------------- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

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