C/C++ 牵扯面广,改起来更麻烦。
很多语言其实都有一个事实上的实现标准,然后别人都得兼容它,如此这般,标准方的话语权地位就十分的高。比如 Python 有一个 CPython 作为事实标准,作者想改那就改了,然后在文档里边体现一句,其它的 python 实现基本都得考虑与它兼容。比如 Java 无论怎么改,都还是要以 sun 的那个为兼容性基础,不与它兼容的都是异端。那么只要它改了就大家都跟着改就行。C#也是,基本只有微软的那一份实现,那么,微软想怎么改怎么改,就算有其它的开源实现什么的,肯定只能是跟它兼容。
C/C++就不一样,有非常多的厂商,独立做出了非常多的不同的实现, 究竟听谁的呢?谁也不服谁,那么结果就只能是,这些厂商的技术代表,以及C/C++作者等人,联合起来谈判,哪些特性要加,哪些特性不加。而这样不可避免的就要吵架,错过了项目的最佳修改时间。
当C/C++在代码界的地位和体量逐渐变大,以其为基础的项目逐渐变多时,已然成为庞然大物。作为目前运用最广的底层语言,牵一发而动全身。
从编写程序员的角度来看,这确实是一个问题。其他程序员代码只写一份实现,而C/C++的程序员不仅需要实现函数功能,还要进行相应声明,确实非常繁琐。
但是,如果项目换一个人接手,或者是向他人提供接口,那么C/C++的头文件就存在优势,它就好比一本目录,一个书签,不需要查阅动辄上万的代码看懂前作者写了什么变量,实现了什么函数,而是一种拿来主义,只需要阅读的相应的头文件就能快速地了解这个文件的内容。对于编写程序员而言,写两次相同的函数和变量名,更能加深他对项目的印象。
可是目录这种东西,由编译器自动推导出或许更合适,也有人认为,它是C/C++的一个特色,不应该删去。头文件这种事,究竟算是一个bug还是一个优势,目前已经各有各的说法,莫衷一是。
在可以遇见的未来里,头文件的删除问题是不会做出较大的让步的,不仅仅是作者和标准方,而且是全世界的以C/C++为基础的,已经建立或完成的项目。