[bind10-dev] easy part for handle non-empty node

JINMEI Tatuya / 神明達哉 jinmei at isc.org
Sat Jan 22 00:36:37 UTC 2011


At Sat, 22 Jan 2011 08:16:33 +0800,
"=?gb2312?B?uqu34w==?=" <hanfeng at cnnic.cn> wrote:

> > > Another suggestion: Have the bool as a parameter of the find function (either
> > > template or non-template with default).
> > 
> > This is actually what BIND 9 (essentially) does, and so it would make
> > most sense as what we are basically doing is a relatively
> > straightforward port of the BIND 9 version.
> 
> I have two concern with the bool as another (template) parameter for find:
> 
> The find interface now isn't that slim later we also needs to return node chain 
> which will make it hard to use or maintain.
> In BIND9, a lot of functions will carry a list of parameters, 
> maybe the developer know all the parameters quit clearly, 
> but when i read the code, it's cause a lot problem to me.
> find has template version, and in some place we have this kind of invocation.
> find<void *>(...), because we have to give compiler some hint to instant the
> template function
> when we don't have callback.
> if we add another bool, it will become find<void *, true/false>(...);
> this kind of code make me uncomfortable.

Whether particular code is readable is often a matter of subjective
opinion, but I agree that adding a parameter to find() is suboptimal
in that we are considering it as a class property.

> One rbtree instance will has the same find policy, so the find policy
> is class/instance level not interface level, for one rbtree instance either needs
> empty node or do not.  

In this sense, the problem of your proposal of enable/disable
functions is that we could dynamically change the policy, which
shouldn't be an expected operation.  If we agree on ignoring
(possible) run time performance penalty of find(), and if we don't
want to make sure it's a persistent instance attribute, I'd suggest
setting this property on construction in some way.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.



More information about the bind10-dev mailing list