C++ LoadLibrary使用LPCTSTR

我想用LoadLibrary开发一个插件系统
我的问题是：我希望我的函数采用

constchar*

，而

LoadLibrary

采用

LPCTSTR

我有一个好主意去做

（LPCSTR）path

，它一直给我一个module not found错误

当前代码如下。如果我取消注释widepath=L..行，它工作正常。我读过使用MFC的解决方案，但我不想使用MFC

当前代码：

bool PluginLoader::Load(char *path)
{
    path = "Release\\ExamplePlugin.dll";
    LPCTSTR widepath = (LPCTSTR)path;
    //widepath = L"Release\\ExamplePlugin.dll";

    HMODULE handle = LoadLibrary(widepath);
    if (handle == 0)
    {
        printf("Path: %s\n",widepath );
        printf("Error code: %d\n", GetLastError());

        return false;
    }

    int (*load_callback)() = (int (*)()) GetProcAddress(handle, "_plugin_start@0");

    if (load_callback == 0)
    {
        return false;
    }

    return load_callback() == LOAD_SUCCESS;
}

使用LoadLibraryA（），它接受常量char*

---

接受字符串的Winapi函数有两个版本，一个是接受Ansi字符串的A版本，另一个是接受宽字符串的W版本。函数名有一个宏，比如LoadLibrary，它可以扩展到a或W，这取决于是否定义了UNICODE。您正在使用有效的#define编译程序，因此获得LoadLibraryW（）。简单地作弊并使用LoadLibraryA（）。

我建议您使用

TCHAR

和

LoadLibrary

而不是手动使用

char

或

wchar\u t

和

LoadLibraryA

来创建UNICODE和ASCII字符的通用应用程序

所以你可以做：

TCHAR x[100]=文本（“某些文本”）

我建议你读书
LPCTSTR
是一个
const TCHAR*

为什么使用
LoadLibrary
而不是
LoadLibraryW
或
LoadLibraryA
？要支持UNICODE和ASCII而不创建两个不同的程序，一个用于
char
，另一个用于
wchar\t

另外，请看一下Microsoft对此的看法：
如果继续对参数使用
char*
，您将遇到文件名中使用了异常字符，LoadLibrary将失败的情况。将该函数改为使用wchar\t，并且在使用该函数时使参数
const
，因为您没有修改字符串

bool PluginLoader::Load(const wchar_t *path)

我想您会发现，32位Windows上的LPCTSTR是一个宏，当程序选项设置为Unicode时，它会扩展为
常量wchar*
。
使用
LoadLibrary
的认可方法是不使用
字符常量*
，而是使用
TCHAR常量*
，并对所有文字使用
\u T
宏：

bool PluginLoader::Load(TCHAR const *path) {

    path = _T("Release\\ExamplePlugin.dll");

    HMODULE handle = LoadLibrary(path);
    if (handle == 0)
    {
        _tprintf(_T("Path: %s\n"),widepath );
        _tprintf(_T("Error code: %d\n"), GetLastError());

        return false;
    }

    int (*load_callback)() = (int (*)()) GetProcAddress(handle, _T("_plugin_start@0"));

    if (load_callback == 0)
    {    
        return false;
    }    
    return load_callback() == LOAD_SUCCESS;
}

当定义了
\u UNICODE
/
UNICODE
时，这将自动使用
LoadLibraryW
，当未定义时，将自动使用
LoadLibraryA
。类似地，
\u T
将在相同的基础上给出窄字符串或宽字符串文本，因此它们都保持同步

我通常更喜欢显式地使用
W
后缀函数，并在字符串文本上使用
L
前缀。Windows在内部几乎只处理宽字符串，因此采用窄字符串文字的版本
A
-后缀版本大多是小存根，它们将参数转换为宽字符串，然后调用宽字符串版本。直接使用宽字符串版本可以节省时间和内存

Windows中的窄字符串支持最初主要是为了与早已不存在的缺少宽字符串支持的Windows 95/98/SE/Me系列兼容。这些已经过去了相当长的一段时间，所以现在使用窄文本的唯一原因是因为这是一些外部来源提供给您的。
这就是为什么这个网站存在的原因，它涵盖了不直观的；-）