On Tuesday 12 September 2017 08:35 PM, Jeff King wrote:
But theta-well isn't a pun. :P
:)
It is true that prepending to a linked list is also Θ(1), but I'm not
sure if it's carelessness that causes many programmers to use big-O.
It's that what we care about is worst-case performance. So knowi
On Tuesday 12 September 2017 08:59 PM, Jeff King wrote:
Like all good writing rules, I think it's important to know when to
break them. :)
That's right. "Have guidelines but 'Be bold' enough to break them when
they seem to be inducing counter productivity."
Writing in the imperative is _most_
On Tue, Sep 12, 2017 at 07:11:38PM +0530, Kaartic Sivaraam wrote:
> On Tue, 2017-09-05 at 09:05 -0400, Jeff King wrote:
> > This patch introduces an UNLEAK() macro that lets us do so.
> > To understand its design, let's first look at some of the
> > alternatives.
> >
>
> > This patch adds the UN
On Tue, Sep 12, 2017 at 08:04:52PM +0530, Kaartic Sivaraam wrote:
> > On Tue, 2017-09-05 at 15:05 -0700, Stefan Beller wrote:
> >
> > After having a sneak peak at the implementation
> > it is O(1) in runtime for each added element, and the
> > space complexity is O(well).
> >
>
> Incidentally I
> On Tue, 2017-09-05 at 15:05 -0700, Stefan Beller wrote:
>
> After having a sneak peak at the implementation
> it is O(1) in runtime for each added element, and the
> space complexity is O(well).
>
Incidentally I was reading about "complexity of algorithms" and there
was the following paragraph
On Tue, 2017-09-05 at 09:05 -0400, Jeff King wrote:
> This patch introduces an UNLEAK() macro that lets us do so.
> To understand its design, let's first look at some of the
> alternatives.
>
> This patch adds the UNLEAK() macro and enables it
> automatically when Git is compiled with SANITIZE=le
On Thu, Sep 7, 2017 at 2:17 AM, Jeff King wrote:
>> After having a sneak peak at the implementation
>> it is O(1) in runtime for each added element, and the
>> space complexity is O(well).
>
> I'm not sure if your "well" is "this does well" or "well, it could be
> quite a lot". :)
Both actually.
On Tue, Sep 05, 2017 at 03:05:12PM -0700, Stefan Beller wrote:
> On Tue, Sep 5, 2017 at 6:05 AM, Jeff King wrote:
>
> > int main(void)
>
> nit of the day:
> s/void/int argc, char *argv/ or in case we do not
> want to emphasize the argument list s/void//
> as that adds no uninteresting t
On Wed, Sep 06, 2017 at 07:16:00PM +0200, Martin Ågren wrote:
> > diff --git a/builtin/commit.c b/builtin/commit.c
> > index b3b04f5dd3..de775d906c 100644
> > --- a/builtin/commit.c
> > +++ b/builtin/commit.c
> > @@ -1819,5 +1819,6 @@ int cmd_commit(int argc, const char **argv, const
> > char *pr
On 5 September 2017 at 15:05, Jeff King wrote:
> 1. It can be compiled conditionally. There's no need in
> normal runs to do this free(), and it just wastes time.
> By using a macro, we can get the benefit for leak-check
> builds with zero cost for normal builds (this patch
>
On Tue, Sep 5, 2017 at 6:05 AM, Jeff King wrote:
> int main(void)
nit of the day:
s/void/int argc, char *argv/ or in case we do not
want to emphasize the argument list s/void//
as that adds no uninteresting things.
>
> In other words, you can do:
>
> int main(void)
> {
> ch
It's a common pattern in git commands to allocate some
memory that should last for the lifetime of the program and
then not bother to free it, relying on the OS to throw it
away.
This keeps the code simple, and it's fast (we don't waste
time traversing structures or calling free at the end of the
12 matches
Mail list logo
