Защо стойностите на връщане дескриптори толкова несъвместими?
Защо върнатите стойности са толкова различни?
Причините, както вече подозират - исторически.
Тези стойности са избрани въз основа на анализ на съвместимостта с 16-битов Windows. 16-битов функция OpenFile, _lopen _lcreat и се връща -1 ако грешка, така че функцията CreateFile 32-битов също връща -1 (INVALID_HANDLE_VALUE), за да се улесни прилагането миграция с Win16.
(Въоръжени с това знание, вече можете да отговорите на следния прост въпрос: защо, когато имам нужда да се обадите на CreateFile, но в действителност не отворите файла не трябва да функционира, наречена OpenFile Отговор: Да, OpenFile би било по-подходящо име, но тя името вече е заето.)
От друга страна, не е имало Win16 еквиваленти за CreateThread или CreateMutex, така че те се връщат 0.
Тъй като прецедент вече установените несъответствия върна ценности, с добавянето на нова функция винаги получавате избор между връщането 0 или INVALID_HANDLE_VALUE.
Тази непоследователност има няколко последици.
Според първата, разбира се, трябва да се провери внимателно върнатата стойност.
На второ място. Това означава, че ако искате да напишете обвивка около обща стойност от ЕВРОВОК - тогава ще трябва да се прави разлика между две възможни стойности "не се справят."
На трето място, ако искате да се инициализира стойността на дръжката, тогава ще трябва да го направя по различен начин, в зависимост от функцията, с която вие ще го използвате. Например, следния код е неправилен:
В този код, две грешки. На първо място, върнатата стойност се проверява от CreateFile погрешно. горните тестове кода за 0 вместо INVALID_HANDLE_VALUE. Второ, кодът неправилно инициализира H. Това е коригираната версия:
Четвърто, трябва да сте особено внимателни с INVALID_HANDLE_VALUE на стойност: чисто случайно, то съвпада със стойността на псевдо-ЕВРОВОК върна GetCurrentProcess. Много от функциите на ядрото да вземат такива псевдо-дръжки, така че ако, например, се притеснявам и случайно наричат, например, със стойност WaitForSingleObject INVALID_HANDLE_VALUE, в крайна сметка ще откриете, че сте в очакване на текущия процес. Такова очакване, разбира се, никога няма да бъде завършен, тъй като процесът преминава в състояние на аларма само когато излезете, така че в крайна сметка в очакване на себе си.
Свързани статии