Слышал, что ретурн из свитча не есть гуд. Почему — не знаю, возможно из-за худшей оптимизации. Развейте, пожалуйста, сомнения по этому поводу

int i;
switch(i)
{
case 0:
    break;
default:
    return -1;
}
return 0;

int i, ret;
switch(i)
{
case 0:
    ret = 0;
    break;
default:
    ret = -1;
}
return ret;

п.с. VS6.0/VS8.0

Здравствуйте, Аноним, Вы писали:

А>Слышал, что ретурн из свитча не есть гуд. Почему — не знаю, возможно из-за худшей оптимизации. Развейте, пожалуйста, сомнения по этому поводу

некоторые думают, чтj это не кошерно. Для оптимизации пофиг.

Слышал, что ретурн из свитча не есть гуд. Почему — не знаю, возможно из-за худшей оптимизации. Развейте, пожалуйста, сомнения по этому поводу

скорость тут не при чем. return в произвольном месте, так же как и goto, нарушает линейность кода . И когда Вы через полгода будете править этот свич, то можете пропустить return и даписать код после него. А потом неделю искать багу .

Но это даже не методология, а так, рекомендация. Что-то вроде "если можно легко обойтись без return в switch — лучше его там не писать". Понятное дело что если по логике функции return там уместен — то он там и должен быть .

Здравствуйте, EyeOfHell, Вы писали:

EOH>

Слышал, что ретурн из свитча не есть гуд. Почему — не знаю, возможно из-за худшей оптимизации. Развейте, пожалуйста, сомнения по этому поводу

EOH>скорость тут не при чем. return в произвольном месте, так же как и goto, нарушает линейность кода . И когда Вы через полгода будете править этот свич, то можете пропустить return и даписать код после него. А потом неделю искать багу .

EOH>Но это даже не методология, а так, рекомендация. Что-то вроде "если можно легко обойтись без return в switch — лучше его там не писать". Понятное дело что если по логике функции return там уместен — то он там и должен быть .

хм.. а мне кажется ретурн в свитче улучшает читабельность кода

Здравствуйте, Аноним, Вы писали:

EOH>>Но это даже не методология, а так, рекомендация. Что-то вроде "если можно легко обойтись без return в switch — лучше его там не писать". Понятное дело что если по логике функции return там уместен — то он там и должен быть .

А>хм.. а мне кажется ретурн в свитче улучшает читабельность кода

В примере который выше — мне тоже так кажется.
А вообще ситуации разные бывают. Ретурн меняет поведение свитча, т.е. я ожидаю, что управление перейдёт на следующую строку после свитча, а на самом деле может произойти выход из функции. Т.к. свитч может быть большой, то легко проглядеть.

Здравствуйте, Сергей Мухин, Вы писали:

СМ>некоторые думают, чтj это не кошерно. Для оптимизации пофиг.

предположительно, single return path кошерней для [N]RVO.

EOH>скорость тут не при чем. return в произвольном месте, так же как и goto, нарушает линейность кода . И когда Вы через полгода будете править этот свич, то можете пропустить return и даписать код после него. А потом неделю искать багу .
В С++ нельзя полагаться на некую "линейность" хотябы потому что там еще исключения иногда бывают, и написанному коду должно быть пофиг где происходит выход (с учетком нормально вызова деструкторов всяческих гардов).

В С++ нельзя полагаться на некую "линейность" хотябы потому что там еще исключения иногда бывают, и написанному коду должно быть пофиг где происходит выход (с учетком нормально вызова деструкторов всяческих гардов)

Так кто спорит. Но, к сожалению, когда через полгода-год нужно что-то поменять в паре десятков тысячь строк кода и навигация по нему идет исключительно через code definition window и find, то велика вероятность пропустить неочевидное поведение. Поэтому в больших проектах стараются код по мере сил держать линейным, неочевидного ничего не писать а исключения использовать исключительно для обработки ошибок . Дабы снизить последующие наклодные расходы по отладке и сопровождению. Исключить проблемы, понятное дело, не получается. Но если благодаря простому коду удалось впоследствии избежать хотя бы нескольких багов от его изменения — то это уже очень значительный плюс по времени.

Все это субъектино, конечно. Костыли так сказать, потому что слаб человек и память у него не ахти . Понятное дело что внимательному программисту с хорошей памятью вся эта мишура нафиг не нужна. Но, к сожалению, кода много — а внимательных людей с хорошей памятью мало. Приходится выкручиваться кто как может .

Здравствуйте, Аноним, Вы писали:

все зависит от конкретного случая. в простых случаях вполне нормально, например:

enum { eDog, eFox, eWolf };
....
std::string SomeEnumToSomeString(int e)
{
    switch(e)
    {
    case eDog:  return "Dog";
    case eFox:  return "Fox";
    case eWolf: return "Wolf";
    }
    throw "Unexpected enum";
}

смотрится вполне читабельно.

Спасибо всем за ответы!
В общем, чем сложнее и больше свитч, тем менее желательно использовать в нём для выхода что-либо кроме break.

Здравствуйте, alzt, Вы писали:

A>А вообще ситуации разные бывают. Ретурн меняет поведение свитча

Ай. Непоставленный в нужном месте или поставленный в ненужном break тоже ой как "меняет поведение свича"...

A>, т.е. я ожидаю, что управление перейдёт на следующую строку после свитча, а на самом деле может произойти выход из функции. Т.к. свитч может быть большой, то легко проглядеть.

Не делай больших свичей, как и вообще ветви свчиа, густо и сытно наполненные функциональностью.

Здравствуйте, Аноним, Вы писали:

А>Спасибо всем за ответы!
А>В общем, чем сложнее и больше свитч, тем менее желательно использовать в нём для выхода что-либо кроме break.

Извините за выражение, но х.там! "чем сложнее и больше свитч, тем менее желательно использовать" (к) — _такой_ большой и сложный свич вообще!

Здравствуйте, Аноним, Вы писали:

А>Спасибо всем за ответы!
А>В общем, чем сложнее и больше свитч, тем менее желательно использовать в нём для выхода что-либо кроме break.
Важно не это. Важно чтобы все ветви switch'а одиаково заканчивались. Или все return'ом или все break'ом. А не так, что там return, тут break, а там "проваливающися brrak"...

А>Спасибо всем за ответы!
А>В общем, чем сложнее и больше свитч, тем менее желательно использовать в нём для выхода что-либо кроме break.

ИМХО большой свитч — плохой свитч. Если необходимо делать длинное перечисление, то функциональную часть каждого случая уместней переводить в отдельный метод. Например:

switch (m_Direction)
{
case 0:
    return GoToSouth();
case 1:
    return GoToWest();
case 2:
    return GoToNorth();
case 3:
    return GoToEast();
default:
    return ERROR_REDCODE;
}

ПО сабжу: Камрады, один знакомый все утверждал, что использование switch в C++ вообще... неуместно в принцепи! Мол в C++ надо "как-то иначе". Естесно, на вопрос "Как?" ответ не прозвучал. Может кто нибудь сведующий кашерный стиль кодинга развеет непонимание?

Не делай больших свичей, как и вообще ветви свчиа, густо и сытно наполненные функциональностью.

Почти все state machines выглядят как свечи. Основательная state machine даже при очень хорошей декомпозиции будет иметь большие свичи, которые в таблицы не преобразуются по определению.

State machines конечно используются реже чем 'тут у нас морда программы, тут ее логика, а тут сигналы', но все равно достаточно, чтобы свичи были. И как от них избавляться?

Извините за выражение, но х.там! "чем сложнее и больше свитч, тем менее желательно использовать" (к) — _такой_ большой и сложный свич вообще!

state machines

А>ПО сабжу: Камрады, один знакомый все утверждал, что использование switch в C++ вообще... неуместно в принцепи! Мол в C++ надо "как-то иначе". Естесно, на вопрос "Как?" ответ не прозвучал. Может кто нибудь сведующий кашерный стиль кодинга развеет непонимание?

Код со свичом:
class Walker
{
int m_Direction;
public:
Walker(int direction):m_Direction(direction){};
int Go()
{
switch (m_Direction)
{
case 0:
    return GoToSouth();
case 1:
    return GoToWest();
case 2:
    return GoToNorth();
case 3:
    return GoToEast();
default:
    return ERROR_REDCODE;
}
}
};
Код без:

class IWalker
{
public:
virtual int Go() = 0;
};

class SouthWalker : public IWalker
{
public:
virtual int Go(){return GoToSouth()};
};

class WestWalker : public IWalker
{
public:
virtual int Go(){return GoToWest()};
};

class NorthWalker : public IWalker
{
public:
virtual int Go(){return GoToNorth()};
};

class EastWalker : public IWalker
{
public:
virtual int Go(){return GoToEast()};
};

Предвещая вопрос что типа в создании конкретного экземпляра класса потребуется свич — нет не потребуется, если раскрутить логику до уровня когда каждое направление имеет свою отдельную ветвь исполнения с самого начала определения направления.

Здравствуйте, The Lex, Вы писали:

TL>Здравствуйте, Аноним, Вы писали:

А>>Спасибо всем за ответы!
А>>В общем, чем сложнее и больше свитч, тем менее желательно использовать в нём для выхода что-либо кроме break.

TL>Извините за выражение, но х.там! "чем сложнее и больше свитч, тем менее желательно использовать" (к) — _такой_ большой и сложный свич вообще!

Извинить, не извинить не могу, потому что не пойму что за "х.там" может "х.. там"?
Если я правильно понял, фраза "_такой_ большой и сложный свич вообще! " выражает недовольство большими свитчами. Я тоже не люблю когда много кода. Но когда его мало, босс отказывается платить

Здравствуйте, Аноним, Вы писали:

А>>ПО сабжу: Камрады, один знакомый все утверждал, что использование switch в C++ вообще... неуместно в принцепи! Мол в C++ надо "как-то иначе". Естесно, на вопрос "Как?" ответ не прозвучал. Может кто нибудь сведующий кашерный стиль кодинга развеет непонимание?

[]

А>Предвещая вопрос что типа в создании конкретного экземпляра класса потребуется свич — нет не потребуется, если раскрутить логику до уровня когда каждое направление имеет свою отдельную ветвь исполнения с самого начала определения направления.

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

Здравствуйте, Аноним, Вы писали:

А>>ПО сабжу: Камрады, один знакомый все утверждал, что использование switch в C++ вообще... неуместно в принцепи! Мол в C++ надо "как-то иначе". Естесно, на вопрос "Как?" ответ не прозвучал. Может кто нибудь сведующий кашерный стиль кодинга развеет непонимание?
А>

А>Код без:

А>class IWalker
А>{
А>public:
А>virtual int Go() = 0;
А>};

А>class SouthWalker : public IWalker
А>{
А>public:
А>virtual int Go(){return GoToSouth()};
А>};

А>class WestWalker : public IWalker
А>{
А>public:
А>virtual int Go(){return GoToWest()};
А>};

А>class NorthWalker : public IWalker
А>{
А>public:
А>virtual int Go(){return GoToNorth()};
А>};

А>class EastWalker : public IWalker
А>{
А>public:
А>virtual int Go(){return GoToEast()};
А>};
А>

А>Предвещая вопрос что типа в создании конкретного экземпляра класса потребуется свич — нет не потребуется, если раскрутить логику до уровня когда каждое направление имеет свою отдельную ветвь исполнения с самого начала определения направления.

Красиво

Только, все же, если до токо как "куда-нибудь пойти" идет много-много общих строк кода и выбор направления движения как раз таки определяется переменной Direction. В этом случае, как я понимаю, без switch никак?