Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
A Flexible Interface
It's common to use "camelCase" in C++ (though some prefer "underscored_names"). I urge you to be consistent, whichever you choose. An interesting alternative, though, would be to use a full set of each; the method delete_entry could internally call deleteEntry, and your users could pick whichever interface they liked.
For that matter, a little careful redundancy can improve an interface. (Many will disagree with me on this point.) For example, there is no reason why the methods concat and append and the operator << might not all do the same thing internally.
A colleague of mine took exception to my comments on careful redundancy, saying that it was a management nightmare for very little reward. Feel free to agree with him. But I will justify my comments by saying that the interface to a class is very important, and different people have different coding styles. Toss the user a bone—allow coding in whatever style the rest of the project uses.
In fact, you could even allow multiple styles of accessors and mutators in this way:
int value(void) const { return _value; }
int value(int v) { return (_value = v); }
// "Aliases"
int getValue(void) const { return _value; }
int setValue(int v) { return (_value = v; }
int get_value(void) { return _value; }
int set_value(int v) { return (_value = v); }
I stand by my assertion that it's worthwhile to provide a rich and flexible interface. But to avoid the "management nightmare," be sure to document the code to show where such aliases are used. For simplicity, let the aliases call the "canonical" versions of the methods (unless, as here, the code is trivial).