headers
Dietmar Kuehl | 1 Feb 2001 03:07
Picon
Favicon

Re: Koenig lookup, names in std:: - Summary

Matthew Austern wrote:

> I don't really see this as more than half a solution, because standard
> library implementors can't use it without a whole lot of changes in the
> library portions of the C++ standard.  You certainly couldn't use
> swap_t when writing std::sort(), or abs_t when writing std::valarray().

Why would an algorithm want to use 'swap_t'? 'swap_t' is only used for
two purposes:
- To implement 'swap()'.
- To allow users partial specialization of 'swap()', although somewhat
  indirectly.

Of course, a library implementation conforming to the current standard
would call 'swap_t' something like '_Swap_t' to stay in the correct
namespace but other than that I don't see any reason not to use 'swap_t'
for the implementation of 'swap()' and documenting this fact: It would be
a conforming extension to allow users [partial] specialization of '_Swap_t'.
If this approach is mandated by the next revision of the standard, the
names would change but this should not be a problem because the next
standard will [hopefully] allow template typedef's, too :-)
Permalink | Reply | 0 comments |
headers
rwgk | 1 Feb 2001 04:32

rational.hpp operator< bug

The current version of rational.hpp has a problem with a comparison
like this:

  0 < -1/2

The result is "true."

Here is my idea of a fix:

RCS file: /cvsroot/boost/boost/boost/rational.hpp,v
retrieving revision 1.4
diff -r1.4 rational.hpp
48a49
>     if (n < 0) return -n;
56a58
>     if (n < 0) return -n;

This is, the functions gcd and lcm are modified such that they always
return a positive number.

Ralf
Permalink | Reply | 1 comment |
headers
John (EBo) David | 1 Feb 2001 04:42
Picon

Re: Draft of Test Policy web page


I've been out of things for awhile, but...

> Although numerics pose special problems, there are lots of other tests
> which are easy and reasonable to configure as "expect this output".
>
> I'm sure that will be one of the next steps in the evolution of testing
> Boost libraries, but we have to walk before we run. 

Possibly a couple of other test types we could consider:

  "expect value less than"
  "expect value greater than"
  "expect value in range"

> For now, I'm excited
> that we are making so much progress with testing, and am not worrying about
> whether the glass is half empty or half full.

Me to!

  EBo --
Permalink | Reply | 4 comments |
headers
hankel_o_fung | 1 Feb 2001 13:05
Picon
Favicon

BGL: what constitutes an undirected graph?

Hi folks,

What constitutes an undirected graph? In graph_theory_review.html,
it says:

 "In an undirected graph ... (u,v) and (v,u) are two ways of
  writing the same edge.

 "In an undirected graph edge (u,v) is incident on vertices u and v."

In graph_concepts.html :
 "When using undirected graphs just mentally disregard the
  directionality in the function names ...

 "If the undirected graph is a multigraph then (u,v) and (v,u)
  might be parallel edges. If the graph is not a multigraph then
  (u,v) and (v,u) must be the same edge."

In using_graph_algorithms.html :

And in Graph.html, it reads
 "boost::graph_traits<G>::edge_descriptor
  An edge descriptor corresponds to a unique edge (u,v) in a graph.
  An edge descriptor must be DefaultConstructible, Assignable, and
  EqualityComparable."

However, the meanings of e1==e2, source(e,g) and target(e,g) are
ambiguous when e1, e2 are edge descriptors and g is undirected,
even if g is not a multigraph:
(Continue reading)

Permalink | Reply | 4 comments |
headers
Beman Dawes | 1 Feb 2001 16:09
Picon
Favicon
Gravatar

Re: Re: Draft of Test Policy web page

At 08:42 PM 1/31/2001 -0700, John (EBo) David wrote:

 >Possibly a couple of other test types we could consider:
 >
 >  "expect value less than"
 >  "expect value greater than"
 >  "expect value in range"

The challenge is to produce a pretty-good-expect that is easily portable, 
no dependencies on anything except the standard library, small (a few 
hundred lines of code, maximum), and very easy to configure.  In other 
words, trouble-free for the boost developers who are the users.

A simple file comparison program would often meet those needs, but wouldn't 
do for "expect value less than" etc.

Maybe someone familiar with dejagnu could comment.  Is there a subset that 
would suit boost's needs?

--Beman
Permalink | Reply | 3 comments |
headers
Jeremy Siek | 1 Feb 2001 16:49
Picon

Re: Re: Draft of Test Policy web page


One addition I'd like to see to the regression testing is a separate
detailed status page for each of the larger libraries, and especially for
the libraries where much of the functionality works for a given compiler,
but a few things typically do not work (like type traits). The detailed
status page would basically show the results of each unit test (or perhaps
groups of closely related unit tests). I think this should be fairly
straighforward to do now that we have a fairly flexible regression.cpp.
I'll look into putting together a detailed status page for the graph
library.

Cheers,
Jeremy

----------------------------------------------------------------------
 Jeremy Siek                        www: http://www.lsc.nd.edu/~jsiek/
 Ph.D. Candidate                  email: jsiek <at> lsc.nd.edu
 Univ. of Notre Dame         work phone: (219) 631-3906
----------------------------------------------------------------------
Permalink | Reply | 2 comments |
headers
Jeremy Siek | 1 Feb 2001 18:45
Picon

Re: BGL: what constitutes an undirected graph?

Hi Hankel,

On Thu, 1 Feb 2001 hankel_o_fung <at> yahoo.com wrote:
hankel> 
hankel> However, the meanings of e1==e2, source(e,g) and target(e,g) are
hankel> ambiguous when e1, e2 are edge descriptors and g is undirected,
hankel> even if g is not a multigraph:
hankel> 
hankel>   tie(e1,found) = edge(u, v, g);
hankel>   tie(e2,found) = edge(v, u, g);
hankel>   cout << source(e1,g) == source(e2,g) << endl;
hankel>   cout << target(e1,g) == target(e2,g) << endl;
hankel> 
hankel> Currently, the BGL interface does not require both comparisons
hankel> to return true/false. If we view logical equality as an indication
hankel> of identical observable behaviours, then both equalities above
hankel> should return true. If we want to traverse all vertices on a path
hankel> delimited by two edge iterators, we may want "source" and "target"
hankel> to depend on the direction we traverse (this seems to be the case
hankel> in the current implementation of adjacency_list).

I'm not exactly sure as to your point: are you saying that the BGL
definition and/or implementation of undirected edges is inconsistent, or
are you asking for a change in the definition? In the various docs that
you quoted, I don't see an inconsistency... if you disagree could you
point it out more explicitly.

The definition of of equality for an undirected edge is that if e1 = (u,v)
and e2 = (v,u) then e1 = e2. Now, the source and target functions merely
return the first and second vertex of the pair respectively, so in this
(Continue reading)

Permalink | Reply | 3 comments |
headers
Beman Dawes | 1 Feb 2001 19:05
Picon
Favicon
Gravatar

Re: Re: Draft of Test Policy web page

At 10:49 AM 2/1/2001 -0500, Jeremy Siek wrote:

 >One addition I'd like to see to the regression testing is a separate
 >detailed status page for each of the larger libraries, and especially for
 >the libraries where much of the functionality works for a given compiler,
 >but a few things typically do not work (like type traits). The detailed
 >status page would basically show the results of each unit test (or 
perhaps
 >groups of closely related unit tests). I think this should be fairly
 >straighforward to do now that we have a fairly flexible regression.cpp.
 >I'll look into putting together a detailed status page for the graph
 >library.

AFAIK, you have the tools now to do that.  Go ahead and try, and let us 
know if you run into problems.

--Beman
Permalink | Reply | 0 comments |
headers
Jens Maurer | 1 Feb 2001 19:30
Picon

Re: Re: Regexp++ 3.03: where is the type.hpp header file?

Paul Selormey wrote:.
> If possible, please give the regex_grep an optional argument
> which could be passed to the static callback procedure.
> This way it will be very simple to use the callback as static method
> of classes and let it access methods/members by passing in the "this"
> pointer as in multithreaded callbacks.

Without looking at code nor documentation, it seems that you
want to use std::mem_fun  and std::bind1st to achieve
"callback with this parameter".

Otherwise, just define a function object.

Jens Maurer
Permalink | Reply | 0 comments |
headers
Jeremy Siek | 1 Feb 2001 20:46
Picon

Re: BGL: what constitutes an undirected graph?


I'm guessing, but perhaps you are looking for some kind of guarantee
like the following for undirected graphs:

for (tie(ui, ui_end) = out_edges(u, g); ui != ui_end; ++ui)
  assert(source(*ui, g) == u);

This certainly should be made explicit. I know most of the BGL graph
algorithms assume the above to be true for both directed and undirected
graphs.

Cheers,
Jeremy

On Thu, 1 Feb 2001, Jeremy Siek wrote:

jsiek> Hi Hankel,
jsiek> 
jsiek> On Thu, 1 Feb 2001 hankel_o_fung <at> yahoo.com wrote:
jsiek> hankel> 
jsiek> hankel> However, the meanings of e1==e2, source(e,g) and target(e,g) are
jsiek> hankel> ambiguous when e1, e2 are edge descriptors and g is undirected,
jsiek> hankel> even if g is not a multigraph:
jsiek> hankel> 
jsiek> hankel>   tie(e1,found) = edge(u, v, g);
jsiek> hankel>   tie(e2,found) = edge(v, u, g);
jsiek> hankel>   cout << source(e1,g) == source(e2,g) << endl;
jsiek> hankel>   cout << target(e1,g) == target(e2,g) << endl;
jsiek> hankel> 
jsiek> hankel> Currently, the BGL interface does not require both comparisons
(Continue reading)

Permalink | Reply | 2 comments |

Gmane