Branko Čibej <brane@xbc.nu> writes:
> Oh, well. I dislike creating stuff in the user's home in lieu of
> documentation ... -0
Mrm. Okay. Separate discussion, but I'll point out that we've done
basically the same thing in the FS, for a long time now.
> >The benefit is not having to clutter other code with stringbufs. APIs
> >that demand stringbufs when null-terminated strings would do just as
> >well place a burden on their callers. That's why we've been getting
> >rid of stringbufs all over the place lately.
> >
> Um. They weren't stringbufs, they were string_t's. There's a
> difference -- no allocations, for one thing.
And that's the only thing. :-) My comment about the burden on the
callers still applies.
> >Is there some reason we need the length of the string? It's not
> >binary data, after all.
> >
> The *user* of the code may need it, to avoid strlens. I thought that's
> what svn_string_t was for.
>
> Sure, kill the stringbufs where they're not needed, but string_t's are
> useful, imho, and quite as easy to use as plain pointers.
The purposes of svn_string_t are also to give counted-length binary
data. Config data is always null-terminated. Anyway, this change is
entirely consistent with the API decisions/changes we've been making
for months now, losing counted-length strings in favor of C strings.
When do the callers need to do strlen(), realistically? Mostly they
do string comparisons and pattern matching. If they do need the
length, they can take strlen(), but so far it hardly ever happens.
I do not find svn_string_t as easy to use as plain pointers. I have
to set them up, and then end up dereferencing the data field anyway
for all those functions that take "const char *". Ugh. (I mean, I
changed the API because it *was* hampering me, not because I thought
it might do so at some future date.)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 20 04:34:43 2002