const QString& 的显式模板专业化导致未解决的外部

Question

#include <QFile>
#include <QString>

// this is some sort of low-level C function
void lowLevelOpenFD(int fd)
{
    qDebug("Opened by fd: %d", fd);
}

// as well as this one
void lowLevelOpenName(const char *name)
{
    qDebug("Opened by name: %s", name);
}

// this is a wrapper around low-level functions
template<typename FileId>
void callLowLevelOpen(FileId id);

template<>
void callLowLevelOpen(const QString &fileName)
{
    lowLevelOpenName(QFile::encodeName(fileName).constData());
}

template<>
void callLowLevelOpen(int fd)
{
    lowLevelOpenFD(fd);
}

// this is the function where the most stuff happens
template<typename FileId>
void openInternal(FileId id)
{
    // lots of useful stuff goes here
    // now we call one of the two low level functions
    callLowLevelOpen(id);
    // more useful stuff
}

// this is high-level interface to the "open by name" function
void openFile()
{
    QString name = "file";
    openInternal(name);
}

// this is high-level interface to the "open by FD" function
void openFile(int fd)
{
    openInternal(fd);
}

int main()
{
    openFile();
    openFile(17);
    return 0;
}

问题在于，据我所知，上面的示例会发生

error LNK2019: unresolved external symbol "void __cdecl callLowLevelOpen<class QString>(class QString)" (??$callLowLevelOpen@VQString@@@@YAXVQString@@@Z) referenced in function "void __cdecl openInternal<class QString>(class QString)" (??$openInternal@VQString@@@@YAXVQString@@@Z)

这种情况，因为编译器在从第一个高级重载调用时会实例化 openInternal() 。好吧，于是我思考并修改了代码：

// this is high-level interface to the "open by name" function
void openFile()
{
    QString name = "file";
    openInternal<const QString&>(name);
}

同样的问题。我以为我告诉编译器实例化 openInternal，那么为什么它仍然抱怨 呢？我也尝试过这个：

// this is high-level interface to the "open by name" function
void openFile()
{
    QString name = "file";
    openInternal<const QString&>(static_cast<const QString&>(name));
}

现在这看起来很愚蠢，但仍然不起作用。我无法显式地专门化 openInternal() 一个，因为它太大了，而这种模板化混乱的目的就是为了避免不必要的代码重复。我不能仅仅重命名低级函数来将它们变成重载函数，因为它们位于第三方 C 库中。我唯一能做的就是将第一个 callLowLevelOpen() 专业化替换为

template<>
void callLowLevelOpen(QString fileName)
{
    lowLevelOpenName(QFile::encodeName(fileName).constData());
}

Then it Works。性能损失几乎为零，因此这是一个完全有效的解决方法，但我只想了解这里发生了什么。

上面的代码只是一个SSCCE，真正的代码是 有如果有人感兴趣的话。此特定问题与 gzopen()/gzdopen()、QuaGzipFilePrivate::open() 和 QuaGzipFile::open() 函数有关。

Answer 1

由于您实际上更改了签名，我认为您实际上不想专门化您的函数模板，而是使用重载。这是使用 std::string 的完整测试程序（如果问题也可以在那里重现，我不知何故更喜欢仅依赖于标准类）：

#include <string>

template <typename T> void f(T);
// #define BROKEN
#if defined(BROKEN)
template <> void f(std::string const&) {}
#else
void f(std::string const&) {}
#endif

int main()
{
    std::string s;
    f(s);
}

如果您在这段代码将不起作用。

出现此行为的原因是编译器根据主模板选择重载。这永远不会添加 const& 部分。完成此操作后，编译器会查找所选重载的潜在特化。由于这永远不会推导出用于专业化的符号，因此不会被拾取。

那么为什么 f(s) 没有获得专业化呢？对我来说，尝试使用 gcc 和 clang 。