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

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

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

result r = foo( ... );

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

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

Здравствуйте, 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>
Да не вопрос!

Да вы батенька знаете толк в извращениях. Знатный велосипед.
Это все фигня. Вы воспользовались 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 в свойствах проекта.

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

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

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

Здравствуйте, 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?

Здравствуйте, Vain, Вы писали:
V>SP1?
ХЗ, у меня TeamSuite , а в MSDN не написано про то в каких эдишнах это работает.
Сам пользуюсь мне нравится, анализ хороший хотя и не быстрый, варнингов много. В паре с C++ test так вообще отлично.

Здравствуйте, 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.

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

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

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

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

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

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

Write code instead of comments where possible.

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

Здравствуйте, 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>Да не вопрос!

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

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

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

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

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

"_Obelisk_" <18435@users.rsdn.ru> wrote in message news:2280075@news.rsdn.ru...
> Здравствуйте, Erop, Вы писали:
>
> ...
> Со всем согласен. От себя добавлю, что так же полезно писать к функциям нормальные комментарии и не лениться их читать. Если обработка возвращаемого значения необходима — не поленитесь и отразите это в комментарии.

Ксожалению, в том месте, где функция используется, этот комментарий не виден. Да и неудобно при чтении текста программы для каждой функции искать ее объявление для того, чтобы почитать комментарий. Гораздо лучше, если названия функций говорят сами за себя и не нуждаются в комментариях.

Здравствуйте, _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. И заграть в макрокнопку студии.

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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

PS: 2000$ — существенная сумма для отдельного человека а не для комманды — если ваша комманда решила серьезно этим заняться 2кб не препятствие, к тому же trial 180 дневный кажется никто не отменял.

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

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

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

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


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

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

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

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

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

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

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

R>Они дабавили аттрибуты (которые в []) и в с++? А рефлекшн есть?
Вроде бы нет. Есть интеграция с БД, все эти занудные стандартные обертки для таблиц. Что-то для комов добавили.

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

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

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