On 12.10.2010 22:30, Hyrum K. Wright wrote:
> On Tue, Oct 12, 2010 at 2:40 PM, Branko Čibej <brane_at_xbc.nu> wrote:
>> On 12.10.2010 20:35, Hyrum K. Wright wrote:
>>> 1) Return everything by value
>>> Pros: simpler memory management, less overhead (?)
>>> Cons: doesn't allow the return of NULL values, need to establish
>>> conventions to represent NULL objects (an isNull() method?)
>> Meh.
>>
>> inline operator bool() const { return (this->c_struct_pointer != 0); }
> That works great for our own types, but what about stuff like std::string?
>
> inline std::string getAuthor() const { return std::string(ptr->author); }
>
> doesn't go over so well when ptr->author is NULL. If returning by
> value, we *have* to return a string, but there just isn't any way to
> indicate the null string.
Good point ... that's a mess. But returning a pointer to an std::string
is a bigger one ... eep.
So typically you'd add a hasAuthor function and throw an exception from
getAuthor if there is no author info for a revision. However, in this
particular case, returning an empty string is just as good, unless you
want to make the fine distinction between a svn:author property with an
empty value (is that even allowed?) and no svn:author property on the
revision. This is no different than if you had a getProperty(name) and
did a lookup in a private map of property name/value pairs.
I'm afraid it's not going to be easy to be consistent, but I'd strive to
follow (1) wherever it's reasonable.
-- Brane
Received on 2010-10-13 00:07:16 CEST