долго такая мелочь интерсовала, как всё таки писать?
типа правильнее, но нада каждый раз проверять перед вызовом
if(m->CanDoIt)
{
m->DoIt();
}
или
не очень понятно, будет что-то сделано или нет при вызове
void Class::DoIt()
{
if(CanDoIt)
{
...
}
}
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Kingofastellarwar, Вы писали:
K>долго такая мелочь интерсовала, как всё таки писать? K>типа правильнее, но нада каждый раз проверять перед вызовом
"Правильность" и того, и другого кода зависит от условий, в которых он используется.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Kingofastellarwar, Вы писали:
K>долго такая мелочь интерсовала, как всё таки писать?
"сделать, если разрешено" имеет как минимум два измерения:
поведение:
1) если не разрешено, ничего не делать
2) если не разрешено, сигнализировать (например, бросить исключение)
знание вызывающего кода:
1) вызвающий код знает о существовании проверок (т.е. может проверить сам, придумать обходные пути и т.п.)
2) вызвающий код не должен знать о существовании проверок (т.е. глядя на него, невозможно сказать, есть какие-то проверки в программе или нет. Ну и можно использовать как с компонентами, содержащими проверки, так и с несодержащими)
Здравствуйте, Kingofastellarwar, Вы писали:
K>долго такая мелочь интерсовала, как всё таки писать?
K>типа правильнее, но нада каждый раз проверять перед вызовом K>
K>if(m->CanDoIt)
K>{
m->>DoIt();
K>}
K>
K>или
K>не очень понятно, будет что-то сделано или нет при вызове K>
Для однопоточного доступа не важно, но для доступа к "m" из многих потоков первый способ является популярной ошибкой (например, при работе с сокетами). Как правильно сказали, можно сделать две версии, бросающую исключения и не бросающую:
void DoIt();
bool TryDoIt();
Здравствуйте, Kingofastellarwar, Вы писали:
>не очень понятно, будет что-то сделано или нет при вызове
void Class::DoIt()
{
if(!CanDoIt)
return;
...
}
Называется этот паттер guard condition, экономит массу времени и усилий при чтении/поддержке кода. Идея в том, что вложеность блоков сильнее всего коррелирует с количетсвом ошибок.
Здравствуйте, Kingofastellarwar, Вы писали:
K>долго такая мелочь интерсовала, как всё таки писать?
K>типа правильнее, но нада каждый раз проверять перед вызовом K>
Проверки типа CanDoIt, мне кажется, уместны только в одном случае: когда есть виртуальный интерфейс, в реализации которого часть методов не поддерживается — и нужно проверить допустимость связывания компонент приложения. Т.е. например в фреймворке абстрактный класс "поток" (Read(), Write(), CanRead(), CanWrite()...) который передаётся в конструктор, для выполнения записи. Можно проверить аргумент на CanWrite, кинуть исключение. Примерно так дотнетовский System.IO.Stream спроектирован.
В остальных случаях операцию желательно делать атомарной, чтобы не создавать сложностей на пустом месте и не провоцировать ошибок. При необходимости жёстких оптимизаций применить inline. Вообще говоря, не очень ясна логика "если не можем, то ничего не делаем" — разве что это spinlock? Или там ветвление, разные методы в зависимости от состояния вызываются?