但我很怀疑以日本宅的废萌脑能写出什么内涵来。。。
语言之争：asm，c，c++, java，pascal。。
系统之争：unix，linux，windows，mac，vxworks。。。
流派之争：copyleft vs copyright， ms-lish vs gnu。。。
传说中的大魔法师：linus，stallman，gates（反派大boss了，肯定）
。。。 原来看错了，现在看见c++代码名称全大写的都会脑补成宏，心里都有阴影了。
宏本身并不坏，只是要看使用方式 也不能断言它没用到宏。
比如那个u8是什么呢？ 在前面有一句 #define u8 unsined char 就没什么问题，当然用typedef也可以 本帖最后由 鸡蛋灌饼 于 2009-7-12 15:19 编辑
其实将programmer类比成魔法师真的挺有搞头的
八神 发表于 2009-7-12 14:34 http://bbs.saraba1st.com/images/common/back.gif
这个弗洛·文奇20年前就玩过了
作品：《真名实姓》（True Names） 作为一个专业人士，我感到压力很大
确实是C++
小错误么7F也说得差不多了
boost里面随便抽一段都不至于这么多错误啊
请先拿到ring0级权限谢谢 ...
鸡蛋灌饼 发表于 2009-7-12 01:23 http://bbs.saraba1st.com/images/common/back.gif
su - root root 可不是ring0
对于现代编译器来说写/256和位移效率没差别，因为在编译优化阶段就会优化成位移代码（如果位移代码效率更高的话）。
u8显然是自定义类型，一般就是unsigned char的typedef，为了平台移植性和代码统一性一般会这样 ...
RedNax 发表于 2009-7-12 11:53 http://bbs.saraba1st.com/images/common/back.gif
c99建议用int8_t uint8_t int32_t 等指明长度的整形 无论面向对象，面向过程
还是泛型，模板
编译后都是产生的机器码
c++那样的别扭语法和继承关系，效率比C高不太可能
但比较效率的话，汇编作为机器语言的直译
肯定要比捆绑了运行库的C强
而C++的运行库一般又比C运行 ...
八神 发表于 2009-7-12 14:20 http://bbs.saraba1st.com/images/common/back.gif
我倒觉得汇编效率不见得比C++好。汇编由于写起来难度很大，所以实现倾向于简单的算法，这未必比利用更好算法的高级语言效率更高。而且现在编译静态优化已经到了一个很高的程度了，编译器为提高运行效率做的很多安排未必是手动安排就能做得那么好的（当然现在的汇编编译器也有编译静态优化）。
要说C/C++运行库的话，其实大都也就是用于对OS API的包装。如果不想用运行库，直接调用OS API的话，和汇编也没啥区别了（汇编也得调用OS API嘛）。
当然汇编最大的优势是可以用特殊指令集(MMX,SSE)进行优化，这个C/C++编译器即使能做也不可能做得比自己优化得好。
就我朋友的经历来看（他搞通讯设备），内嵌一直用C的最大原因其实是Linux内核都是C写的（内嵌和OS内核关联性太大）…… 汗，经查证那个嵌套类的声明语法是没错的，当然接下来你不能声明它的实例，但声明一个指针没问题。
至于类里的typedef，在模板类实现里很常见，估计看不顺眼是因为那个typedef typename，但这里必须这么用，告诉编译器那是一个类型而非变量，当然这种用法基本只在泛型编程里用到，看不顺眼也是自然的。
泛型编程是一种编程风格，它把类型当参数传入，扩大了代码的适用范围，是代码复用的高级形式，代价是代码比较晦涩难懂。java一开始没支持泛型但后续版本也支持了，当初不少人都扬言“java一天不支持泛型就不会去用它”。
其实不少c++程序员都或多或少地接触到泛型编程，比如stl里的容器类，非常好用，用法大同小异或者说规范，大部分情况下又不必去关心实现。 原来这么多人只学过Java没见过C系列么...我还以为大学里面C是必修的呢.... ls乃要知道很多死程都不是大学里学的。。。就算大学里学ooc的时候用c++来讲，用java工作个1年多也就忘光了。。
不过c++么。。。。
只用c写51程序的头顶晴天了
这个弗洛·文奇20年前就玩过了
作品：《真名实姓》（True Names）
鸡蛋灌饼 发表于 2009-7-12 15:17 http://bbs.saraba1st.com/images/common/back.gif
不，这个太不一样了
那些人说到底也只是牛Ｂ的程序员而不是魔法师． 作为C#程序员我感觉到现在可能会写出来欧巴桑... 无聊下了动画看，什么玩意，怪不得以前没看它的小说，估计那时瞄几眼就忽略了。
那段代码，其实没什么错误，除了小括号这个可以肯定外，有个不确定的地方是两个decoder函数，因为后面没有分号和大括号，也可能是画面宽度不够没显示出来而已。一个确定还有一个不确定，说100+错误的显然不会c++。
我倒不觉得元编程是C++的最高成就，C++效率虽然比C低，但和其他语言相比已经超出一大截，如果不是在内嵌式系统这种硬件受限的场合（这种时候用C更多），现在的硬件环境已经没必要在效率上计较到极高的程度了。
相反，元编程带来的是编译器是否支持、编译时间极大增长等很多问题，在我看来远不如模板和命名空间对C++带来的好处大。
而且现在我极为反对写出别人一眼看不懂的代码，毕竟6个月后即使你自己看你的代码都好像是别人写的一样，这种阅读的时候需要用脑子来进行编译的代码越少越好（我觉得boost早已走火入魔了）。
其实boost只不过是写的人可能都是走火入魔的疯子，对于用的人来说根本没必要自己看实现细节，反而很好用。
stl刚出来的时候不也相当走火入魔么（笑），现在大家都在用了。
其实boost只不过是写的人可能都是走火入魔的疯子，对于用的人来说根本没必要自己看实现细节，反而很好用。
stl刚出来的时候不也相当走火入魔么（笑），现在大家都在用了。 ...
Wiksy 发表于 2009-7-13 06:36 http://bbs.saraba1st.com/images/common/back.gif
STL是比较好理解的，让我自己去实现一套花一段时间也能做出来（当然效率上肯定不行而且会bug满天飞）。
但boost，用的时候是觉得神奇，但就觉得一些近乎trick的方式来完成工作并不是一件很好的事情。
当然，另外一个不舒服的地方是文件继承关系实在是复杂到不能接受的程度，哪怕只需要一个小功能也要包进成千上万个头文件，实在是不够优雅……
我倒觉得汇编效率不见得比C++好。汇编由于写起来难度很大，所以实现倾向于简单的算法，这未必比利用更好算法的高级语言效率更高。而且现在编译静态优化已经到了一个很高的程度了，编译器为提高运行效率做的很多安排 ...
RedNax 发表于 2009-7-12 15:32 http://bbs.saraba1st.com/images/common/back.gif
正好提到linux kernel了
内核就是汇编强大的代表制作啊
就算不提引导代码，中断代码等纯汇编
内核态的许多函数都是内嵌汇编实现的，而其中巧妙之处是无法用c语言实现的
汇编时间空间效率都不是高级语言能比的，问题就是编码效率，可读性差，可移值性差
内嵌汇编的c固然是好用，但换个平台就用重写，大型系统如果用内嵌汇编写，维护起来就是噩梦
而这些才是高级语言的强势之处
STL是比较好理解的，让我自己去实现一套花一段时间也能做出来（当然效率上肯定不行而且会bug满天飞）。
但boost，用的时候是觉得神奇，但就觉得一些近乎trick的方式来完成工作并不是一件很好的事情。
当然，另外一 ...
RedNax 发表于 2009-7-13 23:06 http://bbs.saraba1st.com/images/common/back.gif
就算不用stl
高效的纯c也是有现成的，不用重复发明轮子
linux内核源码里很多数据结构的实现都非常具有参考价值，稍作修改就能在用户态下使用
而其中对宏的秒用更是让人赏心悦目，所以我一直认为c语言更能体现编程之美
而c++某些地方确实过于古怪，难怪linus一直不喜c++ 我一直接触的是逻辑复杂的游戏系统，不用面向对象封装的C++是不可能的（再说又不像10多年前那么追求效率），所以接触C不多。
不过如果要用到中断代码什么的话，也不应该用C而是包装成platform SDK吧，即使对于同一个平台，不同编译器内嵌汇编写法都不同，除非十分必要要不然真是不应该是用的。
但要说编程之美的话，我还是觉得C++更甚。面向对象首先具有的封装特性可以说从本质上改变了对实体事物的描述方法，而C++更通过极其巧妙的实现在不依赖运行时环境的前提下做到了多重继承（当然也是另很多程序员抓狂的地方）。虽然C也可以有特殊的写法来实现类似面向对象的功能，但比起C++来说难看了很多。
像对宏的极大依赖我就是不太赞同的。毕竟宏从定义上来说就是一种在编译前的trick(毕竟是预处理)，如果能有一种更加优雅的办法在编译期而不是预处理期来实现宏所要达到的功能的话，我觉得后者更加可取（模板、名字空间，etc）。在我看来编程的魅力来源于各种超越语言的巧妙的算法和实现，而不是魔法般的trick. c++对比c，有多态，有泛型，并且在大型软件开发中，条理性、可读性确实比c好。
我看c源码，都是一堆全局函数就先囧了，只好慢慢耐下心来看；同一个级别的软件代码上，c++的类就容易理解多了 能有多少大型软件的规模能比os内核，通信系统开发还大呢？
这些无一不是用c来做的哦
算法固然是编程之美的最佳体现，但这是编程思想不是语言特性，任何语言都能用算法武装自己
另外面向对象也是编程思想不是语言特性，这些都不是c++的专利，c也能体现出面向对象（不是指用struct模拟类），其实整个linux系统就体现着面向对象的思想
而看c++0x的发展，越来越脱离c中级语言的范围，几乎是java2了，以后肯定大家不会把c和c++当兄弟看了
一个简单的事实就是，如果c++真的是完美的作品，那早就能代替c担当大任了，也不会让java把主流语言的宝座拿走了 作为VB程序员，我感到压力很大。 作为VB程序员，我感到压力很大。 这个贴子真的应该放漫区吗．．． 能有多少大型软件的规模能比os内核，通信系统开发还大呢？
这些无一不是用c来做的哦
算法固然是编程之美的最佳体现，但这是编程思想不是语言特性，任何语言都能用算法武装自己
另外面向对象也是编程思想不是语言特 ...
八神 发表于 2009-7-14 06:47 http://bbs.saraba1st.com/images/common/back.gif
我承认os内核和通信系统是很巨大，但如果你以为其他系统比如AAA级游戏的规模就不大那完全是一种误解。
os内核和通信系统很巨大，但这巨大来源于其提供的功能非常繁多而细小。所以对于单个功能来说，代码既不多，层次也不深（linus曾说过OS代码超过三个for就是不好的代码），阅读相对容易。
但对于AAA级游戏来说，其实功能并不多，模块只能划分成AI, Engine, 3D Rendering, Physic, Sound等几个功能，每个功能都是一个整体而且其规模非常巨大。对于这种系统，不用OO思想来进行设计完全就是不可能的。甚至即使用了OO的思想，不用private, namespace来进行保护也是不可能的——程序员能力参差不齐而这类项目需要在一个比较短的时间内完成，这使得从技术角度来保障安全的代码成为一件必要的事情。
至于不能取代C，只是因为C更适合和OS沟通——事实上在《Efficient in C++》一书（或许是另外一本，记不清了）中，作为通讯行业电子工程师的作者就成功将C++引入通讯设备开发中，所以更可能的只是惯性使然罢了。
而基于虚拟机，有着完善保护机制和垃圾回收器的Java，直接编译成危险的native code的C++无论如何也不可能被超越其安全特性吧（虽然无论是msvc还是g++都在安全性上下了很大功夫）。如果真要比，也只能和.net framework下的语言比了……
其实，我比较喜欢的却是基于运行时虚拟机的C++/CLI，既有C++特性又是.net framework CLR，可惜我觉得不会成为主流（貌似连mono也没搞这个），真可惜。 os内核当然复杂，但我认为它主要用c来写的原因是为了运行效率，而非能更好管理源码。
如果用c++来写，可读性比c好，但os显然会把效率放在第一位，这道理是浅显易懂的 我也要学C++造LOLI 卖脸盆!! 好吧用汇编可以写出什么
我现在只记得这个了
页:
1
[2]