All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremiah Mahler <jmmahler@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v3 1/2] add strbuf_set operations
Date: Thu, 12 Jun 2014 12:31:44 -0700	[thread overview]
Message-ID: <20140612193144.GA17077@hudson.localdomain> (raw)
In-Reply-To: <xmqqr42u55dq.fsf@gitster.dls.corp.google.com>

Junio,

Comments below...

On Thu, Jun 12, 2014 at 11:50:41AM -0700, Junio C Hamano wrote:
> Jeremiah Mahler <jmmahler@gmail.com> writes:
> 
> > A common use case with strubfs is to set the buffer to a new value.
> > This must be done in two steps: a reset followed by an add.
> >
> >   strbuf_reset(buf);
> >   strbuf_add(buf, new_buf, len);
> >
> > In cases where the buffer is being built up in steps, these operations
> > make sense and correctly convey what is being performed.
> >
> >   strbuf_reset(buf);
> >   strbuf_add(buf, data1, len1);
> >   strbuf_add(buf, data2, len2);
> >   strbuf_add(buf, data3, len3);
> >
> > However, in other cases, it can be confusing and is not very concise.
> >
> >   strbuf_reset(buf);
> >   strbuf_add(buf, default, len1);
> >
> >   if (cond1) {
> >     strbuf_reset(buf);
> >     strbuf_add(buf, data2, len2);
> >   }
> >
> >   if (cond2) {
> >     strbuf_reset(buf);
> >     strbuf_add(buf, data3, len3);
> >   }
> >
> > Add strbuf_set operations so that it can be re-written in a clear and
> > concise way.
> >
> >   strbuf_set(buf, default len1);
> >
> >   if (cond1) {
> >     strbuf_set(buf, data2, len2);
> >   }
> >
> >   if (cond2) {
> >     strbuf_set(buf, data3, len3);
> >   }
> 
> Or even more concisely without making unnecessary internal calls to
> strbuf_reset():
> 
> 	strbuf_reset(buf);
>         if (cond2)
>         	strbuf_add(buf, data3, len3);
> 	else if (cond1)
>         	strbuf_add(buf, data2, len2);
> 	else
>         	strbuf_add(buf, default, len2);
> 
> ;-)

_add would work in your example.  strbuf_set would also work and it
would perform the same number of operations (one set and one add).

However your example is different from mine in which cond1 and cond2 are
not necessarily mutually exclusive.

> 
> I am on the fence.
> 
> I have this suspicion that the addition of strbuf_set() would *only*
> help when the original written with reset-and-then-add sequence was
> suboptimal to begin with, and it helps *only* how the code reads,
> without correcting the fact that it is still doing unnecessary
> "first set to a value to be discarded and then reset to set the
> right value", sweeping the issue under the rug.
> 
It is certainly possible that builtin/remote.c (PATCH 2/2) saw the most
benefit from this operation because it is so badly designed.  But this
seems unlikely given the review process around here ;-)

The one case where it would be doing extra work is when a strbuf_set
replaces a strbuf_add that didn't previously have a strbuf_reset.
strbuf_set is not appropriate for all cases, as I mentioned in the
patch, but in some cases I think it makes it more readable.  And in this
case it would be doing a reset on an empty strbuf.  Is avoiding this
expense worth the reduction in readability?

Also, as Eric Sunshine pointed out, being able to easily re-order
operations can make the code easier to maintain.

> Repeated reset-and-then-add on the same strbuf used to be something
> that may indicate that the code is doing unnecessary work.  Now,
> repeated uses of strbuf_set on the same strbuf replaced that pattern
> to be watched for to spot wasteful code paths.
> 
If a reset followed by and add was a rare occurrence I would tend to
agree more.

> I dunno...
> 
> > Signed-off-by: Jeremiah Mahler <jmmahler@gmail.com>
> > ---
> >  Documentation/technical/api-strbuf.txt | 18 ++++++++++++++++++
> >  strbuf.c                               | 21 +++++++++++++++++++++
> >  strbuf.h                               | 13 +++++++++++++
> >  3 files changed, 52 insertions(+)
> >
> > diff --git a/Documentation/technical/api-strbuf.txt b/Documentation/technical/api-strbuf.txt
> > index f9c06a7..ae9c9cc 100644
> > --- a/Documentation/technical/api-strbuf.txt
> > +++ b/Documentation/technical/api-strbuf.txt
> > @@ -149,6 +149,24 @@ Functions
> >  	than zero if the first buffer is found, respectively, to be less than,
> >  	to match, or be greater than the second buffer.
> >  /*----- add data in your buffer -----*/
...
> >  static inline void strbuf_addch(struct strbuf *sb, int c)
> >  {

-- 
Jeremiah Mahler
jmmahler@gmail.com
http://github.com/jmahler

  reply	other threads:[~2014-06-12 19:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-12  7:29 [PATCH v3 0/2] add strbuf_set operations Jeremiah Mahler
2014-06-12  7:29 ` [PATCH v3 1/2] " Jeremiah Mahler
2014-06-12  8:11   ` Thomas Braun
2014-06-12  8:22     ` Jeremiah Mahler
2014-06-12 18:51       ` Junio C Hamano
2014-06-12 19:36         ` Jeremiah Mahler
2014-06-12 21:18           ` Eric Sunshine
2014-06-12 23:14             ` Jeremiah Mahler
2014-06-12 18:50   ` Junio C Hamano
2014-06-12 19:31     ` Jeremiah Mahler [this message]
2014-06-12 21:48       ` Eric Sunshine
2014-06-12 23:46         ` Jeremiah Mahler
2014-06-13  7:15           ` Jeff King
2014-06-14  4:49             ` Jeremiah Mahler
2014-06-12  7:29 ` [PATCH v3 2/2] builtin/remote: improve readability via strbuf_set() Jeremiah Mahler
2014-06-12  8:19   ` Eric Sunshine

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=20140612193144.GA17077@hudson.localdomain \
    --to=jmmahler@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.