Re[2]: Вместо if-ов - C/C++

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

GN>>>>

GN>>>>_CreateDir(sFile)
GN>>>>  && (CopyFile(lpszTemp, sFile, FALSE))
GN>>>>  && _tcsicmp(m_lpszFile, sFile)
GN>>>>  ;

int __forceinline bp() { __asm int 3 }

bp();
_CreateDir(sFile)
  && (CopyFile(lpszTemp, sFile, FALSE))
  && _tcsicmp(m_lpszFile, sFile)
  ;

СМ>>>2. Куда вставлять другую диагностику, если CopyFile выдал ошибку?

GN>>Re[3]: Вместо if-ов
СМ>ответа так и нет

int __forceinline bp() { __asm int 3 }

_CreateDir(sFile)
  && 
bp(),
    (CopyFile(lpszTemp, sFile, FALSE))
  && _tcsicmp(m_lpszFile, sFile)
  ;

СМ>>>3. Если хоть одно условие не сработало, то что произошло? не создалось оглавление или icmp не сравнилось?

GN>>Re[3]: Вместо if-ов

СМ>3. Если хоть одно условие не сработало, то что произошло? проблема то остается!

Какая проблема? Если о речь о изначальной проблеме конструкции if, то поведение кода не изменится.

СМ>ps
СМ>очень неприятный стиль ответа. давать ссылки, да еще непонятно какое отношение имеет первая ссылка

Прямое.

СМ>зы
СМ>я отписываюсь от этого бреда, так что так и не узнаю новых веяний в написании программ

Это не мои проблемы

.

ЗЫ: Я остерегаюсь использовать слово "бред" для вещей мне непонятных. Возможно, дело всего-лишь в том, что я их не понимаю.

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

GN>ЗЫ: Я остерегаюсь использовать слово "бред" для вещей мне непонятных. Возможно, дело всего-лишь в том, что я их не понимаю.

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

ps
что-то отписка не сработала, попробую еще раз

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

GN>>>>

GN>>>>_CreateDir(sFile)
GN>>>>  && (CopyFile(lpszTemp, sFile, FALSE))
GN>>>>  && _tcsicmp(m_lpszFile, sFile)
GN>>>>  ;

СМ>>>а давайте теперь представим, что вам надо написать не курсовую, а реальную программу. Несколько вопросов:
СМ>>>1. Куда вставлять диагностику, если CreateDir выдал ошибку?
СМ>ответа так и нет

А теперь, позвольте рассавить все точки над Ё.
Что такое "диагностика" в контексте вопроса?
если под этим можно понять возможность указания breakpoints для отладки — я дал ответ;
если же под этим нужно понимать дополнительное ветвление в зависимости от результата _CreateDir
— вопрос некорректен.

СМ>зы
СМ>я отписываюсь от этого бреда, так что так и не узнаю новых веяний в написании программ

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

C>по сути я совсем немного новшеств предлагаю...

ИМХО Вы совсем не предлагаете новшеств

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

СМ>>>зы
СМ>>>я отписываюсь от этого бреда, так что так и не узнаю новых веяний в написании программ

GN>>ЗЫ: Я остерегаюсь использовать слово "бред" для вещей мне непонятных. Возможно, дело всего-лишь в том, что я их не понимаю.

СМ>Я остерегаюсь использовать слово "бред" для вещей мне непонятных. Но здесь нет ничего не понятно, может быть был бы не понятен Пролог, но как раз я сейчас пишу компилятор с него.

СМ>ps
СМ>что-то отписка не сработала, попробую еще раз

Интересный способ ведения диалога — "слушайте меня, а мне наплевать на ответы"

Больше напоминает монолог. Разве на форумах пишут монологи ?

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

C>От себя скажу — в таком синтаксисе меня более всего привлекает то, что нет код не уходит вправо из-за табуляций
Стандартное решение — использовать цепочку else if:

//before
void foo_ugly() {
  if ( condition1 ) {
        if ( condition2 ) {
            if ( condition3 ) {
                do_actual_work();
            } else {
                cout << "Too bad, condition3 was false";
            }
        }    else {
            cout << "Too bad, condition2 was false";
        }
    } else {
        cout << "Too bad, condition1 was false";
    }
}
//after
void foo_much_better() {
    if(!condition1) {
        cout << "Too bad, condition1 was false";
    } else if(!condition2) {
        cout << "Too bad, condition2 was false";
    } else if(!condition3) {
        cout << "Too bad, condition3 was false";
    } else {
        do_actual_work();
    }
}

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

C>Придумалась тут одна шняга, выглядит очень симпатично!

<skipped>

1. А если хоть одна функция в этой последовательности void ?
2.
C>-- не очевидно
3.
C>- не так удобно отлаживать

PD>1. А если хоть одна функция в этой последовательности void ?

Сорри, не совсем точно выразился. Я имею в виду, что внутри if ставится код в {}, и в нем вызываются void функции. Или что-то еще.

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

PD>Сорри, не совсем точно выразился. Я имею в виду, что внутри if ставится код в {}, и в нем вызываются void функции. Или что-то еще.

Ну, можно еще и operator, припахать

bool_func1() && bool_func2() || (void_func1(), void_func2(), bool_func3());

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Глеб Алексеев, Вы писали:

ГА>

ГА>    if ( condition3 ) {
ГА>        do_actual_work();
ГА>    }

Кстати, раз уж в этом топике так остро затронуты проблемы читаемости условных конструкций языка...

Например, можно встретить такой стиль:

if ( condition3 )
    {
    //
    }

И есть такой код:

if ( condition() )
    {
    // здесь может быть, а может и не быть несколько строк кода.
    if ( some_other_complex_condition_that_does_a_lot_of_calculations_and_goes_out_of_the_screen() ) {
        do_actual_work();
    }

Внимание, вопрос:
К чему относится нижняя скобка?

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

GN>

GN>if ( condition() )
GN>    {
GN>    // здесь может быть, а может и не быть несколько строк кода.
GN>    if ( some_other_complex_condition_that_does_a_lot_of_calculations_and_goes_out_of_the_screen() ) {
GN>        do_actual_work();
GN>    }
GN>

GN>Внимание, вопрос:
GN>К чему относится нижняя скобка?

Не вижу проблемы (пример не компилируется из-за отсутствия второй закрывающей скобки, а случайно добавить ее так, чтобы она была незаметна, ИМХО, трудно. И раз разговор зашел о стиле, то some_other_complex_condition_that_does_a_lot_of_calculations_and_goes_out_of_the_screen() — именно это корень зла, а не соглашение о расстановке скобок.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Глеб Алексеев, Вы писали:

GN>>

GN>>if ( condition() )
GN>>    {
GN>>    // здесь может быть, а может и не быть несколько строк кода.
GN>>    if ( some_other_complex_condition_that_does_a_lot_of_calculations_and_goes_out_of_the_screen() ) {
GN>>        do_actual_work();
GN>>    }
GN>>

GN>>Внимание, вопрос:
GN>>К чему относится нижняя скобка?

ГА>Не вижу проблемы (пример не компилируется из-за отсутствия второй закрывающей скобки,

На самом деле скобка конечно же есть где-то ниже по тексту.

Тут дело не в поведении компилятра, а в том, что можно неправильно понять, к чему относится последующий else.

ГА>а случайно добавить ее так, чтобы она была незаметна, ИМХО, трудно.

Очень просто. Во вложенных if {} else {}, когда подбираемяся к 80й колонке.

ГА> И раз разговор зашел о стиле, то some_other_complex_condition_that_does_a_lot_of_calculations_and_goes_out_of_the_screen() — именно это корень зла

См. про 80ю колонку выше. Там и smplcndtn() запросто вылезет за пределы экрана. При последующем чтении листинга.

ГА>а не соглашение о расстановке скобок.

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

Прямо как сказал Будда:

Корень зла есть незнание истины. Из этого же корня вырастает дерево заблуждения с своими тысячными плодами страдания.

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

C>Стоит ли мопед свеч?

Однозначно не стоит, почему тут уже много писали, но есть одно замечание, что именно привлекает в записи без if-ов -- это отсутсвеи большой вложенности.

Предлагаю делать так:

if (!_CreateDir(sFile)) {
    //    возможно обработка ситуации
    return false;
}
if (!CopyFile(lpszTemp, sFile, FALSE)) {
    //    опять возможна обработка ошибочной ситуации
    return false
}
    return _tcsicmp(m_lpszFile, sFile);

И понятно, и отлаживать удобно и поддерживать и доп. диагностику есть куда вставлять -- идеальный вариант однако

(Всё ИМХО, ясень фуясень

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

GN>>>

GN>>>if ( condition() )
GN>>>    {
GN>>>    // здесь может быть, а может и не быть несколько строк кода.
GN>>>    if ( some_other_complex_condition_that_does_a_lot_of_calculations_and_goes_out_of_the_screen() ) {
GN>>>        do_actual_work();
GN>>>    }
GN>>>

GN>>>Внимание, вопрос:
GN>>>К чему относится нижняя скобка?

ГА>>Не вижу проблемы (пример не компилируется из-за отсутствия второй закрывающей скобки,
ГА>>а случайно добавить ее так, чтобы она была незаметна, ИМХО, трудно.

GN>Очень просто. Во вложенных if {} else {}, когда подбираемяся к 80й колонке.

Если код подбирается к 80-й колонке, это значит, что он хочет разъехаться в много маленьких функций с не такой глубокой вложенностью конструкций.

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

E>Предлагаю делать так:

E>

E>if (!_CreateDir(sFile)) {
E>    //    возможно обработка ситуации
E>    return false;
E>}
E>if (!CopyFile(lpszTemp, sFile, FALSE)) {
E>    //    опять возможна обработка ошибочной ситуации
E>    return false
E>}
E>    return _tcsicmp(m_lpszFile, sFile);

E>И понятно, и отлаживать удобно и поддерживать и доп. диагностику есть куда вставлять -- идеальный вариант однако

Идеальный, если можно делать return;.

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

C>Если код подбирается к 80-й колонке, это значит, что он хочет разъехаться в много маленьких функций с не такой глубокой вложенностью конструкций.

Эх, если бы всё в жизни было бы как в сказке

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

А длинными они получаются, когда есть много if {} else {}
Если использовать && есть шанс вместо 2х страниц получить 0.5.

Нет общего решения для всех случаев.
Где-то лучше одно, где-то — другое.

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

R>>ИМХО данная записть основана на том что при разборе логических выражений выхдй из отношения "&&" происходит сразу же если текущий оператор равен 0 (тек поступают большинство компиляторов). Но никто не запрещает компилятору разбирато логические выражения полностью. сооьветсвенно он вызовет все функции. А вот отловить этот баг в данном случае будет проблематично.
C>Выделенное курсивом — верно

C>А вот выделенное жирным неверно — это запрещает Стандарт С++.

А много ли ты знаешь компиляторов которые на 100% соответствуют стандарту?

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

GN>Идеальный, если можно делать return;.

Ну я вообще ратую за короткие и простые функции с ясной семантикой

Ну а для такого сложного действия, как обсуждается тут (там помнится речь шла о десятке if'ов

) совершенно точно стоит заводить отдельную функцию

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

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

R>>>Но никто не запрещает компилятору разбирато логические выражения полностью
C>>А вот выделенное жирным неверно — это запрещает Стандарт С++.
R>А много ли ты знаешь компиляторов которые на 100% соответствуют стандарту?

Не знаю ни одного, кто бы не соответсвовал.
Тем более, что что-то типа:

    assert( p!=0 && p->IsValid() );   //   Довольно общепринятая практика

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

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

R>>>ИМХО данная записть основана на том что при разборе логических выражений выхдй из отношения "&&" происходит сразу же если текущий оператор равен 0 (тек поступают большинство компиляторов). Но никто не запрещает компилятору разбирато логические выражения полностью. сооьветсвенно он вызовет все функции. А вот отловить этот баг в данном случае будет проблематично.
C>>Выделенное курсивом — верно

C>>А вот выделенное жирным неверно — это запрещает Стандарт С++.

R>А много ли ты знаешь компиляторов которые на 100% соответствуют стандарту?

Думаю, проверка конкретно этого пункта стандарта есть в Test Suite любого современного компилятора. Я постоянно пишу код вида

if (ptr && ptr[0] == SOME_MAGIC_NUMBER)
{
    fprintf(stderr, "Bingo!");
}

и не сталкивался с проблемами. Или мне просто везло?

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

	От:	gear nuke
	Дата:	26.09.05 12:29
	Оценка:

	От:	Сергей Мухин
	Дата:	26.09.05 12:37
	Оценка:

	От:	gear nuke
	Дата:	26.09.05 12:41
	Оценка:

	От:	gear nuke
	Дата:	26.09.05 12:51
	Оценка:

	От:	gear nuke
	Дата:	26.09.05 12:51
	Оценка:

	От:	Глеб Алексеев
	Дата:	26.09.05 13:07
	Оценка:	+1

	От:	Alex Alexandrov
	Дата:	27.09.05 05:33
	Оценка:	+1