如何使用 #includes 强制 Visual Studio 预处理器区分大小写?

发布于 2024-07-27 23:55:07 字数 187 浏览 4 评论 0原文

如果您有一个名为 ThisIsAHeaderFile.h 的头文件,则以下操作仍将在 Visual Studio 中找到该文件:

#include <ThisIsAheaderFile.h>

是否有办法强制区分大小写,以便 #include 会导致错误?

If you have a header file named ThisIsAHeaderFile.h, the following will still locate the file in Visual Studio:

#include <ThisIsAheaderFile.h>

Is there a way to enforce case sensitivity so that the #include will result in an error?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

荆棘i 2024-08-03 23:55:08

不能,因为 Windows 文件系统本身不区分大小写。

如果您可能遇到同时拥有 RICHIE.h 和 richie.h 的情况,那么控制区分大小写可能有意义,但您不能。

You can't, because the Windows file system is itself case-insensitive.

If you could get into a situation where you had both RICHIE.h and richie.h, it might make sense to control case sensitivity, but you can't.

弄潮 2024-08-03 23:55:08

我想指出,这并不是像许多人试图向OP指出的那样是一个无法解决的问题。 不区分大小写不是重点。 要点是 Lorenz03Tx 在评论中解释,即使文件系统不区分大小写,大小写也会保留,因此它可以被控制。

在进行跨平台开发时,这样的对策确实很棒,并且可以在为其他平台编译代码时避免很多后续工作。 不要忘记,使构建过程更加挑剔,您将为开发人员带来更好的习惯,因为他们逐渐会更加一致地包含和命名文件。

TL;DR

一种解决方案是使用一个脚本,该脚本只需扫描源文件中的包含语句并尝试沿包含路径匹配它们。 这样的脚本可以添加到 Visual Studio 构建后事件中,从而在每次构建时运行,或者(受到 krlmlr 的启发) )使用强制区分大小写的编译器预处理器。

I would like to point out that this is not an unsolvable problem as many tries to point out to the OP. The case insensitivity is beside the point. The point is as Lorenz03Tx explains in a comment, even though the file system is case insentitive the case is retained, so it can be controlled.

Such a counter measures is really great to have when doing cross platform development, and prevents much after work when the code is compiled for the other platform. Not to forget that making the build process more picky you would induce better habits for the developers, as they gradually will be more consistent how they include and name files.

TL;DR

One solution is to use a script that simply scans the source files for include statements and tries to match them along the include paths. Such a script could be added to visual studio post-build events, and thus run at every build, or (inspired by krlmlr) use the preprocessor of a compiler that enforce case sensitivity.

贱人配狗天长地久 2024-08-03 23:55:08

在 NTFS 上可以(曾经是?)创建名称相同但大小写不同的文件。 也许有 cygwin 的人可以验证这一点。

MSDN

然而,即便如此,也不可能从一个站点同时访问多个这些内容。正常的 Windows 应用程序。

It is (used to be?) possible to create files with the same name but case differences on NTFS. Maybe someone with cygwin can verify this.

MSDN

Even then, however, it's impossible to access more than one of these at a time from a normal Windows application.

晨曦慕雪 2024-08-03 23:55:08

虽然可能无法在 Visual Studio 中强制执行此操作,但可以通过仅在 C/C++ 源上运行预处理器来实现快速检查。 即使作为版本控制系统中的提交后挂钩,它也会运行得足够快,并且如果文件名中的大小写不匹配,则会出错。 因此:

  • 在 Linux 中配置您的构建系统以支持仅预处理器运行(-Egcc/g++

  • 实现仅预处理器运行作为提交后挂钩,触发对负责人和/或愿意定期修复这些错误的人员的早期通知

当然,这假设 VCS 作为代码的中央存储。

While it might not be possible to enforce this from within Visual Studio, one could implement a quick check by running only the preprocessor on the C/C++ source. This will run quickly enough to be practicable even as post-commit hook in a version control system, and err if the case in file names has been mismatched. So:

  • Configure your build system in Linux to support preprocessor-only runs (-E with gcc/g++)

  • Implement a preprocessor-only run as post-commit hook, triggering an early notification to the responsible person and/or to someone willing to routinely fix these errors

Of course, this assumes a VCS as central storage for the code.

烦人精 2024-08-03 23:55:08

FAT 和 NTFS 都是不区分大小写的文件系统。 Foo 和 fOO 就它们而言是同一个文件。 尽管 Windows 操作系统会保留您用于文件的大小写。 如果您将文件命名为 ThisIsAheaderFile.h,它将在文件系统中以这种方式显示。 尽管打开该文件的所有系统函数调用都可以使用它们想要的任何大小写。

Both FAT and NTFS are case insensitive file systems. Foo and fOO are the same file as far as they are concerned. Although the Windows OS will preserve the case you use for a file. If you name a file ThisIsAheaderFile.h it will show up that way in the file system. Although all system function calls to open that file can use any casing they want.

旧时光的容颜 2024-08-03 23:55:08

尝试在linux下构建时也遇到类似的问题; 不是完整的解决方案...
如果你通过VS在文件中查找#include并将结果复制到textarea,你将得到排序后的CSV,包含文件名、原始路径和列表第三列中的文件数(列以制表符分隔)
易于检查解决方案/广泛,如果没有太多案例问题,应该很容易更换它们?

function readIncludes(t)
{
    var s = t.value.split('\n');
    var res = {};
    for(var r in s)
    {
        if (r == 0) continue;
        var dq = s[r].indexOf('(');
        var p = s[r].substr(0, dq);
        var p2 = s[r].indexOf(':', dq);
        p2 = s[r].substring(0, p2);
        dq = s[r].indexOf('#', dq);
        var i = s[r].substr(dq);
        var ip = i.replace(/#include\s+/, "");
        if (!ip) continue; // *#includes.*
        var st = '<>""';
        if (st.indexOf(ip[0]) < 0) continue; // *#include*\S+
        st = st[st.indexOf(ip[0]) + 1];
        ip = ip.substr(1, ip.indexOf(st, 2) - 1);
        if (!ip || ip[0] == '/') debugger
        if (!res[ip]) res[ip] = [];
        res[ip].push(p2);
    }
    var resSorted = [];
    for(var r in res)
    {
        var shortR = r.replace(/.+[\\/]/, ""); // include file
        resSorted.push(shortR + "\t" + r + "\t" + res[r]); // \tpath\tplaces
    }
    t.value = resSorted.sort().join('\n'); // sort again long lines of results
}
html,body,textarea {
    width: 100%;
    height: 100%;
    white-space: nowrap;
}
<textarea onchange="readIncludes(this)">
</textarea>

Also having similar problem when trying to build under linux; not full solution...
If you Find in Files #include by VS and copy result to textarea, you will get sorted CSV with include file name, original path and list of files in 3rd column (columns are tab delimited)
Easy to check solution/wide and in case there are not much case problems it should be easy to replace them?

function readIncludes(t)
{
    var s = t.value.split('\n');
    var res = {};
    for(var r in s)
    {
        if (r == 0) continue;
        var dq = s[r].indexOf('(');
        var p = s[r].substr(0, dq);
        var p2 = s[r].indexOf(':', dq);
        p2 = s[r].substring(0, p2);
        dq = s[r].indexOf('#', dq);
        var i = s[r].substr(dq);
        var ip = i.replace(/#include\s+/, "");
        if (!ip) continue; // *#includes.*
        var st = '<>""';
        if (st.indexOf(ip[0]) < 0) continue; // *#include*\S+
        st = st[st.indexOf(ip[0]) + 1];
        ip = ip.substr(1, ip.indexOf(st, 2) - 1);
        if (!ip || ip[0] == '/') debugger
        if (!res[ip]) res[ip] = [];
        res[ip].push(p2);
    }
    var resSorted = [];
    for(var r in res)
    {
        var shortR = r.replace(/.+[\\/]/, ""); // include file
        resSorted.push(shortR + "\t" + r + "\t" + res[r]); // \tpath\tplaces
    }
    t.value = resSorted.sort().join('\n'); // sort again long lines of results
}
html,body,textarea {
    width: 100%;
    height: 100%;
    white-space: nowrap;
}
<textarea onchange="readIncludes(this)">
</textarea>

沧桑㈠ 2024-08-03 23:55:08

我的观点:如果源代码中 #include 的大小写与不区分大小写的系统上磁盘上的大小写不同,所有 C++ 编译器至少应该发出警告。 在区分大小写的系统上,如果存在文件,则应在比较时发出警告,因为不区分大小写将与包含匹配,并且与包含的大小写不同。 只是我的意见,已经被这种方式咬了太多次了......

根据我进行跨平台开发的经验,处理这个问题的最佳方法是在区分大小写的系统上进行编译,查找大小写冲突,然后修复它们。

My opinion: All C++ compilers should at least warn if the case of the #include in source differs from the case on disk on case insensitive systems. On case sensitive systems it should warn if there is a file than when compared as case insensitive would match the include and is a different case than the include. Just my opinion, having been bitten by this way too many times...

In my experience doing cross platform development the best way to deal with this is to compile on a case sensitive system looking for the case conflicts and then fixing them.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文