BIND 10 #2206: define and implement ZoneTableSegment class
BIND 10 Development
do-not-reply at isc.org
Tue Oct 2 18:11:05 UTC 2012
#2206: define and implement ZoneTableSegment class
-------------------------------------+-------------------------------------
Reporter: | Owner: UnAssigned
jinmei | Status: reviewing
Type: task | Milestone:
Priority: | Sprint-20121009
medium | Resolution:
Component: data | Sensitive: 0
source | Sub-Project: DNS
Keywords: | Estimated Difficulty: 6
Defect Severity: N/A | Total Hours: 0
Feature Depending on Ticket: |
background zone loading |
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Comment (by jinmei):
'''zone_table_segment.h'''
- brief descriptions are mostly meaningless:
{{{#!cpp
/// \brief Zone Table Header Class
struct ZoneTableHeader {
}}}
It's too obvious that this is a "Zone Table Header" class (or
struct) from the type name. I'd give some more informative one-line
summary of what this class is. I'd also provide some longer version
of description to this particular class. Some points also apply to
other classes.
- the return value description is mostly redundant:
{{{#!cpp
/// Returns the MemorySegment used in this zone table segment.
///
/// \return Returns a ZoneTableHeader for this zone table segment.
}}}
I'd either provide more meaningful description or if there really
isn't any just skipping the detailed version of the description.
- `ZoneTableHeader`: maybe it's better to provide an accessor to
table rather than having the caller be aware of offset_ptr (which is
a kind of details that the caller doesn't have to care about):
{{{#!cpp
struct ZoneTableHeader {
public:
ZoneTable* getTable() { return (table.get()); }
// maybe we need a const version too?
private:
boost::interprocess::offset_ptr<ZoneTable> table;
};
}}}
- getHeader() should never return NULL. I'd note that (or maybe we
should return a reference instead of a pointer? I'm not sure which
one is better).
- I'd note that the object returned by create() is dynamically
allocated and the caller is responsible for deleting. (providing a
corresponding `destroy()` method maybe cleaner).
- maybe a matter of taste in practice, I'd explicitly define the
constructor of the base class as private to make it clear that the
factory must be used to instantiate it.
- not fully sure about this right now, but we probably want to have a
const version of `getHeader()`. The lookup code path should only
need read-only access to the table.
'''zone_table_segment_local'''
- getHeader() and getMemorySegment(): for such very simple methods we
might just define them in the header file. It's purely a taste
matter though, as they are virtual methods.
'''zone_table_segment_unittest'''
- (general) scoped_ptr would be a slightly better choice than auto_ptr
for such usage.
- `config` is generated in every test. You can avoid by introducing a
fixture. The total amount of code length wouldn't be much different
though.
--
Ticket URL: <http://bind10.isc.org/ticket/2206#comment:7>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list