Main函数的尴尬

    习惯C语言编程的程序员在写程序的时候，打开编译器首先做的也许是引用头文件、将main函数写好然后再进行编程。那么这一习惯性的举动说明了什么呢？这要从main函数说起，main函数即为程序的主函数，main函数是程序的入口函数，程序从此处开始执行。那么C语言为什么会出现一个“裸露”在外面的main函数呢？

    从C语言的语法角度来说，C语言规定函数不允许嵌套定义，但必须嵌套调用。嵌套调用这一规定就决定了C语言程序一定会有一个最外层的“主调用”函数，程序使用它直接或间接调用其他所有函数，这个函数就是C语言中的main函数。到此，我们会把我们要实现的代码一步一步写到main函数里的这一举动就会变得司空见惯。如果说对于这种“过程化”味道很浓的编程方式在C语言中可以被人接受，那么被C++所沿用的这种“过程化”的编程方式会让一些面向对象的“狂热者”无所适从。让我们看一段极其经典的一段代码：

void fun()

{

       cout << "我是fun!" <<endl;

}

 

class A

{

public:

       A()

       {

              fun();

       }

};

 

A a;

 

void main()

{

       cout << "我是main" << endl;

}

 

    程序在运行的时候会首先执行fun函数后执行main函数，这造成了编程者极大的困惑，对于C++这种面向对象的语言为什么会允许这种有失封装性的写法存在？假使我们把实现代码全部写到A的构造函数中，那么main函数还有存在的价值与意义么？

    为什么C++语言允许这种写法，我想究其原因在于C++是一门“混血”的语言（B.Stroustrp先生不喜欢这样的称谓，他更喜欢称之为“multi-paradigm language”），也就是说C++不仅仅是一门面向对象的语言而是一门支持面向对象的多模式语言。这使得面向对象的“狂热者”陷入了极度的恐慌，其中不乏很多人转向“纯”面向对象语言的阵营，或者直接封装C++比如说：MFC这一可视化类库，想方设法要把“万恶”的main函数干掉！（其实如果我们将MFC框架代码展开还是会发现底层调用的WinMain，它是在用一套类多态的宏机制玩出多态的味道来）我想出现这种现象的原因在于我们太过分崇拜面向对象了，过度的纠结于语言的本身而忽略语言所能提供的程序设计方法。用B.Stroustrup的话说：程序设计语言只是我们尝试达到我们目标的一种方法、一种途径，不是每一件好的事物都是面向对象的，基于面向对象的事物也不都是好的。我们应该关注的是面向对象的程序设计而不是面向对象语言本身。

    用面向过程的语言写不出来面向对象的程序吗？第一个C++编译器（Cfront）是使用C++编写出来的，所以早期编译C++代码要先通过预处理器进行预处理，这里的预处理器作用就是将“带类的C”转换成C。那么通过C++写出的面向对象的程序转换成C之后程序就不是面向对象的了吗？直接或者间接支持面向对象的程序设计语言只是便于我们设计面向对象的程序而非必须。至于main函数的保留，我想它不仅仅是作为“主程序入口”这一作用的标识，更是想让C++与C这一完整的语言相兼容，并使其具有足以应对系统编程的性能和灵活性。

 

后记：

    记得上学那会对计算机的世界充满着无限的憧憬与渴望，不知何时对递归算法疯狂的痴迷，崇尚于这种简洁易懂的编程方式。忽然有一天老师发问：递归算法真的那么好么？既然C语言、C++是如此的追求程序的执行效率，为什么不把数据全都存到静态数据区中而是要建立栈这种数据结构呢？猛然间醒悟：也许还真的没法在编译阶段给递归函数分配合适大小的内存空间也说不定呢。

    我想无论是面向对象的程序设计还是面向过程的程序设计都有其值得借鉴与商榷的东西。我们一直在模仿中前行，无论是面向对象的思想还是面向过程的思想都体现了人们对于自然界的探索，一些事物也许真的只有在面向对象的世界与面向过程的世界的交汇处才能看清他们的本质。也许正因为main函数的尴尬成就了C++语言的多模式特性，我想正如自然界中“混血”的生物往往具有较高的生命力一样，在探索的道路上我们一定可以带着C++一起渐行渐远。

 

参考文献：

《Why C++ is not just anObject-Oriented Programming Language》Bjarne Stroustrup

《The C++ ProgrammingLanguage》Bjarne Stroustrup

《TheC Programming Language》Dennis Ritchie， Brian Kernighan