Linux 与 Windows 中的 C 编码对比。有没有足够的面向调试、以 C 为中心的 IDE？
我在用 c 编写一些代码时遇到了问题。我的基本问题是我的时间紧迫，而且我正在处理的代码有很多错误，我必须在明天晚上之前“消除”这些错误。
问题的更大部分是没有足够的 IDE 可以进行实时调试，特别是在使用线程或通过 fork() 生成进程时。我尝试了 Mono、Eclipse，最后是 NetBeans，并得出结论，这些都非常好，但不适用于 C 语言编码。正确使用命令行调试器的学习曲线相当陡峭。 （就像我之前提到的......我时间紧迫。）
所以，由于我是一名专业的 C# 开发人员，我想知道我是否可以在 VS2003/VS2005/VS2008/VS2010 中实现这一目标。如果我放弃使用系统调用，我可以这样做吗？
特别令人感兴趣的是 FILE* 描述符和 fread()、fclose()、fseek() 方法。我知道它们是标准 C 库的一部分，但是它们与平台本身相关吗？ Linux 和 Windows 中的标头相同吗？ fork() 或共享内存怎么样？
也许如果我使用 VS2010 一次构建组件的一部分（通过模拟输入和其他东西），调试它们，然后迁移整个 Linux 项目中的工作代码，会被证明是最有用的？
任何意见将不胜感激。
I've run into an issue with writing some code in c. My basic problem is that I am pressed for time and the code I am dealing with has lots of bugs which I have to "erradicate" before tomorrow evening.
The bigger part of the problem is that there is no adequate IDE that can do real time debugging, especially when using threads or spawning processes with fork(). I tried Mono, Eclipse, and finally NetBeans, and have concluded that those are very good but not for coding in C. More over the learning curve to utilize the command line debugger properly is quite steep. (Like I mentioned earlier... I am pressed on time.)
So, since I am a C# developer by profession I was wondering whether I can pull this off in VS2003/VS2005/VS2008/VS2010. If I abstain from using system calls, can I do this?
Of particular interest are FILE* descriptor and fread(), fclose(), fseek() methods. I know they are part of the standard C library, however are they tied to the platform itself? Are the headers the same in Linux vs Windows? What about fork() or shared memory?
Maybe if I use VS2010 to build parts of the component at a time (by mocking inputs and stuff), debug those, and then migrate the working code in the overall Linux project would prove most useful?
Any input would be greatly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Eclipse CDT 可能对 C/C++ 开发和集成调试有最好的整体支持。
请注意，即使在最好的情况下，多线程和多进程调试也可能很困难。此时投资一个好的日志框架是明智的，并且可能比依赖调试器更有用。有很多可供选择 - 看看 Log4C++ 等等。即使是在紧要关头的
printf也可能是无价的。如果您注意仅使用可移植调用而不是特定于 Win32 的 API，那么应该没问题。此外，还有许多库（对于 C++ 库，例如 Boost++ 提供了一组丰富的功能，其工作方式相同在 Windows、Linux 和其他操作系统上。
是的，您提到的文件 I/O 函数位于
然而，
fork()和共享内存函数shmget()是 POSIX 函数，可在 *nix 平台上使用，但在 Windows 上不可用。 Cygwin 项目在库中提供了这些函数的实现，以便于移植。如果您使用 C++，Boost++ 将为您提供所有这些系统级调用的可移植版本。
你当然可以这样做。请注意，Visual Studio 倾向于引导您走上 Win32 道路，并且您必须保持警惕，不要开始使用不可移植的函数。幸运的是，MSDN 上的库参考为您提供了兼容性信息。一般来说，使用标准 C 或 POSIX 调用是可移植的。根据我的经验，在 *nix 上编写并移植到 Windows 实际上更容易，但是 YMMV。
The Eclipse CDT would probably have the best overall support for C/C++ development and integrated debugging.
Note that multithreaded and multiprocess debugging can be difficult at the best of times. Investing in a good logging framework would be advisable at this point, and probably more useful than relying on a debugger. There are many to choose from - have a look at Log4C++ and so on. Even
printfin a pinch can be invaluable.If you take care to only use portable calls and not Win32-specific APIs, you should be ok. Also, there are many libraries (for C++ libraries such as Boost++ that provide a rich set of functionality which work the same on Windows, Linux and others.
Yes, the file I/O functions you mention are in
<stdio.h>and part of the portable standard C library. They work essentially the same on both Windows and Linux, and are not tied to a particular platform.However,
fork()and the shared memory functionsshmget()are POSIX functions, available on *nix platforms but not natively on Windows. The Cygwin project provides implementations of these functions in a library for ease of porting.If you are using C++, Boost++ will give you portable versions of all these system-level calls.
You could certainly do that. Just be mindful that Visual Studio has a tendency to lead you down the Win32 path, and you must be vigilant to not start using non-portable functions. Fortunately the library reference on MSDN gives you the compatibility information. In general, using standard C or POSIX calls will be portable. In my experience, it is actually easier to write on *nix and port to Windows, but YMMV.
看来我是这里第一个推荐Emacs的人了。以下是 Emacs 的工作原理。当你安装它时，它只是一个带有很多扩展的文本编辑器（默认包含调试器和 C 字体锁定）。当您开始使用它并安装您错过的扩展时，它就不仅仅是一个编辑器了。它很快就会轻松地发展成为一个 IDE，然后发展成为可以在一个框架下避开操作系统的东西。
Emacs 可能需要很长时间才能学习，同时，如果您不担心成本问题，您可以使用 Visual Slick Edit。我在两个平台上都使用过它，发现它在版本控制、标签等方面效果很好。
Looks like I am the first to recommend Emacs here. Here is how Emacs works. When you install it, it is simply a text editor with a lot of extensions(debugger and C font-locking are included by default). As you start using it and install the extensions you miss, it becomes more than just an editor. It grows to become an IDE very soon and easily, then on to something that can eschew the OS under one frame.
Emacs might take long to learn, in the mean time, you could use Visual Slick Edit if you are not pressed on the cost part. I have used it on both platforms and seen it work good with version control, tags, etc.
也许Code::Blocks？我喜欢它，虽然它说它适用于 C++，但它当然也非常适合普通 C。
Perhaps Code::Blocks? I love it and while it says it's for C++ it is, of course, very good for plain C as well.