Реализовать функцию из C++ в C# (MAKE_HRESULT - функция Windows)

Question

У меня есть такой код в C++

#define dppHRESULT(Code) \ 
    MAKE_HRESULT(1, 138, (Code)) 

     long x = dppHRESULT(101); 

результата является й = -2138439579.

MAKE_HRESULT является функцией окна и определяется как

#define MAKE_HRESULT(sev,fac,code) \ 
    ((HRESULT) (((unsigned long)(sev)<<31) | ((unsigned long)(fac)<<16) | ((unsigned long)(code)))) 

мне нужно повторить это в C#. Так что я написал этот код:

public static long MakeHResult(uint facility, uint errorNo) 
     { 
      // Make HR 
      uint result = (uint)1 << 31; 
      result |= (uint)facility << 16; 
      result |= (uint)errorNo; 

      return (long) result; 
     } 

И позвони, как:

// Should return type be long actually?? 
    long test = DppUtilities.MakeHResult(138, 101); 

Но я получаю другой результат, test = 2156527717.

Почему? Может кто-то, пожалуйста, помогите мне повторить эту функцию C++ также в C#? Так что я получаю аналогичный вывод на аналогичных входах?

---

Альтернативная реализация.

Если я использую эту реализацию

public static long MakeHResult(ulong facility, ulong errorNo) 
     { 
      // Make HR 
      long result = (long)1 << 31; 
      result |= (long)facility << 16; 
      result |= (long)errorNo; 

      return (long) result; 
     } 

это работает на входе 101. Но если я вход -1, то C++ возвращает -1 как результат в то время как C# возвращает 4294967295. Почему?

Я бы очень признателен за помощь, поскольку я застрял с ней.

Answer 1

Я переписал функцию как эквивалент C#.

static int MakeHResult(uint facility, uint errorNo) 
{ 
    // Make HR 
    uint result = 1U << 31; 
    result |= facility << 16; 
    result |= errorNo; 

    return unchecked((int)result); 
} 

C# является более строгим о подписанном/без знака преобразования, в то время как исходный код C не обращал внимания на это. Смешение подписи и неподписанных типов обычно приводит к головным болям.

Как Бен Вейгт упоминает в своем ответе, существует различие в названии типов между двумя языками. long в C на самом деле int в C#. Оба они относятся к 32-битным типам.

U в 1U означает «это целое число без знака». (Краткое обновление: подписанные типы могут хранить отрицательные числа, неподписанные типы не могут.) Вся арифметика в этой функции выполняется без знака, а окончательное значение просто переносится на знаковое значение в конце. Это ближайшая аппроксимация исходного макроса C.

unchecked требуется здесь, потому что в противном случае C# не позволит вам преобразовать значение, если оно выходит за пределы целевого типа, даже если бит идентичны. Переключение между подписанным и unsigned обычно требует этого, если вы не возражаете, что значения отличаются, когда вы имеете дело с отрицательными числами.

Answer 2

Вы рассчитываете его в неподписанном типе (uint). Поэтому сдвиги будут вести себя соответственно. Попробуйте вместо этого использовать int и посмотрите, что произойдет.

Ключ здесь в том, что 2156527717 как неподписанный int такой же, как -2138439579 как подписанный int. Они буквально одни и те же.

Answer 3

В компиляторах Windows C++ long - 32 бит. В C# long - 64-разрядный. Ваше преобразование C# этого кода не должно содержать ключевое слово типа long.

SaxxonPike предоставил правильный перевод, но в его пояснении (-ях) отсутствует эта важная информация.

Ваш промежуточный результат - это 32-разрядное целое без знака. В версии C++ приведение выполняется под 32-битовое значение, что приводит к тому, что высокий бит интерпретируется как знаковый бит. Код SaxxonPike делает это также. Результат отрицательный, если промежуточное значение имеет самый старший бит.

В исходном коде в вопросе листинг относится к 64-битной подписанной версии, которая сохраняет старый старший бит как нормальную двоичную цифру и добавляет новый бит знака (всегда ноль). Таким образом, результат всегда положителен. Несмотря на то, что низкие 32-биты точно соответствуют 32-битовому результату в C++, в версии C#, возвращающей long, то, что будет битом знака в C++, не рассматривается как бит знака.

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