История изменений
Исправление
sambist,
(текущая версия)
:
В документации на апи сказано передать enum, а юзер сложил какую-то фигню и получил не то, что хотел, но то что написал. Можно ещё вписать константу из другого енума[1]. Можно ещё не знать чем три режима отличаются и написать от балды. От этого защиты нет.
Если так идти, то можно вообще никакой защиты не делать на одновременные флаги - типа написал ты ALIASED | ANTIALIASED, получил UB, а чего ты, собственно, хотел добиться? Можно опустить все проверки на наличие элемента в хранилище:
LOG(SmlFontCreate(&fnt1, "Ubuntu", SML_FONT_REGULAR));
LOG(SmlGradientSetColour(>>> fnt1 <<<, SML_GRAD_MAX * 1.0, 0x0000FF)); // Несовместимая функция
SmlIndex win1;
LOG(SmlWindowVisibleSet(win1, SML_VISIBLE)); // Не было вызова WindowCreate
Но я делаю такие защиты по мере сил, несмотря на то, что они у меня занимают эдак 25% времени исполнения в отдельных случаях (ну не нашел я более оптимального способа поиска элемента в хранилище кроме как банального цикла).
Вот только издержки такого подхода вы уже описали в [1].
Была мысль сделать две верлии библиотеки - debug и release:
SmlErrors SmlButtonPositionGet(SmlIndex index, SmlPoint * pos)
{
#ifdef DEBUG
SML_CHECKELEM(index, SML_ELEM_BUTTON, SML_ERR_BADBUTTON);
SML_CHECKPTR(pos);
#endif // DEBUG
#ifdef DEBUG
SML_CHECKLOC(
#endif // DEBUG
SmlWindowPositionGet(warehouse.elem[index].data.btn.window, pos)
#ifdef DEBUG
);
#endif // DEBUG
return SML_ERR_SUCCESS;
}
Вот только код становится похож на новогоднюю елку и все равно, если идти идеальным путем и сначала написать проект на debug версии библиотеки, а потом подложить release, да, будет прирост скороси в 25+%, вот только где гарантия что все юнит-тесты были прогнаны правильно, что все были проверены результаты выполнения всех функций? Сейчас же как пишут люди, воспитанные этими вашими плюсами?
int func(int x)
{
if (x > 5) return x;
else return 0;
}
////
func(5);
func(6);
func(-1);
Без всяких проверок результата. «Если функция возвращает код ошибки он должен быть проверен» - когда вы в последний раз сталкивались с соблюдением этого правила?
Исходная версия
sambist,
:
В документации на апи сказано передать enum, а юзер сложил какую-то фигню и получил не то, что хотел, но то что написал. Можно ещё вписать константу из другого енума[1]. Можно ещё не знать чем три режима отличаются и написать от балды. От этого защиты нет.
Если так идти, то можно вообще никакой защиты не делать на одновременные флаги - типа написал ты ALIASED | ANTIALIASED, получил UB, а чего ты, собственно, хотел добиться? Можно опустить все проверки на наличие элемента в хранилище:
LOG(SmlFontCreate(&fnt1, "Ubuntu", SML_FONT_REGULAR));
LOG(SmlGradientSetColour(>>> fnt1 <<<, SML_GRAD_MAX * 1.0, 0x0000FF)); // Несовместимая функция
SmlIndex win1;
LOG(SmlWindowVisibleSet(win1, SML_VISIBLE)); // Не было вызова WindowCreate
Но я делаю такие защиты по мере сил, несмотря на то, что они у меня занимают эдак 25% времени исполнения в отдельных случаях (ну не нашел я более оптимального способа поиска элемента в хранилище кроме как банального цикла).
Вот только издержки такого подхода вы уже описали в [1].
Была мысль сделать две верлии библиотеки - debug и release:
SmlErrors SmlButtonPositionGet(SmlIndex index, SmlPoint * pos)
{
#ifdef DEBUG
SML_CHECKELEM(index, SML_ELEM_BUTTON, SML_ERR_BADBUTTON);
SML_CHECKPTR(pos);
#endif // DEBUG
#ifdef DEBUG
SML_CHECKLOC(
#endif // DEBUG
SmlWindowPositionGet(warehouse.elem[index].data.btn.window, pos)
#ifdef DEBUG
);
#endif // DEBUG
return SML_ERR_SUCCESS;
}
Вот только код становится похож на новогоднюю елку и все равно, если идти идеальным путем и снала написать проект на debug версии библиотеки, а потом подложить release, да, будет прирост скороси в 25+%, вот только где гарантия что все юнит-тесты были прогнаны правильно, что все были проверены результаты выполнения всех функций? Сейчас же как пишут люди, воспитанные этими вашими плюсами?
int func(int x)
{
if (x > 5) return x;
else return 0;
}
////
func(5);
func(6);
func(-1);
Без всяких проверок результата. «Если функция возвращает код ошибки он должен быть проверен» - когда вы в последний раз сталкивались с соблюдением этого правила?