По какой причине мне не следует добавлять проверку GUID в мою программу Visual C++?

Чтобы сделать мою программу Visual C++ более надежной, у меня возникает соблазн вставить проверки того, что GUID переменные содержат допустимые GUID версии 4 ( и не остаются неинициализированными):

GUID guid;
UuidCreate( &guid );
// many lines of code later...
// the following assert should not fire for valid version 4 GUIDs
int data3 = guid.Data3;
assert( ( data3 >> 12 ) == 4 );

Я полностью уверен, что все идентификаторы GUID либо обычно поступают из функции UuidCreate(), либо представляют собой неинициализированные переменные (и последнее — это то, что я хотел бы диагностировать с помощью этих проверок). Меня беспокоит только то, что Microsoft может внезапно изменить реализацию GUID в будущих версиях Windows.

Какие еще факторы я должен учитывать, чтобы решить, не повредят ли такие проверки? Также насколько вероятно, что реализация GUID изменится в будущих версиях Windows?


windows error-handling guid visual-c++
person sharptooth    schedule 21.12.2010    source источник
comment
Почему вы считаете, что вам нужно проверять идентификаторы GUID из UuidCreate?   -  person KristoferA    schedule 21.12.2010
comment
@KristoferA - Huagati.com: Это только для иллюстрации, реальная проблема заключается в том, что может быть передан неинициализированный GUID, что указывает на ошибку проектирования в моей программе.   -  person sharptooth    schedule 21.12.2010

Ответы (2)


arrow_upward
4
arrow_downward

Меня беспокоит только то, что Microsoft может внезапно изменить реализацию GUID в будущих версиях Windows.

Смиритесь с этим, если это произойдет. Нет, серьезно, вы также можете беспокоиться о реализации integer, Microsoft может решить переключиться на типы данных .NET и сделать integer общесистемным 4-байтовым значением.

Беспокоитесь о других вещах, если реализации меняются, вам все равно придется переписать/изменить/исправить вашу программу.

Редактировать: если я вас правильно понял, вы беспокоитесь о возвращаемом значении функции, а не о самой структуре GUID. И вы имеете в виду, что на данный момент он может возвращать либо GUID, либо неинициализированное значение, но в будущих реализациях он может возвращать GUID с нулевым заполнением?

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

person Bobby    schedule 21.12.2010
comment
Согласен с Бобби. Беспокоиться о каком-то неясном и постоянно меняющемся API может быть разумно, но беспокоиться о том, что базовый тип будет изменен где-то в будущем, совершенно бесполезно. - person Albireo; 21.12.2010
comment
@kappa: Меня не беспокоит сама структура GUID - меня беспокоит алгоритм, который создает значения. - person sharptooth; 21.12.2010
comment
@sharptooth: я отредактировал свой ответ, надеюсь, я правильно вас понял. - person Bobby; 21.12.2010
comment
@sharptooth, поскольку утверждения влияют только на отладочные сборки, я бы сказал, что об этом не стоит беспокоиться. Если однажды все эти утверждения начнут срабатывать, их всегда можно удалить или обновить, чтобы они соответствовали новому формату. Важно делать утверждения внутри хорошо названной встроенной функции, чтобы а) было очевидно, что они тестируют, и б) вам нужно обновить только одну вещь, если вам нужно обновить/удалить утверждение в будущем. - person Leo Davidson; 21.12.2010
comment
Ну, если вы беспокоитесь о том, что Microsoft изменит реализацию UuidCreate, мне кажется, что это слишком много: эта функция всегда должна возвращать действительный GUID, действительно ли имеет значение, версия ли это 4, 5, 6 или 8723? Если вас беспокоит просто то, что функция не возвращает никакого значения, инициализируйте переменную перед вызовом функции чем-то известным, скажем, всеми нулями, и проверьте после функции, является ли значение все еще нулями. - person Albireo; 21.12.2010
comment
@kappa: Если я вставлю эту проверку, а Microsoft изменит реализацию так, что будет, скажем, 7 или просто любое значение, где я ожидаю 4, эти проверки не пройдут, даже если реальной проблемы нет, и мне придется отредактировать и повторно отправить мою программу. - person sharptooth; 21.12.2010
comment
@sharptooth: Тогда почему бы просто не использовать эти утверждения в отладочных сборках? Если вы не можете быть на 100% уверены, что утверждение действительно, то оно не относится к сборке релиза, но все же может быть полезно для обнаружения ошибок во время разработки. - person Leo Davidson; 21.12.2010
comment
Я добавил проверку только для сборок, которые не отправляются пользователю. Думаю, это будет лучшее решение - ничего не сломается. - person sharptooth; 26.01.2011

arrow_upward
2
arrow_downward

Что ж, давайте посмотрим... вы вызываете UuidCreate, не имея возможности указать конкретную версию GUID, и вы ожидаете взамен конкретную версию? Как это хорошая идея?

Если вы пытаетесь сделать свое программное обеспечение «более надежным», как насчет инициализации ваших переменных и проверки на наличие ошибок?

GUID guid = {0};
if (SUCCEEDED(UuidCreate( &guid ) ) {
    // you can be _pretty_ sure guid has some valid stuff in it
}
person martona    schedule 21.12.2010
comment
Хорошо, но что, если некоторые из таких инициализаторов каким-то образом обойдены из-за ошибочного кода? Я хотел бы поймать явно недопустимые значения GUID позже. - person sharptooth; 22.12.2010