iostream、wifstream 和 eclipse/g++在窗户上
我在 Windows 上使用 Eclipse 和 MinGW 工具链（g++ 等）。我有一个基于 darwin 构建的程序，它使用 wifstream 和 wofstream 读取和写入文件。该程序在 darwin (Mac) 上使用 eclipse 进行编译和工作，发现...不适合我的问题。
当我将代码移至 Windows 并尝试使用 MinGW 工具链和 Eclipse 进行构建时，我在 wifstream、wofstream 和 wcout 上收到编译错误。定义为 wstring 的变量编译得很好。
例如：
wifstream inFile； inFile.open(argv[2], ios_base::in);
导致编译错误
..\src\pdConv.cpp:31: error: `wifstream' 未在此范围内声明，
这似乎表明编译器认为 wifstream 是一个变量。我确实注意到包含文件中未启用 _GLIBCXX_USE_WCHAR_T 指令。我需要自己定义这一点还是环境中的某些东西应该知道这一点？如果我手动定义它，那么我似乎无法在同一程序中同时使用宽实现和窄实现。
这可能是显而易见的，但我已经陷入这个问题很长时间了...哈哈..我在这里错过了什么？
I am using Eclipse on windows with the MinGW tool chain (g++, etc.). I have a program that I built on darwin that reads and writes to files using wifstream and wofstream. The program comiles and works find using eclipse on darwin (Mac)...no for my problem.
When I move the code over to windows and try to build in using the MinGW tool chain and eclipse, I get a compile error on wifstream, wofstream, and wcout. Variables defined as wstring compile just fine.
For example:
wifstream inFile;
inFile.open(argv[2], ios_base::in);
results in a compile error
..\src\pdConv.cpp:31: error: `wifstream' was not declared in this scope
which seems to indicate that the compiler thinks wifstream is a variable. I did notice that the _GLIBCXX_USE_WCHAR_T directive is not enabled in the include files. Do I need to define this myself or is something in the environment supposed to know this? If I define it manually then it appears I cant use both wide and narrow implementations in the same program.
This is probably obvious but I have been stuck in this problem for to long...lol..What am I missing here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
基本上，MinGW 不支持这一点。请参阅此 链接 我想可能是最新的 gcc (4.4.0) 可用于MinGW 解决了这个问题，但我不会指望它。如果您需要坚持使用 MinGW，看起来使用 STLPorts 可能是您唯一的选择。
Basically, this isn't supported with MinGW. See this link I suppose it's possible the the very latest gcc (4.4.0) that is available for MinGW solves this, but I wouldn't count on it. Looks like using STLPorts might be your only option if you need to stick with MinGW.