From: Junio C Hamano <gitster@pobox.com>
To: Christian Couder <chriscool@tuxfamily.org>
Cc: Nanako Shiraishi <nanako3@lavabit.com>,
git@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
John Tapsell <johnflux@gmail.com>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Pierre Habouzit <madcoder@debian.org>
Subject: Re: [PATCH 1/7] strbuf: add "include_delim" parameter to "strbuf_split"
Date: Fri, 13 Mar 2009 00:06:02 -0700 [thread overview]
Message-ID: <7v7i2tj411.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <200903130702.01039.chriscool@tuxfamily.org> (Christian Couder's message of "Fri, 13 Mar 2009 07:02:00 +0100")
Christian Couder <chriscool@tuxfamily.org> writes:
>> Also comparing this with Perl/Python split() forgets that you are working
>> in C, where truncating an existing string is quite cheap (just assign
>> '\0'). There is a different trade-off to be made in these language
>> environments.
>
> Sorry but I think the goal of the strbuf API is to be quite high level, so I
> think comparing this with Perl/Python is ok.
I think you are mistaken again.
The highlevel-ness of strbuf holds true only while you live in the strbuf
world, but you should consider what happens when its end product finally
gets used in the calling function written in C. It will be a good-old NUL
terminated string or just a chunk of memory with known length.
For a user written in C, it is far easier and cheaper to trim excess at
the end, especially when the length of the string is known (strbuf_detach
gives you the length of the string exactly for this reason) than having to
extend it (in order to recover the lost delimiter because the splitter
removed it). Trimming from the front is also cheap (just move the head
pointer and start consuming from the middle).
prev parent reply other threads:[~2009-03-13 7:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-12 7:51 [PATCH 1/7] strbuf: add "include_delim" parameter to "strbuf_split" Christian Couder
[not found] ` <20090312190846.6117@nanako3.lavabit.com>
2009-03-13 4:48 ` Christian Couder
2009-03-13 5:17 ` Junio C Hamano
2009-03-13 6:02 ` Christian Couder
2009-03-13 6:53 ` Junio C Hamano
2009-03-14 7:46 ` Migrate bisect to C (was: [PATCH 1/7] strbuf: add "include_delim" parameter to "strbuf_split") Christian Couder
2009-03-14 8:16 ` Migrate bisect to C Junio C Hamano
2009-03-14 12:09 ` fetch--tool, was " Johannes Schindelin
2009-03-13 7:06 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7v7i2tj411.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=johnflux@gmail.com \
--cc=madcoder@debian.org \
--cc=mingo@elte.hu \
--cc=nanako3@lavabit.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).