我工作时间不长，见得也不多，但是，从接触的两三的公司看，还是用ANSI C的多。

几乎都是C，C++只是在一些应用层的数据库操作用一些。。

我也有此疑问，一问那些开发人员答曰效率，效率，我说狗P,c跟c++有效率能差到哪里去。还不是那些人怕进步，怕c++开发流行了，丢了饭碗。说实话，我觉得用c开发比较大型的系统，如果没有很好的架构，很好的管理人员简直是一团遭。

同意！在开发大系统时用C时比较的困难，因为C++给我们带来了便利！写出的系统也更好维护！
C/C++的效率相差无几，这是在找借口！

虽然我现在尝试用c++写unix程序，但是又想全部改回到标准c的，因为各个unix平台的c++编译器对标准支持的程度有太大的差别，有的平台只有c编译器，c++编译器不是标准配置，移植代码时很成问题。不象window程序，一般windows程序是不会考虑移植到别的平台的，甚至用vc写得程序很少移植成c++ builder代码

我也想说两句,好象现在C++在绝大多数UNIX中都支持（包括新的并行C++）。我很早以前用的SCO UNIX 5.0.4版本中就支持CC（C++）编译，现在我用的已经是5.0.6版本，它和以前版本比较起来，不允许不负责的开大数组；并且程序优化的也不错。
     C++和C没有本质的区别，只不过C++的封装、继承、重载这三大特性，注定了它比C语言功能应用起来更加灵活一些，如在WINDOWS下用别人的封装类就显得格外轻松，从C过渡到C++用不了费很大事。

不是各大UNIX厂家不支持，而是对标准的兼容程度参差不齐，比如SCO的C++编译器就很差劲，连namespace还不支持；另外有的unix平台的c++编译器不是随OS一起发布的，需要另外购买，所以经常是这些平台上只安装了c编译器；虽然可以下载gcc安装，但总不如针对特定平台的编译器好，多了道工序不说，程序的分发也成了问题

C++的特性比C要多得多，一不小心用了某些编译器不支持的特性就会给移植造成问题。所以能编译一般的C++程序，并不代表该C++编译器的可用性多么好。我很想使用STL，可是不敢用，就是因为可移植性的问题

我的观点：C++对C最大的改进就是提供了构造和析构方法，仅此而已。

我觉得主要还是移植问题,不同厂家的编译器差别不小,而且安装起来也挺费事,如果没有安装那就彻底歇菜.

兼容性问题，要想尽可能简单的支持多种unix版本的最主要的办法就是只用ansi c.
大规模的商用系统可不是你家装windows，来一个新版本就跟着升级一次
几年前十几年前的系统并不少见，c++？想得美吧  :D

UNIX要的是稳定和高效，至于应用层面的东西本来就不是UNIX的事情，
要用C++到客户端去好了。

Unix上到处都是C的库，你见过几个C++的库。构建应用最好就是大量使用现成的库，谁还会去自己写。
重要的是C++要提供自己的库相当困难，这是C++的本质决定的，如果以编译好的库的形式提供，大量的内联就难以实现，应用性能将急剧降低；同样的，继承，特别是虚拟继承更有可能使得库的提供变得更加困难，C++在这一点上不如COM。不管是STL还是Boost，这些经典的东西多半都以头文件形式提供，问题是，C++本身的结构复杂性，增加了理解这些头文件的困难，很少有人能完全掌握这些东西。

C++是兼容C的，Unix上到处都是的C函数库，在C++上仍然可以使用。C++提供了更高的代码编写效率。如果用STL的话，兼容性也不是问题。各个流行的Unix平台上都有可用的C++编译器。
我觉得C++没有C流行的原因是，C++比C更复杂，编写优秀的C++代码需要比编写优秀的C代码更多的经验。

C++兼容C仅仅是对语言而言有意义，在库的层次上就不是那么简单的问题了。
对于线程的问题有些unix甚至必须改写整个libc库，提供一个libc_r，这样的问题用C都是个痛苦，何况C++。
如果你需要写一个基于openssl的安全应用，你用C++去包装试试。
如果你要做大数运算，用libslang看看，里面大量使用宏，用C++怎么去包装？
尽管这些库的头文件都提供extern "C"{}的说明，但并不意味着用了C++就能提供更好的性能，如果你要将这些库的对象转换为C++的对象，存放到STL之类的容器里面，必须提供自己的wrapper，这还增加了一个层次上的开销。另外内存分配的问题上C++习惯用new，而那些C库肯定都用malloc，虽然new是从malloc而来，但是在应用层面上这两个东西是各自独立的，代码维护将遇到相当大的困难。
说到经验，那些能够提供各种各样的通用库的人，经验难道不丰富？C++真的像吹的那么好，那些人为什么不把自己的库移植到C++？甚至整个gnome都是基于C的！
不要说C++有了98年的标准，就是个没有问题的好东西了，C++一方面要兼顾面向对象，一方面又要保持C的性能优势，中国话说就是当了婊子又要立牌坊，哪有这么好的事，逻辑上都可能出问题。我给个简单例子去研究研究吧：
一个类虚拟继承两个类，其中一个基类的析构函数是普通的，另一个是虚拟的，派生类的析构到底应该是怎么样的？

to  楼上的：
     关于你的最后一个问题。
     “一个类虚拟继承两个类，其中一个基类的析构函数是普通的，另一个是虚拟的，派生类的析构到底应该是怎么样的？”
     这只是一个错误的设计！！如果一个类要作为基类，那么它的析够函数就应该被设计为虚拟的。这应该是设计时就明确的。
     如果实际应用中出现了上面的情况，它的设计人应该被隔离！！

如果C++连这样的漏洞都检测不出来，能说不是C++本身的问题？
更重要的是，如果以库的形式提供接口，顶层抽象完全有可能被忽略。以至于开发者并不知道他所继承的两个类的析构一个是虚的，一个不是。

用什么语言从来都是个人喜好.
再好的语言,不好好管理也是废物.
gcc里面有c++编译器,有c,java,fortran,gnat…….
gcc很全面,而且也是很重视移植性的.