[bind10-dev] Name::reverse()?
Evan Hunt
each at isc.org
Fri Feb 19 17:25:42 UTC 2010
> - I'd use string::append instead of string::insert, and overall
> simplify the loop logic
> - I'd build the reverse offset vector directly from the original
> offsets using transform(). It should also help simplify the code
> logic (by eliminating the boundary case consideration for
> offsets_[0])
Fantastic. I tried to figure out transform() and failed, so I came
up with this solution instead--if there's a smarter way, let's do that.
... I like your double-iterator approach. However, wouldn't this work
equally well, without the transform()?
// Copy the original name, label by label, from tail to head.
vector<unsigned char>::const_reverse_iterator rit0 = offsets_.rbegin();
vector<unsigned char>::const_reverse_iterator rit1 = rit0 + 1;
string::const_iterator n0 = ndata_.begin();
while (rit1 != offsets_.rend()) {
retname.ndata_.append(n0 + *rit1, n0 + *rit0);
+ retname.offsets_.push_back(retname.ndata_.size());
++rit0;
++rit1;
}
retname.ndata_.push_back(0);
> Currently, (AFAICS) the only usage of this method is the following
> line of data_source_sqlite3.cc:
>
> const char *c_rname = qname.reverse().toText().c_str();
>
> This seems to me a very special case.
This won't be the only use of this function, it's just the first.
For one thing, since the SQL schema for zone records includes a reversed
name, we'll need to be able to create those names when inserting into the
SQL data source. Right now I'm doing that in python (which includes a
generic reverse() function) but DDNS and probably *XFR will require C++ to
be able to do the same thing.
Also, since the database is indexed by the reversed-name field, I expect
there would probably a small speedup for large zones if we reversed the
name before doing the database query. That's a minor point at this stage
of development, though.
For those things, during the prototype phase, there are other ways to
proceed. But I need findPreviousName() for NSEC support; therefore
a reverse() function has now become essential.
As to whether it belongs in the Name class... I could code one using the
existing Name API; it's easy enough to do with split() and concatenate().
But that requires multiple copies and transformations per label. A
dedicated reverse() function that acts directly on the underlying
Name data is a single copy.
So I believe it does belong in the Name class, or at least in a derived
class that has full access to the Name data. And I don't really see any
advantage to having a class ReversibleName, as opposed to one extra method
in Name.
eh
More information about the bind10-dev
mailing list