From: "Jeff Flinn" <TriumphSprint2000@hotmail.com>
"Rob Stewart" <stewart@sig.com> wrote in message news:200507251959.j6PJx7Qe022151@weezy.balstatdev.susq.com...
So rather than creating new(as far as C++ is concerned) terminology, I'd find general expansion of set manipulating functionality more useful.
There are many things that one can do with more fundamental components. The question is whether those things can be expressed better using a new component (where better can be interpreted variously). [snip] A junctions component also seems worthwhile because it raises one's awareness of the functionality and its possible application. By contrast, one isn't likely to think of "junction" when looking for a solution to a problem. Thus, adding the functionality to std::set, for example, is likely to put the functionality in a known component, increasing the chances one will see the functionality as a solution.
I associate Junction with the result of joining/connecting, such as already used by boost::thread and boost::signal.
OK. I wasn't married to "junction," but the "ab," "dis," etc. prefixes were helpful to distinguish among the behaviors. However, "any," "all," "none," and "one" are even more meaningful.
I wasn't necessarily advocating expansion of std::set, but rather that the described functionality/behavior was more akin to the mathematical concept of a set. std::set carries additional baggage, notably the ordering, which is not always necessary. This conceptual_set may not even possess any internal storage at all. For example the set of odd numbers could be defined
I see.
just as a function: bool ismember_odd_set( int n ){ return n % 2; }. Also as Darren Cooke mentioned in another post to this thread, ranges would be convenient, and is encompassed by the preceding concept. The key operations are defining sets, and comparing sets.
The Defining operations would include: [snip] various set operations To avoid the unnecessary construction of temporaries when merely checking for emptiness, lazy evaluation could be used, ala phoenix/fusion.
Yes, you'd want compile-time set operations where possible. Let's compare notation. Given a set of values usable by the "any," "all," "none," and "one" types named s, a conceptual_set named c, and a test value named x: "junctions" | conceptual_set -------------|----------------------- x == any(s) | c.count(x) > 1 x == all(s) | c.count(x) == c.size() x == none(s) | c.count(x) == 0 x == one(s) | c.count(x) == 1 (I'm assuming that conceptual_set will provide count(), of course. Note that conceptual_set will probably include contains(), so "any" could be written as c.contains(x).) The junctions notation is shorter and clearer. One can envision layering the junctions notation over conceptual_set. (The expositional implementation I've shown above is inefficient: conceptual_set::count() can't know when you have enough information to arrive at the answer. For "any" and "one," you can stop as soon as count > 1. For "none," you can stop as soon as count == 1. For "all," you can stop as soon as an element doesn't match. You'd either have to make those operations be part of the conceptual_set interface, or you'd have to implement them via iteration.) Implementation details aside, junctions--or whatever you want to call them--seem like a good idea. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;