[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] resolving name conflicts; code style
From: |
Zack Weinberg |
Subject: |
Re: [Monotone-devel] resolving name conflicts; code style |
Date: |
Sat, 10 May 2008 10:51:59 -0400 |
On Sat, May 10, 2008 at 4:06 AM, Stephen Leake
<address@hidden> wrote:
> "Zack Weinberg" <address@hidden> writes:
>> I would suggest passing just the relevant fields of app.opts.
>
> That makes sense. And now I see it is in HACKING; I guess I need to
> read that again :).
>
> There doesn't seem to be a way to pass an options set. There are four
> relevant fields; resolve_conflicts_given, resolve_conflicts,
> resolve_conflicts_file_given, resolve_conflicts_file. That's unwieldy
> for a parameter list; it would be nice to be able to pass the set.
I suppose you could make up a struct for this. There's no generic way to do it
and off the top of my head I can't think of anything that would be cleaner than
making up structs as necessary.
There's other places where it might be handy, I admit.
>> For the switch statement, I would recommend a default: clause
>> that's an invariant failure, like so:
>>
>> switch (thing)
>> {
>> case one: ...; break;
>> case two: ...; break;
>> case three: ...; break;
>> ...
>> default:
>> I(false);
>> }
>
> Right, if the cases don't cover all the possible values.
Even if they do, sometimes the compiler doesn't understand that - like
in your case, you had a return "" after the switch just to shut it up
about control falling off the end of the function.
>> and don't put anything after the switch.
>
> This I don't understand; what's wrong with more processing after the
> switch?
In general that's fine, but when every case of the switch should
return (as in your original example) we don't want a dummy return.
The invariant failure should be enough to convince the compiler that
control never passes beyond the switch.
zw
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, (continued)
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, William Uther, 2008/05/08
- [Monotone-devel] File resurrection, William Uther, 2008/05/08
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Stephen Leake, 2008/05/09
- Re: [Monotone-devel] resolving name conflicts; code style, Stephen Leake, 2008/05/09
- Re: [Monotone-devel] resolving name conflicts; code style, Stephen Leake, 2008/05/09
- Re: [Monotone-devel] resolving name conflicts; code style, Zack Weinberg, 2008/05/09
- Re: [Monotone-devel] resolving name conflicts; code style, Stephen Leake, 2008/05/10
- Re: [Monotone-devel] resolving name conflicts; code style,
Zack Weinberg <=
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Markus Schiltknecht, 2008/05/09
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Stephen Leake, 2008/05/09
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, William Uther, 2008/05/09
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Markus Schiltknecht, 2008/05/09
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Derek Scherger, 2008/05/09
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Thomas Moschny, 2008/05/10
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Justin Patrin, 2008/05/06
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Markus Schiltknecht, 2008/05/07
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, William Uther, 2008/05/06
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Matthew Nicholson, 2008/05/06