Как на стадии компиляции форсировать проверку возвращаемого значения функции? Или это не возможно?
Как ни странно на форуме ничего похожего не нашёл...
Например:
bool some_func();
if (some_func()); // компилируетсяbool result = some_func(); // компилируется
some_func(); // не должно компилироваться
Здравствуйте, remark, Вы писали:
R>Как на стадии компиляции форсировать проверку возвращаемого значения функции? Или это не возможно? R>Как ни странно на форуме ничего похожего не нашёл...
Думаю, это невозможно.
Функция some_func() должна возвращать результат, который будет неявно приводится к bool (требование для if ( condition ) statement).
Следовательно, в месте, помеченном как "не должно компилироваться", просто произойдет вычисление этого выражения — и все (к сожалению) скомпилируется.
Здравствуйте, remark, Вы писали:
R>Как на стадии компиляции форсировать проверку возвращаемого значения функции? Или это не возможно? R>Как ни странно на форуме ничего похожего не нашёл...
On Thu, 23 Feb 2006 12:53:28 -0000, remark <38267@users.rsdn.ru> wrote:
> Как на стадии компиляции форсировать проверку возвращаемого значения функции? Или это не возможно?
Никак.
Для решения этой задачи хорошо подходят исключения, так как их нельзя случайно проигнорировать.
-- Maxim Yegorushkin
Posted via RSDN NNTP Server 2.0
Re[2]: Форсирование проверки возвращаемого значения
Здравствуйте, MaximE, Вы писали:
ME>On Thu, 23 Feb 2006 12:53:28 -0000, remark <38267@users.rsdn.ru> wrote:
>> Как на стадии компиляции форсировать проверку возвращаемого значения функции? Или это не возможно?
ME>Никак.
ME>Для решения этой задачи хорошо подходят исключения, так как их нельзя случайно проигнорировать.
ME>-- ME>Maxim Yegorushkin
Для решения этой задачи исключения совсем не подходят. Вызов функции может возвращать false, это не ошибка, но тем не менее проверять значение обязательно.
Пример: выполнение запроса на выборку к БД:
DBCommand dbCommand("select a, b from some_table");
while (dbCommand.Fetch()) // Выборка всех записей из запроса
{
...
// Копируем запись куда-то
}
Или выборка одной записи:
DBCommand dbCommand("select a, b from some_table");
if (!dbCommand.Fetch()) // Выборка одной записиreturn false;
...
// Обработка одной записи
R>Для решения этой задачи исключения совсем не подходят.
Почему не подходят?
Учитывая то, что мы говорим о С++, вариантов у тебя не много.
В тех ситуациях, когда обязательно надо проверить результат,
ты можешь возвращать не обычный bool, а объект
и в итоге пользоваться механизмом исключений.
А еще тебе может помочь банальное code review.
Тоже эффективный способ, чтобы проверить выполнение определенных требований к коду.
Можешь попробовать присобачить тулы для статического анализа кода.
Re[4]: Форсирование проверки возвращаемого значения
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, remark, Вы писали:
R>>Для решения этой задачи исключения совсем не подходят.
B>Почему не подходят? B>Учитывая то, что мы говорим о С++, вариантов у тебя не много. B>В тех ситуациях, когда обязательно надо проверить результат, B>ты можешь возвращать не обычный bool, а объект B>и в итоге пользоваться механизмом исключений.
B>А еще тебе может помочь банальное code review. B>Тоже эффективный способ, чтобы проверить выполнение определенных требований к коду. B>Можешь попробовать присобачить тулы для статического анализа кода.
Задача именно в той постановке, в которой есть.
Уже есть дофига кода в большом количестве проектов, где используется эта функция и именно с таким описанием (как возвращающая bool).
Просмотр кода тут не подойдёт.
Изменение семантики функции нельзя делать — нельзя, что бы дофига продуктов начали пададь в местах, о которых все уже давно забыли.
Единственное, что приемлимо — если компилятор покажет места, где значение игнорировалось.
Здравствуйте, Alxndr, Вы писали:
A>Понятно, что использовать для этой цели компилятор кошернее, ну дык ты неделю будешь думать, как это реализовать (а потом все равно напишешь скрипт ).
Если это действительно критично, я бы и скрипту не доверил.
Мало ли какие ситуации в коде, а если скрипт с ошибкой,
то можно критичное место автоматически проигнорировать.
Здравствуйте, remark, Вы писали:
R>Как на стадии компиляции форсировать проверку возвращаемого значения функции? Или это не возможно? R>Как ни странно на форуме ничего похожего не нашёл...
В подобной постановке задача просто некорректна и не решаема. Иными словами, Вы пытаетесь заставить автора вызывающего кода проверить значение, возвращаемое функцией. Это можно сделать лишь на уровне языка программирования и компилятора. Сама же функция не может отвечать за то, как ее используют. Грубо говоря, функция — это "кирпич", из которого автор вызывающего кода строит свой "дом". Но в реальности Вы же не можете заставить кирпич проверять, корректно ли спроектирован дом.
На мой взгляд, более продуктивно поговорить о проблемах, из-за которых Вы хотите внести такую проверку, и попробовать найти для них другое решение.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, Alxndr, Вы писали:
A>>Понятно, что использовать для этой цели компилятор кошернее, ну дык ты неделю будешь думать, как это реализовать (а потом все равно напишешь скрипт ).
B>Если это действительно критично, я бы и скрипту не доверил.
Если это действительно критично И объем работы большой И делать это придется не один раз — я выбираю автоматический инструмент.
Ты доверяешь компилятору?
B>Мало ли какие ситуации в коде, а если скрипт с ошибкой, B>то можно критичное место автоматически проигнорировать.
Инструменты надо тестировать.
Re[8]: Форсирование проверки возвращаемого значения
Здравствуйте, Alxndr, Вы писали:
B>>Мало ли какие ситуации в коде, а если скрипт с ошибкой, B>>то можно критичное место автоматически проигнорировать.
A>Инструменты надо тестировать.
Понятно что надо...
В общем это уже офтопик, который видимо
перейдет в обсуждение требований на этот самый скрипт.
По сути же я с тобой согласен.
Re[5]: Форсирование проверки возвращаемого значения
534 Ignoring return value of function 'Symbol' (compare with
Location) -- A function that returns a value is called
just for side effects as, for example, in a statement by
itself or the left-hand side of a comma operator. Try:
(void) function(); to call a function and ignore its
return value. See also the fvr, fvo and fdr flags in
Section 5.5 Flag Options.
Re[6]: Форсирование проверки возвращаемого значения
Здравствуйте, Alxndr, Вы писали:
A>Здравствуйте, remark, Вы писали:
R>>Единственное, что приемлимо — если компилятор покажет места, где значение игнорировалось.
A>Объясни, почему не подходит внешний инструмент, запускаемый сразу после компиляции?
Проекты не мои, проектов много, я не могу для этих проектов запускать скрипты и т.д.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, Alxndr, Вы писали:
B>>>Мало ли какие ситуации в коде, а если скрипт с ошибкой, B>>>то можно критичное место автоматически проигнорировать.
A>>Инструменты надо тестировать.
B>Понятно что надо... B>В общем это уже офтопик, который видимо B>перейдет в обсуждение требований на этот самый скрипт.
B>По сути же я с тобой согласен.
Поддерживаю, что инструменты для автоматической проверки кода — это полезно. Особенно, если они проверяют и другие вещи.
оффтоп: меня поразили возможности IntelliJ Idea в этой области — вплоть до проверки цикломатической (по-моему так это называется) сложности функций. И всё это встроено прямо в IDE.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, remark, Вы писали:
R>>Как на стадии компиляции форсировать проверку возвращаемого значения функции? Или это не возможно? R>>Как ни странно на форуме ничего похожего не нашёл...
КЛ>В подобной постановке задача просто некорректна и не решаема. Иными словами, Вы пытаетесь заставить автора вызывающего кода проверить значение, возвращаемое функцией. Это можно сделать лишь на уровне языка программирования и компилятора. Сама же функция не может отвечать за то, как ее используют. Грубо говоря, функция — это "кирпич", из которого автор вызывающего кода строит свой "дом". Но в реальности Вы же не можете заставить кирпич проверять, корректно ли спроектирован дом.
В 90 году было так
Но теперь я могу заставить не компилироваться, где наоборот проверяется возвращаемое значение функции.
Или заставить не компилироваться присваивание переменной long результата функции, которая возвращает int.
Или определить для чего используют результат operator[] — для того, что бы присвоить ему что-то, или что бы присвоить его чему-то.
Одним словом, язык с++ гораздо более мощный, чем Вы представляете.
КЛ>На мой взгляд, более продуктивно поговорить о проблемах, из-за которых Вы хотите внести такую проверку, и попробовать найти для них другое решение.
Проблемы всё те же — забывчивость и невнимательность человека
Здравствуйте, igna, Вы писали:
I>Здравствуйте, remark, Вы писали:
R>>Проекты не мои, проектов много, я не могу для этих проектов запускать скрипты и т.д.
I>Вот оно как! Тогда предположим, будто C++ позволяет сделать так, чтобы:
I>
I>bool some_func();
I>if (some_func()); // компилируется
I>bool result = some_func(); // компилируется
I>some_func(); // не должно компилироваться
I>
I>Немаловероятно, что после первой неудачной попытки откомпилировать программу пользователь some_func сделает так:
I>
I>if (some_func())
I> do_the_same_as_yesterday();
I>else
I> ; // HANDLE THIS CASE LATER!!!
I>
I>Тем более, если проект использующий some_func завершен.
И к чему ты всё это?
А если кидать исключение? То что?
Добавят: catch (...){}
Только это ещё хуже, т.к. места, где это надо добавить выявяться только после падения программы.
Я же не говорил форсировать корректную обработку ошибки, я сказал — форсировать хотя бы проверку результата функции.
Если человек напишет: I>
I>if (some_func())
I> do_the_same_as_yesterday();
I>else
I> ; // HANDLE THIS CASE LATER!!!
I>
То возможно он задумается, что в строчке HANDLE THIS CASE LATER!!! его программа будет падать.
