прервите случай с возвратом.. и для значения по умолчанию

Раньше я любил читать исследовательские работы по сборке мусора (сейчас я чувствую себя намного лучше, спасибо, что спросил). Общим для них было: «Эти алгоритмы были бы быстрее / выполнимыми, если бы у нас была аппаратная поддержка барьеров записи».

В GC существует проблема блокировки чтения-записи. Вы не можете понять, что за фигня, если приложение продолжает перемещать указатели, пока вы пытаетесь провести инвентаризацию. Один трюк, который люди пробовали снова и снова, - это изменение способа написания указателей для отслеживания изменений. Это называется барьером записи, потому что вы не можете писать без ведения бухгалтерии. Это позволяет одновременно запускать приложение и сборщик мусора, но во многих случаях оказалось, что приложение работает слишком медленно.

Intel пришлось решить аналогичную проблему защиты от записи, чтобы виртуализация работала гладко - как запустить приложение, которое выполняет виртуальную память, в операционной системе, в которой уже есть виртуальная память? По сообщениям, Zing использует эти функции для превращения JVM в буквальную виртуальную машину и использует эти возможности для ускорения работы GC. Чем быстрее GC, тем больше куча, с которой вы можете справиться.

38
задан chaos 18 July 2009 в 16:55
поделиться

13 ответов

Вам не нужно ни одного перерыва, но они не вредны. На мой взгляд, чтобы сохранить структуру кода, стоит иметь пару посторонних утверждений.

35
ответ дан 27 November 2019 в 03:30
поделиться

Я согласен с перерывом в последнем случае по умолчанию и не согласен с перерывами после возвратов. (Коллега делает это, и это повреждает мои глаза.)

Я также делаю отступы переключателей, чтобы уменьшить увеличение уровней отступов. :) то есть:

switch(option) {
case 1:
    a = 1;
    b = 7;
    break;
case 2:
    a = 2;
    b = 4;
    return -1;
default:
    a = -1;
    break;
}

(я также думаю, что, поскольку оператор return не является функцией, неуместно применять лишний стиль, который делает его похожим на один)

25
ответ дан 27 November 2019 в 03:30
поделиться

Я бы посчитал перерыв после возврата плохим тоном, вы получите предупреждения о недоступности кода на некоторых компиляторах.

Перерыв в вашем случае по умолчанию полностью уместен, случай провала - инструмент и должен быть особо отмечен при использовании.

2
ответ дан 27 November 2019 в 03:30
поделиться

Разрыв после вашего случая по умолчанию - это просто вопрос личных предпочтений.

Размещение паузы после возврата почти кажется мне противоречивым. Я бы удалил разрыв, просто чтобы оператор return действительно выделялся.

8
ответ дан 27 November 2019 в 03:30
поделиться

Я предпочитаю всегда иметь перерыв в каждом случае , включая значение по умолчанию , и вообще избегать возврата внутри переключателя . Для коротких переключателей всего с 2-3 случаями (включая значение по умолчанию) return подходит, но только если все case делают это одинаково. «Бессмысленный» перерыв я считаю бессмысленным и просто заставляю читать больше кода. То же самое и с пустыми значениями по умолчанию, которые просто ломаются, совершенно бессмысленно. На мой взгляд, легкость чтения кода важнее того, что произойдет, если кто-то изменит то или это.

2
ответ дан 27 November 2019 в 03:30
поделиться

Ни один из перерывов не делает ничего для вас, но ни один из них не навредит.

Лично я обычно не использую их, если у меня есть возврат, но я также стараюсь избегать нескольких если возможно, вернуть точки в функции.

Тем не менее, я считаю, что перерыв в регистре default: хорош - по одной причине: если вы его оставили, и кто-то добавил новый регистр после по умолчанию :,

1
ответ дан 27 November 2019 в 03:30
поделиться

Как отмечали другие, размещение перерыва после возврата или в случае по умолчанию в основном является вопросом личного стиля.

Когда мне не нужно следовать каким-либо конкретным правилам стиля , Я предпочитаю что-то вроде этого:

    switch(foo){
         case 0:
             baz = 1;
             break;
         case 1:
             bar %= 2;
             return -1;
             /* NOTREACHED */
         case 2:
             bar = -1;
             return -2;
             /* NOTREACHED */
             break;
         default:
             break;
    }

Между случаями 1 и 2 я предпочитаю 2. Несмотря на то, что в комментарии написано NOTREACHED, комментарии могут лгать (конечно, непреднамеренно) при изменении кода. Мне нравится комментарий NOTREACHED, поскольку он может удовлетворить lint, что вы знаете, что делаете, и служит напоминанием о том, что вы выходите из функции раньше. Рассуждения о том, что размещение перерыва после возврата уменьшит количество ошибок, если возврат будет удален, мне кажутся ошибочными. Вы по-прежнему будете вести себя фальшиво, независимо от того, перейдете ли вы к следующему делу или выйдете из переключателя и продолжите как раньше.

Конечно, если бы я мог этого избежать, я бы не возвращался из функции в теле переключателя.

1
ответ дан 27 November 2019 в 03:30
поделиться

Что касается комментария, сделанного другими, что они оставляют перерыв в регистре по умолчанию на случай, если кто-то придет позже и добавит случай после него: Где я работаю, стандарт кодирования говорит always ставит значение по умолчанию в качестве последнего случая; так что в нашей ситуации перерыв в этом случае просто излишен. (Это тот случай, когда я полностью согласен со стандартом кодирования компании, потому что, поскольку кейс по умолчанию всегда является последним, вы всегда знаете, где его найти, даже в длинном операторе switch.)

Что касается перерывов после возвращается, я стараюсь опускать перерыв, если нет каких-либо путей выполнения, которые не возвращаются, поскольку я считаю его избыточным. (Мое исключение составляют те редкие случаи, когда в кейсе несколько путей выполнения, и я могу '

1
ответ дан 27 November 2019 в 03:30
поделиться

Мне сказали, что в C, C ++, java и C #, если вы не поставите эти «паузы», поток программного кода попадет в другие «случаи» и выполнит инструкции внутри них, независимо от того, не имеет ли переменная значений, присвоенных «наблюдениям».

1
ответ дан 27 November 2019 в 03:30
поделиться

Я лично не вставляю паузы, но он может помочь, когда кто-то другой решит переместить возврат (-1) в вне переключателя и забывает добавить перерыв.

0
ответ дан 27 November 2019 в 03:30
поделиться

Я бы сделал перерыв, чтобы показать, что вы не собираетесь переходить к следующему делу.

0
ответ дан 27 November 2019 в 03:30
поделиться

In this exact example, for both questions, it is personal preference. In general, the rule is this: anything without a break will fall through. That means (as Pod said) its a good idea to put breaks in default cases in case they are not last. This also means if your case contains a return, then a following break is indeed not necessary.

0
ответ дан 27 November 2019 в 03:30
поделиться

Извините, пожалуйста, за мои ограниченные знания, но что такое ОКР?
Кроме того, Брайан Керниган дает хорошее объяснение того, когда вы должны (не) использовать break в операторе switch .

-1
ответ дан 27 November 2019 в 03:30
поделиться
Другие вопросы по тегам:

Похожие вопросы: