monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Re: [PATCH] monotone ls authors


From: Bruce Stephens
Subject: [Monotone-devel] Re: [PATCH] monotone ls authors
Date: Thu, 15 Dec 2005 20:04:03 +0000
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

"Steven E. Harris" <address@hidden> writes:

> Nathaniel Smith <address@hidden> writes:
>
>> It's completely against the idiom,
>
> What idiom? It's idiomatic in our house style here.

Well, I copied the whole function from ls_tags, so I'd guess it's
idiomatic in monotone, which is probably the important question.

However, I think it's idiomatic in C++ generally, isn't it?  For
example, 
<http://www.oreillynet.com/pub/a/network/2005/10/18/what-is-iterator-in-c-plus-plus.html?page=2>
 shows:

    vector<int> v;
    // fill up v with data...
    for (vector<int>::iterator it = v.begin();
         it != v.end(); ++it) {
         cout << *it << endl;
    }

[...]

>> and does _not_ improve performance.  (end() is inlined anyway!)
>
> Even if so, you're inlining something that looks like this
>
> ,----
> | iterator end()
> |   {
> |   return (iterator(_Mylast));
> |   }
> `----
>
> (constructing a spurious temporary) on every termination
> test. Inlining may save call overhead but says nothing about
> eliminating operations.

Intuitively that seems wrong.  I'd expect end() to be const, and since
nothing else is changing the container, I'd hope a compiler would be
allowed to move it outside the loop.  However, maybe that's not so.

> Maybe it's not worth worrying over a small difference here, but in
> our own code base here we would flag the repeated end() check in a
> code review and require it to be changed.

Yuck.  On the other hand, if you've measured the compilers you use and
found it really does make a difference, then I guess that's what you
have to do.  I doubt it does make a difference, though.

> Apparently idioms are less common than we assume.

Some are local, I guess.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]