Importowanie przy użyciu plików DEF
Jeśli zdecydujesz się używać __declspec(dllimport) pliku .def wraz z plikiem .def, zmień plik .def, aby używać danych zamiast stałej, aby zmniejszyć prawdopodobieństwo, że nieprawidłowe kodowanie spowoduje problem:
// project.def
LIBRARY project
EXPORTS
ulDataInDll DATA
W poniższej tabeli przedstawiono przyczynę.
| Słowo kluczowe | Emituje w bibliotece importu | Eksporty |
|---|---|---|
CONSTANT |
_imp_ulDataInDll, _ulDataInDll |
_ulDataInDll |
DATA |
_imp_ulDataInDll |
_ulDataInDll |
Funkcja Using __declspec(dllimport) i CONSTANT wyświetla zarówno imp wersję, jak i nieużywaną nazwę w utworzonej bibliotece importu biblioteki DLL .lib, aby zezwolić na jawne łączenie. Funkcja Using __declspec(dllimport) i DATA wyświetla tylko imp wersję nazwy.
Jeśli używasz funkcji CONSTANT, do uzyskania dostępu ulDataInDlldo programu można użyć jednej z następujących konstrukcji kodu:
__declspec(dllimport) ULONG ulDataInDll; /*prototype*/
if (ulDataInDll == 0L) /*sample code fragment*/
— lub —
ULONG *ulDataInDll; /*prototype*/
if (*ulDataInDll == 0L) /*sample code fragment*/
Jeśli jednak używasz danych w pliku .def, tylko kod skompilowany z następującą definicją może uzyskać dostęp do zmiennej ulDataInDll:
__declspec(dllimport) ULONG ulDataInDll;
if (ulDataInDll == 0L) /*sample code fragment*/
Użycie stałej jest bardziej ryzykowne, ponieważ jeśli zapomnisz użyć dodatkowego poziomu pośredniego, możesz potencjalnie uzyskać dostęp do wskaźnika tabeli adresów importu do zmiennej — a nie samej zmiennej. Ten typ problemu może często występować jako naruszenie dostępu, ponieważ tabela adresów importu jest obecnie tylko do odczytu przez kompilator i konsolidator.
Bieżący konsolidator MSVC wyświetla ostrzeżenie, jeśli widzi stałą w pliku .def, aby uwzględnić ten przypadek. Jedyną rzeczywistą przyczyną używania stałej jest to, że nie można ponownie skompilować pliku obiektu, w którym plik nagłówka nie został wymieniony __declspec(dllimport) w prototypie.