Subject: Re: [boost] [Review] ITL review starts today, February 18th
From: Barend Gehrels (barend_at_[hidden])
Date: 2010-02-26 17:27:27
Hi Joachim,
This is not yet the review.
I'm about halfway and I'm enthousiastic. I've done two small projects
inspired on my needs and all I tried is working good, it definitely is a
useful library.
Questions /remarks though.
1) The set union is modelled as += (doc: "So interval_sets define an
operator += that is naturally implemented as set union and an operator
-= that is consequently implemented as set difference"), set
intersection as &= (according to the doc definition and man_power sample).
However, a union is more or less like an OR operation, an intersection
like and AND operation, so I would have expected that union would be |=.
According to the manual, in another place, that is also supported.
Boost.Polygon(BP)/GTL also supports both, for union. Is it intentional
that two operators are implemented for the same operation in these two
libraries? And if so, why is that not done for the intersection (having
synonym *= in BP).
Boost.dynamic_bitset also implement all of these:
dynamic_bitset& operator&=(const dynamic_bitset& b); Bitwise-AND ...
dynamic_bitset& operator|=(const dynamic_bitset& b); Bitwise-OR's...
dynamic_bitset& operator^=(const dynamic_bitset& b); Bitwise-XOR's...
dynamic_bitset& operator-=(const dynamic_bitset& b); Computes the set
difference of this bitset...
Boost.Geometry does not (yet) implement operators so we look in a way to
conform, if possible, and would like to avoid to introduce synonyms. So
I would advocate, for (at least) the four libraries
Boost.dynamic_bitset, Boost.Polygon, Boost.Geometry and ITL, the usage
of operators conform dynamic bitset, so the following:
&= for intersection
|= for union
^= for symmetric difference (as is done in both ITL and BP)
-= for difference (as is done in both ITL and BP)
2) Same scope, the "boolean" functions "is_disjoint", "contained_in", we
in Boost.Geometry have named them (according to ISO/OGC) as "disjoint"
and "within". The following functions match: "intersects", "contains"
and "touches". And, besides that, ISO/OGC also describe "equals",
"overlaps" (where overlaps is roughly intersects, but not completely
within, and not touches).
So actually we're nearly there, there are just some small differences in
names/synonyms.
Do you find it a good idea to have / create a common picture of
operators and functions and if yes, is it still possible to adapt?
Regards, Barend