【问题标题】:Need to write a daemon in linux, not sure what to use C++ or C需要在linux下写一个守护进程,不知道用C++还是C
【发布时间】:2011-01-10 21:42:29
【问题描述】:

我在选择正确的语言来编写我的守护进程时遇到了一点问题, 我对 C 和 C++ 感到困惑,我想使用 C++,因为它比 C 更扩展, 但我想用 C 因为它是 linux 一切的起点,

我想选择 C++,因为我有很多关于它的资源,所以,如果我选择 C++ 而不是 C,有什么不同吗?

如果我更多地学习 C,我会有什么好处? 我觉得如果我进入 C++,我会在 C++ 中涵盖 C...

问候

【问题讨论】:

  • 你更懂哪种语言?
  • 如果您还不了解 C,请帮自己一个忙,不要使用 C++。如果您已经知道 C,请帮自己一个忙并继续使用它。
  • 我实际上都知道,但没有那么多可以让我写一个守护进程,我在大学的一个研究项目需要这个,所以我需要决定做什么,这样我才能进入它更深入
  • 好的,所以我从您的评论中了解到 Billy,在所有情况下都推荐 C 高于 C++?
  • 一个守护进程可以用任何语言编写,Bluscrod。选择适合你的。

标签: c++ c linux daemon


【解决方案1】:

使用您现在最熟悉的语言。

【讨论】:

    【解决方案2】:

    既不使用 C 也不使用 C++,一般编程并不真正需要它们。

    使用让事情变得简单的高级语言,例如Python

    当然,这取决于您正在编写什么样的“守护程序”,但很可能,您希望将开发精力集中在手头的任务上,而不是修复内存泄漏、字符串处理或其他干扰等问题。不使用 C 或(在较小程度上)C++ 将允许您这样做。

    【讨论】:

    • FUD:“修复内存泄漏、字符串处理或其他干扰等问题”
    【解决方案3】:

    我可以完全用代码回答这个问题。编写一个守护进程大致包括这样做:

    /*
     * Daemon Initialisation:
     * 1. Fork()
     * 2. setsid()
     * 3. Fork() do we need to do this twice?
     * 4. Chdir /
     * 5. Umask(0)
     * 6. Close STDIN/OUT/ERR
     * 7. Optionally re-open stuff.
     *
     * Refs:
     * 1. http://www.faqs.org/faqs/unix-faq/programmer/faq/
     * 2. http://www.netzmafia.de/skripten/unix/linux-daemon-howto.html
     * 3. http://www.enderunix.org/docs/eng/daemon.php
     */
    
    /* Variables */
    /* Our process ID and Session ID */
    
    pid_t pid, sid;
    int fd = 0;
    
    /* Fork off the parent process */
    pid = fork();
    if (pid < 0)
    {
        exit(EXIT_FAILURE);
    }
    /* If we got a good PID, then
     * we can exit the parent process.
     */
    if (pid > 0)
    {
        exit(EXIT_SUCCESS);
    }
    
    /* Create a new SID for the child process */
    sid = setsid();
    
    if (sid < 0)
    {
        /* Log the failure */
        exit(EXIT_FAILURE);
    }
    
    /* Fork off the parent process, again */
    pid = fork();
    if (pid < 0)
    {
        exit(EXIT_FAILURE);
    }
    /* If we got a good PID, then
       we can exit the parent process. */
    if (pid > 0)
    {
        exit(EXIT_SUCCESS);
    }
    
    /* Change the current working directory */
    if ((chdir("/")) < 0)
    {
        /* Log the failure */
        exit(EXIT_FAILURE);
    }
    
    /* Change the file mode mask */
    umask(0);
    
    /* Close all file descriptors */
    
    for (fd = getdtablesize(); fd >= 0; --fd)
    {
        close(fd);
    }
    
    /* Open standard file descriptors from
     * elsewhere.
     * e.g. /dev/null -> stdin.
     *      /dev/console -> stderr?
     *      logfile as stdout?
     */
    fd = open("/dev/null", O_RDWR); /* open stdin */
    dup(fd); /* stdout */
    dup(fd); /* stderr */
    

    这些都是 C 函数调用,当然,您可以从 C++ 中调用它们。

    我有这段代码的原因是因为它实际上是一个函数,我将函数指针传递给它来执行我的“守护进程”。为什么我要这样做?为了弄清楚我的错误在哪里直接作为进程运行代码(如果需要使用 root privs),然后我“守护进程”。否则很难调试守护进程...

    编辑:当然,使用函数指针是一种 C 思维方式,但没有理由不能实现某种形式的基于类的机制。

    所以,老实说,这真的没关系。选择你喜欢的。

    【讨论】:

    • 是的,但是你可以将任何可调用的对象作为函数传递给它吗?
    • @Noah 不,因为我只在 C 中使用它。我发布它只是为了指出编写守护程序不会阻止您使用 C++。这很容易成为您向其传递对象的类中的方法,或者只是您向其传递对象的方法。我敢肯定有很多聪明的 C++ 方法可以做到这一点。
    【解决方案4】:

    就我而言,C++ 是带有可选附加功能的 C。所以就这样吧,使用任何你觉得舒服的点点滴滴。

    【讨论】:

    • 除非“可选附加”应该是“一大堆完整的范式”:你失败了,先生。 C 是一种很好的系统编程语言。 C++ 是一种用于通用编程的大型语言,它从 C 继承了很多令人讨厌的边缘。那种名为“C with classes”或“C/C++”的假设语言是一团糟。
    • 为什么?使用 c++ 编译器并以程序方式编写所有内容有什么问题,除了(比如说)std::string 或 std::list - 与使用您自己的列表或字符串处理函数相比没有太大区别。如果你不想的话,你当然不必用继承的类和诸如此类的东西来填充它。
    【解决方案5】:

    如果您更熟悉 C++,则没有理由选择 C ​​而不是 C++,反之亦然。它们都是同样能胜任这项任务的语言。

    除非您希望对 C 更加熟悉,否则请使用您所知道的。

    【讨论】:

      【解决方案6】:

      除非你打算做内核开发或嵌入式编程,否则学习 C++ 绝对比学习 C 好。你唯一需要注意的是 C++ 会“破坏”它的函数名,这样你的函数void foo()在 C++ 中,C 程序无法直接访问。诀窍是用 C 链接声明它,如extern "C" void foo()

      也就是说,C++ 是一门比 C 大得多的语言,而且肯定需要更多时间来学习。

      【讨论】:

      • C++ 会破坏其函数名称,除非您在它们周围使用“extern C”。对于仅限内部的函数,修改并不是什么大问题。
      【解决方案7】:

      你绝对应该使用 C++。

      【讨论】:

        【解决方案8】:

        你绝对应该使用 C,句号。

        【讨论】:

        • 我想这是个玩笑。也许甚至像 cmets 一样具有教育意义。但是没有任何问题可以回答,抱歉。
        • 这个答案可以使用一些扩展,但我不认为这是一个笑话。
        猜你喜欢
        • 1970-01-01
        • 2023-03-26
        • 2017-01-19
        • 1970-01-01
        • 2011-06-25
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多