[Trick] Форсирование проверки возвращаемого значения
От: remark Россия http://www.1024cores.net/
Дата: 24.12.06 16:19
Оценка: 40 (10) -1

Свершилось! Форсирование проверки возвращаемого значения в компайл-тайм возможно!

В начале несколько вводных слов, что б было понятно о чём речь:

bool f();

int main()
{
  if (!f()) // Хорошо! Проверили возвращаемое значение
    exit(1);

  f(); // Плохо! Не проверили возвращаемое значение
}

Как заставить пользователя функции f() не игнорировать возвращаемое значение?

В gcc для этих целей есть __attribute__((warn_unused_result)). Но что делать пользователям msvc? (забить на msvc и перейти на gcc не предлагать )

Есть такое решение
Автор: Sm0ke
Дата: 28.02.06
, но оно вносит некоторый оверхед в рантайм, плюс невозможно найти ошибку, пока код с ошибкой не отработает.

Ещё есть такое интересное решение
Автор: elcste
Дата: 24.02.06
, но оно работает только для свободных функций, что сводит его не нет.

Решение

Вначале пример использования. Допустим есть такая функция, для которой надо форсировать проверку:
bool fff(int param)
{
    return 0 == param;
}


Для форсирования проверки придётся написать вот так:

template<int id>
checked_result<id> fff_wrap(int param, RESULT_CHECK_PARAM)
{
    return 0 == param;
}


Как работает:

int main()
{
    bool b1 = fff(1, ID); // Компилируется
    ignore_result(fff(2, ID)); // Компилируется
    if (fff(2, ID)); // Компилируется
    fff(1, ID); // НЕ Компилируется! error C2027: use of undefined type 'boost::STATIC_ASSERTION_FAILURE<x>'
}


К сожалению параметр RESULT_CHECK_PARAM — необходимость — сейчас будет видно. Собственно исходный код:


// Стратегии сообщения об ошибке (куда сейчас без стратегий? :) )
// На выбор - ошибка компиляции, варнинг, ошибка без использования boost (специально для нелюбителей boost'а :) )

struct error_report_policy
{
    template<typename> static void report()
    {
        BOOST_STATIC_ASSERT(false);
    }
};

struct error_report_no_boost_policy
{
    template<typename> static void report()
    {
        typedef char error[-1];
    }
};

struct warning_report_policy
{
    template<typename> static void report()
    {
        BOOST_STATIC_WARNING(false);
    }
};

namespace
{
    // Вспомогательный класс - ниже будет видно зачем
    template<int id>
    struct result_check_helper
    {
        static void fake() {}
    };
}

// Собственно класс для возвращаемого значения
// id - вспомогательный параметр
// type - тип возвращаемого значения - bool, int, HRESULT и т.д.
// report_policy - одна из вышеприведённых стратегий информирования об ошибке
template<int id, typename type = bool, typename report_policy = error_report_policy>
class checked_result
{
public:
    checked_result(type value)
        : value_(value)
    {}

    operator type ()
    {
        // Обращаемся к классу result_check_helper<id>
        // ниже будет видно зачем
        result_check_helper<id>::fake();
        return value_;
    }

    ~checked_result()
    {
        // ЗДЕСЬ!
        // Определяем есть ли класс result_check_helper<id>,
        // что фактически равнозначно тому, вызывается operator type () или нет!
        __if_not_exists (result_check_helper<id>)
        {
            report_policy::report<void>();
        }
    }

private:
    type value_;
};

// Вспомогательный класс для передачи уникальных идентификаторов вызова
template<int id> struct long_and_inconvenient_name {static const int id = id;};

// Вспомотельный макрос для генерации уникальных идентификаторов вызова
// В реальности надо какое-то более длинное имя, чем ID, но здесь для простоты так
#define ID long_and_inconvenient_name<__COUNTER__>()

// Вспомогательный макрос
#define RESULT_CHECK_PARAM long_and_inconvenient_name<id>

// Функции для явного игнорирования возвращаемого значения
inline void ignore_result(bool) {}
inline void ignore_result(int) {}
//...


Работает на msvc71/80. В рантайм оверхед нулевой.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re: [Trick] Форсирование проверки возвращаемого значения
От: rm822 Россия  
Дата: 25.12.06 16:45
Оценка: 12 (5) +2
Да вы батенька знаете толк в извращениях. Знатный велосипед.
Это все фигня. Вы воспользовались MS-extention __if_not_exist, а раз вы им воспользовались то заведомо прилипли к платформе
У MS есть решение подобного рода встроеное в компилер, которое кстати сказать работает на порядок лучше

// C++
#include <codeanalysis\sourceannotations.h>
using namespace vc_attributes;
[returnvalue:Post(MustCheck=Yes)] int fff();


я получил такой вот варнинг
warning C6031: Return value ignored: 'fff'

PS:для этого надо врубить code-analysys в свойствах проекта.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: А может по-человечески как-то это сделать? :)
От: Erop Россия  
Дата: 25.12.06 15:58
Оценка: 1 (1) +3
Здравствуйте, remark, Вы писали:

R>Без форсирования:

R>1. Неправильный код написать легче, чем правильный
Называй функции понятнои с простой и ясной семантикой, избегая при этом всяких синтаксических трюков и неявно генерирующегося и вызываемого кода -- и будет тебе счастье
R>2. Не явны намерения программиста: он забыл проверить или хотел это сделать?
Ну коглда программист вменяемый, то и не страшно, а когда невменяемый, то он обойдёт твою приблуду на раз-два-три
R>3. Код менее читабельный: f() — а эта функция что-то ещё и возвращает?
Ну вот скажи, про какую из функций не понятно возвращает она что-то или нет?
EvalVariantQuality( ... );
CloseAllActiveConnections( ... )
CopyFiles( ... );


Может просто отказаться от возврата кодов ошибок, а API всегда звать через C++ warper?
Тогда информацию об ошибках игнорировать будет нельзя. Обрабатывать её будут в удобных местах, а нужно ли значение, возвращаемое функцией будет понятно из её названия.
Скажем функция CopyFiles( ... ) ничего не возвращает, а GetCopiedFilesCount() -- возвращает
А, скажем такая или анологичная конструкция:
class CFilesCopyist {
public:
    CFilesCopyist();
    CFilesCopyist( const char* Src, const char* Dst, DWORD mode );
    ~CFilesCopyist();

    //   Установка дополнительных параметров
    void SetSrcPath( const char* );
    void SetDstPath( const char* );
    void SetWildcard( const char* );

    void SetCopyMode( DWORD mode );
    bool IsParamsCorrect();

    void CopyFiles();

    int GetCopiedFilesCount() const;
};


Вообще искоренит проблему на корню
R>Форсирование решает все эти проблемы.

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

R>

Да не вопрос!
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: А может по-человечески как-то это сделать? :)
От: igna Россия  
Дата: 26.12.06 09:36
Оценка: 1 (1) +2 -1
Здравствуйте, _Obelisk_, Вы писали:

_O_>От себя добавлю, что так же полезно писать к функциям нормальные комментарии и не лениться их читать.


Ты прав. Но если что-то можно выразить на языке программирования, использовать для этого комментарий не стоит.

Write code instead of comments where possible.

(Herb Sutter, Andrei Alexandrescu. C++ Coding Standards: 101 Rules, Guidelines, and Best Practices)

Re: [Trick] Форсирование проверки возвращаемого значения
От: IROV..  
Дата: 24.12.06 21:10
Оценка: 1 (1) :)
Здравствуйте, remark, Вы писали:

...


struct ignore_result_t {};

#    define ignore_result ( ignore_result_t() )

class checked_result
{
  ...
    void operator () ( ignore_result_t )
    {
        result_check_helper<id>::fake();
    }
  ...
}


int main()
{
    fff(2, ID) ignore_result; // Компилируется
}


Могу еще предложить вот такой забавный трюк
я не волшебник, я только учусь!
Re[2]: [Trick] Форсирование проверки возвращаемого значения
От: remark Россия http://www.1024cores.net/
Дата: 25.12.06 08:34
Оценка: +1 :)
Здравствуйте, night beast, Вы писали:

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


R>>

Свершилось! Форсирование проверки возвращаемого значения в компайл-тайм возможно!

R>>В начале несколько вводных слов, что б было понятно о чём речь:

R>>Работает на msvc71/80. В рантайм оверхед нулевой.


R>>


NB>может стоит ID сделать первым параментром, на случай если у функции есть параметры по умолчанию?


Это можно варьировать по желанию для каждой функции.
В данном случае просто хотелось более показать сходство с оригинальной функцией.

NB>PS: а что, действительно большая проблема в проверкой?


С проверкой — нет, а вот с не проверкой — да

Ты не видишь в следующем коде проблемы?

CopyFile(lpExistingFileName, lpNewFileName, FALSE);


Программист по определению ленивый. Если что-то можно не сделать, то рано или поздно (например в 1 ночи ) он это обязательно не сделает.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[2]: [Trick] Форсирование проверки возвращаемого значения
От: rg45 СССР  
Дата: 25.12.06 14:32
Оценка: +2
"IROV.." <35375@users.rsdn.ru> wrote in message news:2279806@news.rsdn.ru...
> Здравствуйте, remark, Вы писали:
>
> R>

Свершилось! Форсирование проверки возвращаемого значения в компайл-тайм возможно!

>
> как по мне на лицо борьба с ветряными мельницами! а именно, ну а кто мне _леньтяю_ запретит писать вот такое..
>
>
> if( foo( 1, 2 ) );
>

>
>

Так в этом то и состоит цель этой затеи, чтоб заставить пользователя так писать. Таким образом пользователь как бы говорит: "я осознанно проигнорировал результат, всю ответственность беру на себя...".
Цель, вообще говоря, хорошая, но, имхо, не такой ценой как в предлагаемом варианте: один только макрос RESULT_CHECK_PARAM чего стоит.
Posted via RSDN NNTP Server 2.0
--
Не можешь достичь желаемого — пожелай достигнутого.
Re[8]: А может по-человечески как-то это сделать? :)
От: _Obelisk_ Россия http://www.ibm.com
Дата: 26.12.06 13:23
Оценка: +2
Здравствуйте, igna, Вы писали:

I>

I>Write code instead of comments where possible.

I>(Herb Sutter, Andrei Alexandrescu. C++ Coding Standards: 101 Rules, Guidelines, and Best Practices)


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



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[4]: [Trick] Форсирование проверки возвращаемого значения
От: remark Россия http://www.1024cores.net/
Дата: 20.01.07 16:56
Оценка: -1 :)
Здравствуйте, np9mi7, Вы писали:

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


R>>В смысле?


N>Насколько я понял, твоё решение накладывает такое ограничение, поэтому не является полноценной заменой этого расшерения (без учета дополнительного параметра);


Да, есть такая фигня. Решение вообще далеко до.... до чего-либо

Для решения именно это проблемы можно разместить само "ядро" функции как и раньше в cpp файле, а в h файле оставить только шаблонную обёртку, которая будет форвардить вызов. Тут только надо будет как-то сделать, что бы пользователи не могли вызывать само "ядро" т.к. иначе весь смысл теряется. Тут наверное можно что-то замутить с недоступными членами и друзьями.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[3]: [Trick] Форсирование проверки возвращаемого значения
От: Roman Odaisky Украина  
Дата: 06.02.07 21:26
Оценка: 2 (1)
Здравствуйте, Alxndr, Вы писали:

R>>Если кого это интересует, то это больше не M$ SPECIFIC, это 100% PURE C++ благодаря здесь
Автор: remark
Дата: 06.02.07


A>А что такого в исходном решении M$ SPECIFIC?


Как что, __if_exists.
До последнего не верил в пирамиду Лебедева.
Re: [Trick] Форсирование проверки возвращаемого значения
От: IROV..  
Дата: 24.12.06 20:32
Оценка: :)
Здравствуйте, remark, Вы писали:

...

fff(1, ID /* - фээ некрасиво */ );


я не волшебник, я только учусь!
Re: [Trick] Форсирование проверки возвращаемого значения
От: _Winnie Россия C++.freerun
Дата: 25.12.06 13:55
Оценка: +1
Здравствуйте, remark, Вы писали:

Прикольно, но ИМХО неудобства написания шаблонного враппера к каждому нешаблонному методу здесь слишком большие. И это не удовлетворяет более ранним требования — "есть дофига старого кода, хочу проверить ошибки там" — нужен параметр ID.
Можно конечно макросы ещё написать — #define Foo(x) Foo(x, ID), но это всё более и более уход в Темную Сторону.

Я бы выбрал или runtime-проверку с тестрованием, или трюк с двумя проходами компиляции — http://www.rsdn.ru/Forum/?mid=1698165&amp;flat=0
Автор: Erop
Дата: 25.02.06

или code guide с написанием скрипта — "эту функцию можно вызывать только так — ^bool :i = foo\(.*\);$ и как if \(.*foo" (это не реальные регэкспы а просто как начинать их писать)
Можно даже скрипт не писать, а сразу Edit->Find In Files. И заграть в макрокнопку студии.
Правильно работающая программа — просто частный случай Undefined Behavior
Re: [Trick] Форсирование проверки возвращаемого значения
От: IROV..  
Дата: 25.12.06 14:23
Оценка: +1
Здравствуйте, remark, Вы писали:

R>

Свершилось! Форсирование проверки возвращаемого значения в компайл-тайм возможно!


как по мне на лицо борьба с ветряными мельницами! а именно, ну а кто мне _леньтяю_ запретит писать вот такое..

if( foo( 1, 2 ) );


я не волшебник, я только учусь!
Re[3]: [Trick] Форсирование проверки возвращаемого значения
От: IROV..  
Дата: 25.12.06 14:54
Оценка: +1
Здравствуйте, rg45, Вы писали:

R>Так в этом то и состоит цель этой затеи, чтоб заставить пользователя так писать. Таким образом пользователь как бы говорит: "я осознанно проигнорировал результат, всю ответственность беру на себя...".

R>Цель, вообще говоря, хорошая, но, имхо, не такой ценой как в предлагаемом варианте: один только макрос RESULT_CHECK_PARAM чего стоит.

Хочу не согласится! если честно то если програмист _ленивый_, то он напишет именно if(...); только по томучто ему лень, а потом забудет как всегда.
Я вот понимаю сделать чтото типа такого..

result r = foo( ... );

r.check_result(); // для подтверждения того что я оттестил. тогда я хоть по ctrl + F смогу отыскать все такие места, и поправить если что забыл..


Конечно это оверхед, но его можно отключать в релизе!

я не волшебник, я только учусь!
Re[6]: А может по-человечески как-то это сделать? :)
От: _Obelisk_ Россия http://www.ibm.com
Дата: 25.12.06 16:50
Оценка: +1
Здравствуйте, Erop, Вы писали:

...
E>Короче, ИМХО, лучше подходить с другого конца. Не заставлять при помощи плохо переносимых и очень сложных и не особо понятных трюков программиста делать то, что делать на самом деле неудобно, а так обустроить архитектуру и технологию программирования, что неудобные действия станут ненужными

Со всем согласен. От себя добавлю, что так же полезно писать к функциям нормальные комментарии и не лениться их читать. Если обработка возвращаемого значения необходима — не поленитесь и отразите это в комментарии.



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[7]: А может по-человечески как-то это сделать? :)
От: remark Россия http://www.1024cores.net/
Дата: 26.12.06 09:43
Оценка: +1
Здравствуйте, _Obelisk_, Вы писали:

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


_O_>...

E>>Короче, ИМХО, лучше подходить с другого конца. Не заставлять при помощи плохо переносимых и очень сложных и не особо понятных трюков программиста делать то, что делать на самом деле неудобно, а так обустроить архитектуру и технологию программирования, что неудобные действия станут ненужными

_O_>Со всем согласен. От себя добавлю, что так же полезно писать к функциям нормальные комментарии и не лениться их читать. Если обработка возвращаемого значения необходима — не поленитесь и отразите это в комментарии.


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


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[8]: А может по-человечески как-то это сделать? :)
От: _Obelisk_ Россия http://www.ibm.com
Дата: 26.12.06 13:20
Оценка: +1
Здравствуйте, remark, Вы писали:

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


Хм. Я всегда читаю документацию или комментарии на функции, которые собираюсь использовать. Коллеги тоже.
Мы говорим ведь от девелоперах, а не о конечных потребителях. Излишние навороты на пустом месте не нужны.



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[8]: А может по-человечески как-то это сделать? :)
От: Erop Россия  
Дата: 26.12.06 13:32
Оценка: +1
Здравствуйте, igna, Вы писали:

I>Ты прав. Но если что-то можно выразить на языке программирования, использовать для этого комментарий не стоит.

Почему тебе кажется, что куча из шаблонов, макросов и особых вызывалок выражает именно это лучше, чем просто комментарий и понятное название функции с ясной семантикой?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: А может по-человечески как-то это сделать? :)
От: Erop Россия  
Дата: 26.12.06 15:47
Оценка: +1
E>>Называй функции понятнои с простой и ясной семантикой, избегая при этом всяких синтаксических трюков и неявно генерирующегося и вызываемого кода -- и будет тебе счастье

R>Ну вот например. И чего? И что отсюда следует?

R>
R>CopyFile(lpExistingFileName, lpNewFileName, FALSE);
R>

отсюда следует, что функция должна быть void



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


E>>Ну вот скажи, про какую из функций не понятно возвращает она что-то или нет?
E>>
E>>EvalVariantQuality( ... );
E>>CloseAllActiveConnections( ... )
E>>CopyFiles( ... );
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[2]: [Trick] Форсирование проверки возвращаемого значения
От: remark Россия http://www.1024cores.net/
Дата: 28.12.06 01:04
Оценка: :)
Здравствуйте, _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.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[2]: [Trick] Форсирование проверки возвращаемого значения
От: Alxndr Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 06.02.07 21:15
Оценка: :)
Здравствуйте, remark, Вы писали:

R>Если кого это интересует, то это больше не M$ SPECIFIC, это 100% PURE C++ благодаря здесь
Автор: remark
Дата: 06.02.07


А что такого в исходном решении M$ SPECIFIC?
Re: [Trick] Форсирование проверки возвращаемого значения
От: _Obelisk_ Россия http://www.ibm.com
Дата: 24.12.06 17:59
Оценка:
Здравствуйте, remark, Вы писали:

R>

Свершилось! Форсирование проверки возвращаемого значения в компайл-тайм возможно!

R>В начале несколько вводных слов, что б было понятно о чём речь:

Супер! Только вопрос — зачем?
Если программист хочет игнорировать возвращаемое значение — пущай игнорирует.



Душа обязана трудиться! (с) Н.Заболоцкий.
Re: [Trick] Форсирование проверки возвращаемого значения
От: johny5 Новая Зеландия
Дата: 25.12.06 03:10
Оценка:
Здравствуйте, remark, Вы писали:



R>

Свершилось! Форсирование проверки возвращаемого значения в компайл-тайм возможно!

Ну во первых нужно было прям перед заголовком вот так написать:

Microsoft specific

Я может дальше и читать бы не стал


R>
R>template<int id>
R>checked_result<id> fff_wrap(int param, RESULT_CHECK_PARAM)
R>{
R>    return 0 == param;
R>}
R>


R>Как работает:


R>
R>int main()
R>{
R>    bool b1 = fff(1, ID); // Компилируется
R>    ignore_result(fff(2, ID)); // Компилируется
R>    if (fff(2, ID)); // Компилируется
R>    fff(1, ID); // НЕ Компилируется! error C2027: use of undefined type 'boost::STATIC_ASSERTION_FAILURE<x>'
R>}
R>


Тут наверно таки вызов fff_wrap?



R>

   [cut]

R>



Я так понимаю, при каждом вызове такой функции, будет инстанцироваться result_check_helper<int id>::fake()
У линкера башню то не порвёт?
Re[2]: [Trick] Форсирование проверки возвращаемого значения
От: remark Россия http://www.1024cores.net/
Дата: 25.12.06 08:09
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

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


R>>

Свершилось! Форсирование проверки возвращаемого значения в компайл-тайм возможно!

R>>В начале несколько вводных слов, что б было понятно о чём речь:

_O_>Супер! Только вопрос — зачем?

_O_>Если программист хочет игнорировать возвращаемое значение — пущай игнорирует.

Я думаю, это одна из тех вещей, которые не объяснить. Те, кто поняли зачем, тем понятно, а те кто не поняли, тем не объяснить.
Ну это типа как "А зачем программировать на С++, когда есть С?" или "Зачем использовать исключения, когда есть коды возврата?"


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[2]: [Trick] Форсирование проверки возвращаемого значения
От: remark Россия http://www.1024cores.net/
Дата: 25.12.06 08:14
Оценка:
Здравствуйте, IROV.., Вы писали:

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


IRO>...


IRO>
IRO>fff(1, ID /* - фээ некрасиво */ ); 
IRO>


IRO>


Согласен.
Но во-первых, надо с чего-то начинать. Это первый рабочий вариант, который я видел (который работает и для методов). На rsdn точно ничего аналогичного нет, в других местах тоже не видел. В Overload ещё не так давно кто-то писал про вариант типа здесь
Автор: Sm0ke
Дата: 28.02.06
. Далее надо улучшать. Для чего собственно я это и выложил на всеобщее рассмотрение.
Во-вторых, это красивее:
func_with_very_important_result(1);





1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[2]: [Trick] Форсирование проверки возвращаемого значения
От: remark Россия http://www.1024cores.net/
Дата: 25.12.06 08:18
Оценка:
Здравствуйте, IROV.., Вы писали:

IRO>Могу еще предложить вот такой забавный трюк


Не вижу сильного различия между:
fff(2, ID) ignore_result;

и:
ignore_result(fff(2, ID));}


что бы для этого вводить ещё макросы.

А в таком варианте это будет хуже, т.к. будет не видно:

some_func_with_long_name(/*много параметров*/, ID) /* за границей экрана*/ ignore_result;


Тут есть более серьёъные проблемы (основная — доп. параметр), которые бы хотелось решить. Я потом подробнее напишу.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[2]: [Trick] Форсирование проверки возвращаемого значения
От: remark Россия http://www.1024cores.net/
Дата: 25.12.06 08:21
Оценка:
Здравствуйте, johny5, Вы писали:

J>Ну во первых нужно было прям перед заголовком вот так написать:

J>Microsoft specific
J>Я может дальше и читать бы не стал

Читай внимательнее:

В gcc для этих целей есть __attribute__((warn_unused_result)). Но что делать пользователям msvc?






J>Тут наверно таки вызов fff_wrap?


Да, конечно, описался...



J>Я так понимаю, при каждом вызове такой функции, будет инстанцироваться result_check_helper<int id>::fake()

J>У линкера башню то не порвёт?
J>

Нет. Тем более, что символ с внутренним связыванием.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re: [Trick] Форсирование проверки возвращаемого значения
От: night beast СССР  
Дата: 25.12.06 08:28
Оценка:
Здравствуйте, remark, Вы писали:

R>

Свершилось! Форсирование проверки возвращаемого значения в компайл-тайм возможно!

R>В начале несколько вводных слов, что б было понятно о чём речь:

R>Работает на msvc71/80. В рантайм оверхед нулевой.


R>


может стоит ID сделать первым параментром, на случай если у функции есть параметры по умолчанию?

PS: а что, действительно большая проблема в проверкой?
Re[3]: [Trick] Форсирование проверки возвращаемого значения
От: IROV..  
Дата: 25.12.06 10:10
Оценка:
Здравствуйте, remark, Вы писали:

R>Не вижу сильного различия между:

R>
R>fff(2, ID) ignore_result; 
R>

R>и:
R>
R>ignore_result(fff(2, ID));}
R>


вся фишка в этом

Могу еще предложить вот такой _забавный_ трюк


я не волшебник, я только учусь!
Re: [Trick] Форсирование проверки возвращаемого значения
От: Antipov  
Дата: 25.12.06 11:09
Оценка:
Здравствуйте, remark, Вы писали:

R>

Свершилось! Форсирование проверки возвращаемого значения в компайл-тайм возможно!

R>Работает на msvc71/80. В рантайм оверхед нулевой.


немного добавим для демонстрации:

template<int id> checked_result<id> fff_wrap(int param, RESULT_CHECK_PARAM)
{
    static bool first_call(true);

    if(first_call)
    {
        first_call    = false;
        std::cout << "first call " << __FUNCTION__ << std::endl;
    }
    else
    {
        std::cout << "second call " << __FUNCTION__ << std::endl;
    }
    return 0 == param;
}

int _tmain(int argc, _TCHAR* argv[])
{
    //bool b1 = fff_wrap(1, ID); // Компилируется
    
    if (fff_wrap(2, ID)); // Компилируется
    if (fff_wrap(2, ID)); // Компилируется
    std::cout << std::endl;

    for(int i = 0; i < 2; ++i)
    {
        if (fff_wrap(2, ID)); // Компилируется
    }
    _getch();
    return 0;
}


Как вы думайте сколько реализаций функции fff_wrap в бинарнике ?
Вряд ли такое поведение функции ожидается, а отказ от статических переменных в функции ИМХО слишком суров.
Re[4]: [Trick] Форсирование проверки возвращаемого значения
От: remark Россия http://www.1024cores.net/
Дата: 25.12.06 11:14
Оценка:
Здравствуйте, IROV.., Вы писали:

IRO>вся фишка в этом


IRO>

IRO>Могу еще предложить вот такой _забавный_ трюк


Забавные трюки бывают разные, например, CRTP тоже можно назвать забавным...

IRO>


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[2]: [Trick] Форсирование проверки возвращаемого значения
От: remark Россия http://www.1024cores.net/
Дата: 25.12.06 11:24
Оценка:
Здравствуйте, Antipov, Вы писали:

A>Как вы думайте сколько реализаций функции fff_wrap в бинарнике ?

A>Вряд ли такое поведение функции ожидается, а отказ от статических переменных в функции ИМХО слишком суров.


Ну вообще использоваться это должно примерно так:

template<int id> checked_result<id> fff_wrap(int param, RESULT_CHECK_PARAM)
{
  return fff(param);
}


Т.к. плохо только из-за этого вытаскивать всю реализацию в h'ник
Т.ч. проблем не будет.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[3]: [Trick] Форсирование проверки возвращаемого значения
От: _Obelisk_ Россия http://www.ibm.com
Дата: 25.12.06 13:15
Оценка:
Здравствуйте, remark, Вы писали:


R>Я думаю, это одна из тех вещей, которые не объяснить. Те, кто поняли зачем, тем понятно, а те кто не поняли, тем не объяснить.

R>Ну это типа как "А зачем программировать на С++, когда есть С?" или "Зачем использовать исключения, когда есть коды возврата?"

На эти два вопросы имеются ответы, а вот необходимости в compile-time проверки учета возвращаемого значения не вижу.



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[4]: [Trick] Форсирование проверки возвращаемого значения
От: remark Россия http://www.1024cores.net/
Дата: 25.12.06 13:32
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

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



R>>Я думаю, это одна из тех вещей, которые не объяснить. Те, кто поняли зачем, тем понятно, а те кто не поняли, тем не объяснить.

R>>Ну это типа как "А зачем программировать на С++, когда есть С?" или "Зачем использовать исключения, когда есть коды возврата?"

_O_>На эти два вопросы имеются ответы, а вот необходимости в compile-time проверки учета возвращаемого значения не вижу.


Без форсирования:
1. Неправильный код написать легче, чем правильный
2. Не явны намерения программиста: он забыл проверить или хотел это сделать?
3. Код менее читабельный: f() — а эта функция что-то ещё и возвращает?

Форсирование решает все эти проблемы.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[2]: [Trick] Форсирование проверки возвращаемого значения
От: Vain Россия google.ru
Дата: 25.12.06 17:06
Оценка:
Здравствуйте, rm822, Вы писали:

R>Да вы батенька знаете толк в извращениях. Знатный велосипед.

R>Это все фигня. Вы воспользовались MS-extention __if_not_exist, а раз вы им воспользовались то заведомо прилипли к платформе
R>У MS есть решение подобного рода встроеное в компилер, которое кстати сказать работает на порядок лучше

R>
R>// C++
R>#include <codeanalysis\sourceannotations.h>
R>using namespace vc_attributes;
R>[returnvalue:Post(MustCheck=Yes)] int fff();
R>


R>я получил такой вот варнинг

R>warning C6031: Return value ignored: 'fff'

R>PS:для этого надо врубить code-analysys в свойствах проекта.

Весь флейм зря..
токо вот у меня:
Compiling...
cl : Command line warning D9040 : ignoring option '/analyze'; Code Analysis warnings are not available in this edition of the compiler

SP1?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[3]: [Trick] Форсирование проверки возвращаемого значения
От: rm822 Россия  
Дата: 25.12.06 17:33
Оценка:
Здравствуйте, Vain, Вы писали:
V>SP1?
ХЗ, у меня TeamSuite , а в MSDN не написано про то в каких эдишнах это работает.
Сам пользуюсь мне нравится, анализ хороший хотя и не быстрый, варнингов много. В паре с C++ test так вообще отлично.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: [Trick] Форсирование проверки возвращаемого значения
От: Vain Россия google.ru
Дата: 25.12.06 19:05
Оценка:
Здравствуйте, rm822, Вы писали:

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

V>>SP1?
R>ХЗ, у меня TeamSuite , а в MSDN не написано про то в каких эдишнах это работает.
R>Сам пользуюсь мне нравится, анализ хороший хотя и не быстрый, варнингов много. В паре с C++ test так вообще отлично.
Я уже потом подумал про team suit, хотя уже нашёл:
/analyze is only available in Enterprise (team development) versions for x86 compilers.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[2]: [Trick] Форсирование проверки возвращаемого значения
От: remark Россия http://www.1024cores.net/
Дата: 25.12.06 21:27
Оценка:
Здравствуйте, rm822, Вы писали:

R>Да вы батенька знаете толк в извращениях.


Да Вы батенька знаете толк в продуктах за $2000.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[6]: А может по-человечески как-то это сделать? :)
От: remark Россия http://www.1024cores.net/
Дата: 26.12.06 09:40
Оценка:
Здравствуйте, Erop, Вы писали:

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


R>>Без форсирования:

R>>1. Неправильный код написать легче, чем правильный
E>Называй функции понятнои с простой и ясной семантикой, избегая при этом всяких синтаксических трюков и неявно генерирующегося и вызываемого кода -- и будет тебе счастье

Ну вот например. И чего? И что отсюда следует?
CopyFile(lpExistingFileName, lpNewFileName, FALSE);


R>>2. Не явны намерения программиста: он забыл проверить или хотел это сделать?

E>Ну коглда программист вменяемый, то и не страшно, а когда невменяемый, то он обойдёт твою приблуду на раз-два-три

Во-первых, это будет видно, что здесь что-то обойдено (сравните с "здесь не будет ничего видно").
Во-вторых, раз уж надо что-то обходить, то уже есть шанс, что программист задумается, может ему не обойти, а сделать нормальную проверку.
Обратный вариант — программист просто пишет минимум кода без проверки, этого не видно, не понятно, он это хотел или забыл.


R>>3. Код менее читабельный: f() — а эта функция что-то ещё и возвращает?

E>Ну вот скажи, про какую из функций не понятно возвращает она что-то или нет?
E>
E>EvalVariantQuality( ... );
E>CloseAllActiveConnections( ... )
E>CopyFiles( ... );
E>


Ни про какую.


E>Может просто отказаться от возврата кодов ошибок, а API всегда звать через C++ warper?


Так подожди, ты сам за что? что бы надеяться на мифического вменяемого, неленивого, у_которого_всегда_есть_время, который_не_работает_поздно, который_не_работает_по_14_часов, который_ничего_не_забывает и_т_д программиста, или за то, что бы делать интерфейс, который трудно использовать неправильно при любых обстоятельствах?

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


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

E>Скажем функция CopyFiles( ... ) ничего не возвращает, а GetCopiedFilesCount() -- возвращает
E>А, скажем такая или анологичная конструкция:
E>class CFilesCopyist {
E>public:
E>    CFilesCopyist();
E>    CFilesCopyist( const char* Src, const char* Dst, DWORD mode );
E>    ~CFilesCopyist();

E>    //   Установка дополнительных параметров
E>    void SetSrcPath( const char* );
E>    void SetDstPath( const char* );
E>    void SetWildcard( const char* );

E>    void SetCopyMode( DWORD mode );
E>    bool IsParamsCorrect();

E>    void CopyFiles();

E>    int GetCopiedFilesCount() const;
E>};


E>Вообще искоренит проблему на корню


Какаим образом?

R>>Форсирование решает все эти проблемы.


E>Короче, ИМХО, лучше подходить с другого конца. Не заставлять при помощи плохо переносимых и очень сложных и не особо понятных трюков программиста делать то, что делать на самом деле неудобно, а так обустроить архитектуру и технологию программирования, что неудобные действия станут ненужными


Это замечательно... если возможно. Опять же исключения решают проблему.
Можно поглядеть здесь статья "A Return Type That Doesn’t Like Being Ignored".
Есть по-крайней мере 2 случая, когда это не возможно:
1. Исключения использовать нельзя — это предусловие
2. Исключения не прикрутишь к интерфейсу. Вот пример:

class DBCmd
{
...
   bool Fetch();
...
};


Очень удобно использовать так:

DBCmd cmd;
...
while (cmd.Fetch())
{
  ...
}


Для одной записи, это должно выглядеть так:

DBCmd cmd;
...
if (!cmd.Fetch())
  обработка_ошибки


Но, к сожалению, очень часто пишется такой код:
DBCmd cmd;
...
cmd.Fetch();


С объяснениями типа — ну эта запись там должна быть всегда...


R>>

E>Да не вопрос!

1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[7]: А может по-человечески как-то это сделать? :)
От: rg45 СССР  
Дата: 26.12.06 09:48
Оценка:
"_Obelisk_" <18435@users.rsdn.ru> wrote in message news:2280075@news.rsdn.ru...
> Здравствуйте, Erop, Вы писали:
>
> ...
> Со всем согласен. От себя добавлю, что так же полезно писать к функциям нормальные комментарии и не лениться их читать. Если обработка возвращаемого значения необходима — не поленитесь и отразите это в комментарии.

Ксожалению, в том месте, где функция используется, этот комментарий не виден. Да и неудобно при чтении текста программы для каждой функции искать ее объявление для того, чтобы почитать комментарий. Гораздо лучше, если названия функций говорят сами за себя и не нуждаются в комментариях.
Posted via RSDN NNTP Server 2.0
--
Не можешь достичь желаемого — пожелай достигнутого.
Re[2]: [Trick] Форсирование проверки возвращаемого значения
От: remark Россия http://www.1024cores.net/
Дата: 26.12.06 09:53
Оценка:
Здравствуйте, _Winnie, Вы писали:

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


_W>Прикольно, но ИМХО неудобства написания шаблонного враппера к каждому нешаблонному методу здесь слишком большие.


Согласен. Это всё есть. Но это отправная точка, а не законченный солюшн. Смотри мой ответ здесь
Автор: remark
Дата: 25.12.06


Если вы думаете, что, я считаю, что вызов "f()" — это слишком просто и не катит, и что обязательно надо к нему навернуть макросов, доп параметров, шаблонов и т.д. То это не так. Мне просто "f()" тоже гораздо больше нравится. Но тут это была необходимость.


_W>И это не удовлетворяет более ранним требования — "есть дофига старого кода, хочу проверить ошибки там" — нужен параметр ID.


Это отдельно от того




_W>Я бы выбрал или runtime-проверку с тестрованием, или трюк с двумя проходами компиляции — http://www.rsdn.ru/Forum/?mid=1698165&amp;flat=0
Автор: Erop
Дата: 25.02.06

_W>или code guide с написанием скрипта — "эту функцию можно вызывать только так — ^bool :i = foo\(.*\);$ и как if \(.*foo" (это не реальные регэкспы а просто как начинать их писать)
_W>Можно даже скрипт не писать, а сразу Edit->Find In Files. И заграть в макрокнопку студии.

А разьве не приятнее просто компилировать программу как всегда, и что бы компилятор показывал ошибки?



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[2]: [Trick] Форсирование проверки возвращаемого значения
От: remark Россия http://www.1024cores.net/
Дата: 26.12.06 10:07
Оценка:
Здравствуйте, rm822, Вы писали:

R>Да вы батенька знаете толк в извращениях. Знатный велосипед.

R>Это все фигня. Вы воспользовались MS-extention __if_not_exist, а раз вы им воспользовались то заведомо прилипли к платформе

Я прилип к платформе ещё до этого, когда появилось требование разработки под win32 на msvc. И я думаю, что я не одинок.
Прилипание к самой распространённой платформе и самому распространённому компилятору имхо не так страшно.
И я это указал в начале поста.


R>У MS есть решение подобного рода встроеное в компилер, которое кстати сказать работает на порядок лучше

R>PS:для этого надо врубить code-analysys в свойствах проекта.

Это замечательно. Вы совсем плохо обо мне думаете.
Но это работает только под msvc80 enterprise, и сдаётся мне, что раз аттрибуты, то ещё и c++/cli.
Хотелось бы решение для msvc71/80 всех версий, и без cli.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[8]: А может по-человечески как-то это сделать? :)
От: remark Россия http://www.1024cores.net/
Дата: 26.12.06 10:10
Оценка:
Здравствуйте, igna, Вы писали:

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


_O_>>От себя добавлю, что так же полезно писать к функциям нормальные комментарии и не лениться их читать.


I>Ты прав. Но если что-то можно выразить на языке программирования, использовать для этого комментарий не стоит.


Рад, что хоть кто-то меня понимает, зачем я это делаю.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[8]: А может по-человечески как-то это сделать? :)
От: remark Россия http://www.1024cores.net/
Дата: 26.12.06 10:20
Оценка:
Здравствуйте, rg45, Вы писали:


R>Гораздо лучше, если названия функций говорят сами за себя и не нуждаются в комментариях.


Согласен. Но ещё лучше, если потом компилятор проверит правильность написанного кода


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[3]: [Trick] Форсирование проверки возвращаемого значения
От: rm822 Россия  
Дата: 26.12.06 10:53
Оценка:
Здравствуйте, remark, Вы писали:

R>Это замечательно. Вы совсем плохо обо мне думаете.

Я хорошо думаю о вас, но то что вы изобретаете это конечно интересно но не более того, С++ не приспособлен для контрактного программирования (compile-time) и этим все сказано.
R>Но это работает только под msvc80 enterprise, и сдаётся мне, что раз аттрибуты, то ещё и c++/cli.
Это работает без cli.

PS: 2000$ — существенная сумма для отдельного человека а не для комманды — если ваша комманда решила серьезно этим заняться 2кб не препятствие, к тому же trial 180 дневный кажется никто не отменял.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: [Trick] Форсирование проверки возвращаемого значения
От: remark Россия http://www.1024cores.net/
Дата: 26.12.06 12:25
Оценка:
Здравствуйте, rm822, Вы писали:

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


R>>Это замечательно. Вы совсем плохо обо мне думаете.

R>Я хорошо думаю о вас, но то что вы изобретаете это конечно интересно но не более того, С++ не приспособлен для контрактного программирования (compile-time) и этим все сказано.

Имхо "интересные" вещи очень ценны. Возможно в данном применении она ("интересная" вещь) воплотилась не в полностью практическом решении. Зато возможно позднее кто-то сделает на её основе что-то действительно практическое и с превосходными характеристиками, чего без этой "интересной" вещи сделать было бы нельзя.
В boost можно найти много примеров "интересных" вещей, которые тем не менее воплотились в очень практические решения.
Например, sfinae многие (и я) несколько лет назад воспринимали как "интересную" и "забавную" фичу.


R>>Но это работает только под msvc80 enterprise, и сдаётся мне, что раз аттрибуты, то ещё и c++/cli.

R>Это работает без cli.

Они дабавили аттрибуты (которые в []) и в с++? А рефлекшн есть?



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[5]: [Trick] Форсирование проверки возвращаемого значения
От: rm822 Россия  
Дата: 26.12.06 12:52
Оценка:
Здравствуйте, remark, Вы писали:

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


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


R>>>Это замечательно. Вы совсем плохо обо мне думаете.

R>>Я хорошо думаю о вас, но то что вы изобретаете это конечно интересно но не более того, С++ не приспособлен для контрактного программирования (compile-time) и этим все сказано.

R>Имхо "интересные" вещи очень ценны. Возможно в данном применении она ("интересная" вещь) воплотилась не в полностью практическом решении. Зато возможно позднее кто-то сделает на её основе что-то действительно практическое и с превосходными характеристиками, чего без этой "интересной" вещи сделать было бы нельзя.

Очень(!) некоторые ценны, остальные просто интересны.

R>Они дабавили аттрибуты (которые в []) и в с++? А рефлекшн есть?

Вроде бы нет. Есть интеграция с БД, все эти занудные стандартные обертки для таблиц. Что-то для комов добавили.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: А может по-человечески как-то это сделать? :)
От: Erop Россия  
Дата: 26.12.06 14:51
Оценка:
Здравствуйте, remark, Вы писали:

_O_>>Со всем согласен. От себя добавлю, что так же полезно писать к функциям нормальные комментарии и не лениться их читать. Если обработка возвращаемого значения необходима — не поленитесь и отразите это в комментарии.


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


А может таки попробовать семантику функций продумывать?
Чтобы не было смысла вызывать функци, игнорируя её значение?

R>
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[9]: А может по-человечески как-то это сделать? :)
От: igna Россия  
Дата: 27.12.06 12:50
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

_O_>Отсюда не следует, что лучше городить изврат, чем писать комментарий.


Конечно не следует. Но понятия "изврат" и "нормальный комментарий"
Автор: _Obelisk_
Дата: 25.12.06
субьективны.
Re: [Trick] Форсирование проверки возвращаемого значения
От: np9mi7 Россия  
Дата: 11.01.07 13:42
Оценка:
Здравствуйте, 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] Форсирование проверки возвращаемого значения
От: remark Россия http://www.1024cores.net/
Дата: 20.01.07 15:28
Оценка:
Здравствуйте, np9mi7, Вы писали:

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


R>>В gcc для этих целей есть __attribute__((warn_unused_result)). Но что делать пользователям msvc? (забить на msvc и перейти на gcc не предлагать )


N>Не являюсь пользователем g++, но неужели расширение языка в виде __attribute__((warn_unused_result)) накладывает ограничение наличия определения и объявления в одной единице трансляции?


В смысле?
Вообще нет, не накладывает.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[3]: [Trick] Форсирование проверки возвращаемого значения
От: np9mi7 Россия  
Дата: 20.01.07 16:10
Оценка:
Здравствуйте, remark, Вы писали:

R>В смысле?


Насколько я понял, твоё решение накладывает такое ограничение, поэтому не является полноценной заменой этого расшерения (без учета дополнительного параметра);
"В любое мгновение принятия решения, лучшее, что вы можете сделать, это принять правильное решение; следующим лучшим вариантом будет принять неправильное решение, худший вариант – не принимать решения совсем" (c) Теодор Рузвельт.
Re: [Trick] Форсирование проверки возвращаемого значения
От: remark Россия http://www.1024cores.net/
Дата: 06.02.07 21:02
Оценка:
Здравствуйте, remark, Вы писали:

Если кого это интересует, то это больше не M$ SPECIFIC, это 100% PURE C++ благодаря здесь
Автор: remark
Дата: 06.02.07



R>


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re: [Trick] Форсирование проверки возвращаемого значения
От: Smooky Россия  
Дата: 07.02.07 04:43
Оценка:
Здравствуйте, remark, Вы писали:

R>

Свершилось! Форсирование проверки возвращаемого значения в компайл-тайм возможно!


А как сделать чтобы всёэто работало на msvc6.0

R>Работает на msvc71/80. В рантайм оверхед нулевой.


R>
Только Путин, и никого кроме Путина! О Великий и Могучий Путин — царь на веки веков, навсегда!
Смотрю только Соловьева и Михеева, для меня это самые авторитетные эксперты.
КРЫМ НАШ! СКОРО И ВСЯ УКРАИНА БУДЕТ НАШЕЙ!
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.