Bas*_*Ben 4 c c++ networking daemon
在过去的几年里,我一直在用不同语言编写许多网络守护进程,现在我即将开始一个新项目,需要一个新的自定义网络协议实现.
所述协议非常简单 - 一些基本的JSON格式的消息,这些消息在一些基本的帧包装中传输,以使客户端知道消息完全到达并准备好被解析.
守护进程需要处理多个连接(同时大约200个)并对它们进行一些管理并传递消息,就像在聊天室中一样.
在过去,我一直在使用C++来编写我的守护进程.通常使用Qt4框架(网络部分,而不是GUI部分!),因为这也是我用于其他项目的内容,而且操作简单且非常便携.这通常工作得很好,我没有太多麻烦.
作为一名Linux管理员,我注意到大多数网络守护进程都是用简单的C编写的(当然有些是用其他语言编写的,但我感觉80%以上的守护进程用简单的C)写的.
现在我想知道为什么会这样. 这是由于纯粹的历史UNIX背景(如KISS)还是普通的可移植性或减少膨胀？有哪些原因不能使用C++或任何"更上一层楼"语言的东西像守护进程？
提前致谢!
对我来说,使用C++通常更方便,因为我有对象具有getter和setter方法等.普通C的"上下文"对象在某些时候可能是一种真正的痛苦 - 特别是当你习惯于面向对象的编程时.
是的,我知道 C++是C的超集,C代码基本上是C++您可以使用C++编译器编译任何C代码.但那不是重点.;)
我知道现在使用像Python,node.js等类似的高级(脚本)语言会更有意义.我过去就这样做了,我知道这样做的好处(至少我希望我这样做) - 但这个问题只是关于C和C++.
我无法想到选择C over 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++编译器但实际上并没有现在很长一段时间都是如此.您几乎可以在所有安装中找到两者或两者.
为了回应可维护性 - 我当然不同意.
就像我说的,我想不出一个不能立即被驳斥的.反之亦然.
守护程序代码开发对C++的抵制源于以下几个方面:
C++以难以避免内存泄漏而闻名.在任何长期运行的软件中,内存泄漏都是不可能的.这在某种程度上是不真实的 - 问题是具有C背景的开发人员倾向于在C++中使用C语言,这非常漏洞.使用矢量和智能指针等可用的C++功能可以生成无泄漏的代码.
相反,智能指针模板类虽然隐藏了程序员的资源分配和解除分配,但却在很多方面做了很多工作.实际上,由于复制构造函数等原因,C++通常会有很多隐式分配.因此,即使有足够的RAM,C++堆也会随着时间的推移而变得碎片化,并且守护进程最终会因内存不足而失败.这可以通过使用更具抗碎性的现代堆管理器来改善,但是他们通过预先消耗更多资源来实现这一点.
虽然这不适用于usermode守护程序代码,但内核模式开发人员避免使用C++,这也是因为C++生成的隐式代码,以及C++库用来处理错误的异常.大多数c ++编译器在硬件异常方面实现c ++异常,并且许多内核模式代码在不允许抛出异常的环境中执行.此外,c ++生成的所有隐式代码都是隐式的,不能用#pragma指令包装,以保证它在可分页或不可分页的内存中的位置.
因此,C++根本不可能在任何平台上进行内核开发,并且通常也会被守护程序开发人员所避免.即使一个人的代码是使用适当的智能内存管理类编写的并且没有泄漏 - 保持潜在的内存碎片问题,使得内存分配明确的语言成为首选.