使用C ++进行网络守护进程是否有任何缺点?

时间:2011-01-16 09:18:28

标签: c++ c networking daemon

在过去的几年里,我一直在用不同语言编写许多网络守护进程,现在我即将开始一个新项目,需要新的自定义网络协议实现。

所述协议非常简单 - 一些基本的JSON格式的消息,这些消息在一些基本的帧包装中传输,以使客户端知道消息完全到达并准备好进行解析。

守护进程需要处理多个连接(同时大约200个连接)并对它们进行一些管理并传递消息,就像在聊天室中一样。

过去我一直在使用C ++来编写我的守护进程。通常使用Qt4框架(网络部分,而不是GUI部分!),因为这也是我用于其他项目的内容,而且操作简单且非常便携。这通常工作得很好,我没有太多麻烦。

现在作为一名Linux管理员,我注意到大多数网络守护进程都是用简单的C编写的(当然有些也用其他语言编写,但我觉得> 80守护进程的百分比是用普通的C)编写的。

现在我想知道为什么会这样。 这是由于纯粹的历史UNIX背景(如KISS)还是普通的可移植性或减少膨胀? 使用C ++或任何“更高级别”语言的守护进程的原因是什么?

提前致谢!


更新1:

对于我来说,使用C ++通常更方便,因为我有对象,它们具有getter和setter方法等。普通C的“上下文”对象在某些时候可能是一种真正的痛苦 - 特别是当你习惯于面向对象的编程时。

是的,我知道 C ++是C的超集,C代码基本上是C ++ ,你可以用C ++编译器编译任何C代码。但那不是重点。 ;)


更新2:

我知道现在使用像Python,node.js等类似的高级(脚本)语言会更有意义。我过去就这样做了,我知道这样做的好处(至少我希望我这样做) - 但这个问题只是关于C和C ++。

8 个答案:

答案 0 :(得分:6)

我无法想到选择C而不是C ++的任何技术原因。不管怎么说,我无法立刻想到一个对立点。

编辑回复编辑:我会严肃地劝阻你不要考虑,“...... C代码基本上是C ++。”虽然你可以在技术上使用C ++编译器编译任何C程序(只要你不使用C语言中比C ++采用的更新的任何特性)我真的试图阻止任何人在C ++中编写C代码或考虑C ++作为“C with objects。”

为了响应C在Linux中的标准,只有C开发人员一直这么说:p C ++是Linux中任何标准的一部分,就像C一样,Linux上有很多种C ++程序。如果您正在编写Linux驱动程序,则需要在C中执行此操作。除此之外...我知道RMS喜欢说您更有可能找到C编译器而不是C ++编译器但实际上并没有现在很长一段时间都是如此。您几乎可以在所有安装中找到这两种设备。

为了回应可维护性 - 我当然不同意。

像我说的那样,我想不出一个不能立即被驳斥的东西。反之亦然。

答案 1 :(得分:6)

守护程序代码开发对C ++的抵制源于一些来源:

  • C ++以难以避免内存泄漏而闻名。在任何长期运行的软件中,内存泄漏都是不可能的。这在某种程度上是不真实的 - 问题是具有C背景的开发人员倾向于在C ++中使用C语言,这非常漏洞。使用矢量和智能指针等可用的C ++功能可以生成无泄漏的代码。

  • 反过来说,智能指针模板类虽然隐藏了程序员的资源分配和解除分配,但却在很多方面做了很多工作。实际上,由于复制构造函数等原因,C ++通常会有很多隐式分配。因此,即使有足够的RAM,C ++堆也会随着时间的推移而变得碎片化,并且守护进程最终会因内存不足而失败。这可以通过使用更具抗碎性的现代堆管理器来改善,但是他们通过预先消耗更多资源来实现这一点。

  • 虽然这不适用于usermode守护程序代码,但内核模式开发人员避免使用C ++,这也是因为C ++生成的隐式代码,以及C ++库用来处理错误的异常。大多数c ++编译器在硬件异常方面实现c ++异常,并且许多内核模式代码在不允许抛出异常的环境中执行。此外,c ++生成的所有隐式代码都是隐式的,不能包含在#pragma指令中,以保证它在可分页或不可分页的内存中的位置。

因此,C ++根本不可能在任何平台上进行内核开发,并且通常也会被守护程序开发人员所避免。即使一个人的代码是使用适当的智能内存管理类编写的并且没有泄漏 - 保持潜在的内存碎片问题,使得内存分配明确的语言成为首选。

答案 2 :(得分:2)

我会建议你感觉更舒服。如果你对C ++更熟悉,你的代码会变得更干净,运行效率更高,因为你会更习惯它,如果你知道我的意思。

同样适用于Python和Perl讨论之类的更大规模。无论你更熟悉哪个都可能产生更好的代码,因为你将有经验。

答案 3 :(得分:1)

我认为原因是ANSI C是Linux中的标准编程语言。每当人们想要与他人分享他们的代码时,遵循这个标准是很重要的。但是,如果你只是想为自己写点东西,这不是一个要求。

您个人可以使用C或C ++,结果将完全相同。我认为你应该选择C ++,如果你熟悉它并且可以在你的代码中利用它的一些特殊的面向对象特性。不要在这里看太多其他人,如果你擅长C ++只是去用C ++编写你的守护进程。我个人也会用C ++编写它。

答案 4 :(得分:1)

你是对的。 使用C ++的原因是KISS,特别是如果您打算让其他人继续维护您的代码。我所知道的大多数人都学会了从现有资源编写守护进程或者阅读Stevens的书籍。差不多这意味着你的例子将在C中.C ++很好,我自己也写过守护进程,但我认为如果你希望它被维护,你不知道维护者是谁可能会在路上用C语言表现出更好的远见。

答案 5 :(得分:1)

Boost使用asio库编写单线程或多线程,高度可扩展的网络守护进程非常容易。

答案 6 :(得分:0)

我建议使用C ++,保留使用异常处理和动态RTTI。这些功能可能会影响运行时性能成本,并且可能无法跨平台得到很好的支持。

C ++更具模块化和可维护性,因此如果您可以避免使用这些功能,请将其用于您的项目。

答案 7 :(得分:0)

C和C ++都非常适合编写守护进程的任务。

除此之外,如今,您还应该考虑将语言编写为Perl或Python。性能通常足够好,您将能够在更短的时间内编写更强大的应用程序。

顺便说一下,看看ACE,一个用C ++编写可移植网络应用程序的框架。