Здравствуйте, igna, Вы писали:
I>Ты прав. Но если что-то можно выразить на языке программирования, использовать для этого комментарий не стоит.
Почему тебе кажется, что куча из шаблонов, макросов и особых вызывалок выражает именно это лучше, чем просто комментарий и понятное название функции с ясной семантикой?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[8]: А может по-человечески как-то это сделать? :)
Здравствуйте, remark, Вы писали:
_O_>>Со всем согласен. От себя добавлю, что так же полезно писать к функциям нормальные комментарии и не лениться их читать. Если обработка возвращаемого значения необходима — не поленитесь и отразите это в комментарии.
R>Это смешно. Пользователи читают документацию только в исключительных случаях. Вариант, когда можно и так написать работающий код не относится к исключительным случаям.
А может таки попробовать семантику функций продумывать?
Чтобы не было смысла вызывать функци, игнорируя её значение?
R>
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: А может по-человечески как-то это сделать? :)
E>>Называй функции понятнои с простой и ясной семантикой, избегая при этом всяких синтаксических трюков и неявно генерирующегося и вызываемого кода -- и будет тебе счастье
R>Ну вот например. И чего? И что отсюда следует? R>
R>Во-первых, это будет видно, что здесь что-то обойдено (сравните с "здесь не будет ничего видно"). R>Во-вторых, раз уж надо что-то обходить, то уже есть шанс, что программист задумается, может ему не обойти, а сделать нормальную проверку. R>Обратный вариант — программист просто пишет минимум кода без проверки, этого не видно, не понятно, он это хотел или забыл.
Ну и пишет он без проверки. А ещё может переменные не инициализировать. А ещё ODR может нарушать. И что?
ИМХО есть такие проблемы, против которых бороться средствами самого C++ сложнее, чем не бороться E>>Ну вот скажи, про какую из функций не понятно возвращает она что-то или нет? E>>
R>Ни про какую.
ИМХО последние две не должны ничего возвращать. А первая должна либо получать на вход параметр для заполнения, либо должна возвращать качество E>>Может просто отказаться от возврата кодов ошибок, а API всегда звать через C++ warper? R>Так подожди, ты сам за что? что бы надеяться на мифического вменяемого, неленивого, у_которого_всегда_есть_время, который_не_работает_поздно, который_не_работает_по_14_часов, который_ничего_не_забывает и_т_д программиста, или за то, что бы делать интерфейс, который трудно использовать неправильно при любых обстоятельствах?
Я за то, чтобы борьба с проблемой не была хуже самой проблемы
В частности, если уж тебе так важно проверять использование возврата какой-то функции (и никак никак нельзя переформулировать эту функцию), то используй средства анализа кода, отличные от C++ компилятора. Они реально намного удобнее E>>Вообще искоренит проблему на корню R>Какаим образом?
Ну таким образом, что если случается исключительная ситуация, то происходит обработка через механизм исключений.
А если тебе надо скопировать, то скопируешь, а если надо узнать сколько таки файлов скопировалось, то узнаешь сколько скопировалось.
Я, например, ещё и assert'ы всюду пишу, и assert у меня свой, который в release-версии не откулючается R>Есть по-крайней мере 2 случая, когда это не возможно: R>1. Исключения использовать нельзя — это предусловие
Насколько мне подсказывает мой опыт, использовать твой велосипед там, где нельзя использовать исключения, тем более не получится R>2. Исключения не прикрутишь к интерфейсу. Вот пример:
Какие проблемы?
Может таки лучше иметь два метода? Один для команд, которые точно должны выполниться, а другой для команд, которые могут быть выполненны.
Ещё лучше, если удастся сформулировать два метода.
1) вовращает значение: "можно ли ещё раз выполнить"
2) выполняет, а если не смог -- ошибка
Тогда и циклы писать будет удобно, типа тиак:
while(cmd.CanFetch() ) {
cmd.Fetc();
}
и просто плоский код будет просто писать:
cmd.Fetch(); // Эта запись всегда есть. Ну просто зуб даю!!!
и код в стиле if(!...) { обработка ошибки } тоже удобно пишется:
if( !cmd.CanFetch() ) {
// тут какая-то хитрая обработка, отличная от просто ошибки в Fetch
} else {
cmd.Fetch();
}
И везде всё понятно и никакого форсирования не надо
Мало того, если вдруг метод CanFetch() от чего-то очень трудно написать или неэффективно, скажем, можно и так сделать:
while( cmd.FetchIfCan() ) {
// тут чего-то, что надо
}
да и
cmd.Fetch(); // Эта запись всегда есть. Ну просто зуб даю!!!
совсем не изменится
Ну а третий контекст, тоже будет простой и понятный:
if( !cmd.FetchIfCan() ) {
// тут какая-то хитрая обработка, отличная от просто ошибки в Fetch
}
ИМХО так намного понятнее, чем чудовище из хитроприкрученных шаблонов, да ещё и существенно опирающихся на конкретную реализацию
Тогда уж лучше просто штатными коданализаторами полтзоваться. По крайней мере предсказуемее результат
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[9]: А может по-человечески как-то это сделать? :)
Здравствуйте, _Obelisk_, Вы писали:
_O_>Здравствуйте, remark, Вы писали:
R>>
Свершилось! Форсирование проверки возвращаемого значения в компайл-тайм возможно!
R>>В начале несколько вводных слов, что б было понятно о чём речь:
_O_>Супер! Только вопрос — зачем? _O_>Если программист хочет игнорировать возвращаемое значение — пущай игнорирует.
здесь Andrei Alexandrescu пишет, что проверка — хорошо.
Вот цитата оттуда:
I'm very happy with this solution. Of course, it still doesn't prevent
perverse programmers from saying:
(bool) Fun();
but I ignore perversity. I care only about carelesness.
Вот собственно ответ на твой вопрос: but I ignore perversity. I care only about carelesness.
Здравствуйте, remark, Вы писали:
R>В gcc для этих целей есть __attribute__((warn_unused_result)). Но что делать пользователям msvc? (забить на msvc и перейти на gcc не предлагать )
Не являюсь пользователем g++, но неужели расширение языка в виде __attribute__((warn_unused_result)) накладывает ограничение наличия определения и объявления в одной единице трансляции?
В основном идея понравилась
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
"В любое мгновение принятия решения, лучшее, что вы можете сделать, это принять правильное решение; следующим лучшим вариантом будет принять неправильное решение, худший вариант – не принимать решения совсем" (c) Теодор Рузвельт.
Re[2]: [Trick] Форсирование проверки возвращаемого значения
Здравствуйте, np9mi7, Вы писали:
N>Здравствуйте, remark, Вы писали:
R>>В gcc для этих целей есть __attribute__((warn_unused_result)). Но что делать пользователям msvc? (забить на msvc и перейти на gcc не предлагать )
N>Не являюсь пользователем g++, но неужели расширение языка в виде __attribute__((warn_unused_result)) накладывает ограничение наличия определения и объявления в одной единице трансляции?
Насколько я понял, твоё решение накладывает такое ограничение, поэтому не является полноценной заменой этого расшерения (без учета дополнительного параметра);
"В любое мгновение принятия решения, лучшее, что вы можете сделать, это принять правильное решение; следующим лучшим вариантом будет принять неправильное решение, худший вариант – не принимать решения совсем" (c) Теодор Рузвельт.
Re[4]: [Trick] Форсирование проверки возвращаемого значения
Здравствуйте, np9mi7, Вы писали:
N>Здравствуйте, remark, Вы писали:
R>>В смысле?
N>Насколько я понял, твоё решение накладывает такое ограничение, поэтому не является полноценной заменой этого расшерения (без учета дополнительного параметра);
Да, есть такая фигня. Решение вообще далеко до.... до чего-либо
Для решения именно это проблемы можно разместить само "ядро" функции как и раньше в cpp файле, а в h файле оставить только шаблонную обёртку, которая будет форвардить вызов. Тут только надо будет как-то сделать, что бы пользователи не могли вызывать само "ядро" т.к. иначе весь смысл теряется. Тут наверное можно что-то замутить с недоступными членами и друзьями.
Свершилось! Форсирование проверки возвращаемого значения в компайл-тайм возможно!
А как сделать чтобы всёэто работало на msvc6.0
R>Работает на msvc71/80. В рантайм оверхед нулевой.
R>
Только Путин, и никого кроме Путина! О Великий и Могучий Путин — царь на веки веков, навсегда!
Смотрю только Соловьева и Михеева, для меня это самые авторитетные эксперты.
КРЫМ НАШ! СКОРО И ВСЯ УКРАИНА БУДЕТ НАШЕЙ!
