From: FlSt@gmx.de
I have a few questions about your design:
Why "super position" versus Perl's "junction?" When describing the enumerators, you use the Perl terminology, apparently because it makes sense. Frankly, I don't "get" "super position."
Before it was a built-in feature of Perl, something similar was available as a CPAN module called Quantum::SuperPosition. This naming comes from the quantum physics where elementary particles can have more than one state, called super position. But i think its more evident to call it "junction". (Furthermore "super position" sounds overblown ;-)
I see. I agree that "super position" sounds overblown for this component.
Why is the junction type a template parameter? Did you consider making four separate types? Does using one make it easier to compare instances of the four types? Should the client have to care about that? IOW, I think writing disjunction<T> is simpler and clearer than super_position<ANY, T>. Other name possibilities like "any_of" are possible, too.
I must admit that i don't spend time in tinking about this until now.
That's why we're here! ;-)
The idea behind the diffrent types was, that i don't know how to handle assignments between diffrent junction types.
Should there be assignment among them?
I wrote an explicit constructor for assigning the eigenvalues. But what should the
I saw the use of eigenvalue in the code, but I don't see how it is valid, given what little I know of linear algebra. Anyway, I understand that you're simply referring to the underlying state.
assignment operator copy? Only the values or also the junction type?
I don't see the point of assigning a disjunction to an abjunction, for example. Once can use boost::any or some other scheme to create a variant type when warranted.
Would it be better to store the type as an attribute? An
That isn't needed if there isn't assignment between the four types, right?
another idea i had while writing this template class was, that i write a junction base class and make the is_result_true(...) function virtual and inherit for
That presumes that there is real commonality among these types. As far as I can see, the only thing they have in common are implementation details. IOW, forgetting about construction, destruction, and copying, all that they have in common is being able to participate in comparisions, right? That doesn't provide a good basis for using virtual functions; there's no abstract entity to model.
every junction type. That would fit with your second naming suggestion,
Are you referring to "any_of?"
which i like, because its more conform to the Perl-implementation. I
I think you're referring to "any_of" being similar to Perl's "any," right? I'm not worried about matching Perl's naming conventions so much as choosing what is sensible. Upon reflection, "any_of<T>" doesn't work so well as a type. You could use that as a family of function templates that generate a disjunction<T>: template <typename T> disjunction<T> any_of(T const & v1); template <typename T> disjunction<T> any_of(T const & v1, T const & v2); etc.
aggree that writing super_position<ALL,T> is ugly, not only for the clients ;-). The comparisons between diffrent types is no problem, because the only diffrence between the junction types is the is_result_true() function. Has anyone an idea?
Don't do it! ;-)
Why would one change the Container parameter? Why would the client of this class care about the associative container being used to implement it?
I'm using boost::hash_set<T> in my own applications. And i think there are cases where std::multiset<T> also can make sense. That was the reason for this optional template parameter. For example this is not possible with std::set<T>: http://www.metaperl.com/talks/p6-junctions/slide5.html
You should choose the best container for each of the four types (assuming you agree to four separate types) so that each is as efficient as you can make it. A "one" junction might use std::multiset because you have to allow for multiple elements of the same value so you can see if there is only one. OTOH, you could just count the number of each element upon insertion. Then, comparision means matching the value and then checking the count. Thus, lookup performance is important and you don't need std::multiset for that. "all," "any," and "none" have to check every element (potentially). The O(log N) lookup of an associative container is wasted. A std::vector seems better suited to the task. (The only difference between them would be the condition that could break the iteration.) Unless one needs to be able to ask a junction for more information like how many elements matching a given value it holds or use it in set operations, their implementation should be focused on just answering the one question you can ask of them. Other considerations of these containers is what Concepts their value type must satisfy. Must the values be copyable? Default constructible? These demands impact the range of types that may be used. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;