|
|
re: 谈目前项目组的代码提交制度 那谁 2010-07-09 21:43
@陈梓瀚(vczh)
话说我已经开始觉得搭建这个一个系统也是一个有利于他人的事情了....
re: C++的流设计很糟糕 那谁 2010-07-09 20:50
@Noock
我文章的目的,是要说明C++的这种机制存在缺陷,已经强调了很多次.你可以"规避"这个问题,不能否认我的结论.
re: 谈目前项目组的代码提交制度 那谁 2010-07-09 18:54
@Sparkle
是的,这样做才能严格控制checkin代码的质量,不可能随便改几行代码,也不说明改了什么,就让你提交到代码库中的.
re: C++的流设计很糟糕 那谁 2010-07-09 18:52
@Noock 是的,我测试了一下,确实不行.查了一些文档,发现是因为C语言里面认为,以%u输出char是正确的,比如这里: http://blog.csdn.net/wangyadong/archive/2009/05/22/4208013.aspx我把代码贴在这里: #include <stdarg.h> extern void my_printf(const char *format,...) __attribute__((format(printf,1,2))); #define printf my_printf int main() { char cc = -1; printf("cc=%u\n", cc); return 0; } void my_printf(const char *format,...) { // do the really fuck output } 使用宏替代掉系统的printf的作用是,用户可以完全不知道后面的改动,照常使用printf的功能.而你的LOG宏,只是规避了问题,没有解决我提出的log<<"hello"<<"world"无法判断结束符的问题,如果你有一种办法,可以不改变我用户的输入,而解决这个问题并且不带来新的问题,这个才算是解决吧.
re: C++的流设计很糟糕 那谁 2010-07-09 13:47
@Noock 请看这里: http://blog.chinaunix.net/u3/91522/showart_2054004.html我的做法会在项目组内禁止直接使用printf,而使用加上了__attribute__封装的函数. 紧跟着的问题是,如何能保证禁止直接使用printf呢,define宏解决.
re: C++的流设计很糟糕 那谁 2010-07-09 10:34
@Noock
"解决"问题应该是"自封闭"的,也就是不引入别的问题.在这里我提出的类sprintf的解决方式,带来的格式输入有误,缓冲区溢出等问题,我都有方法解决掉,这才叫"解决"问题.
你的第一种方式,带来的另外一个问题,你没有帮我"解决"掉,所以,你这不叫"解决"问题.
斗胆说一句,平时工作中,你都是这么给人"解决"问题的么?假设你是制造车的,我要解决代步问题,从你那里买辆车,如果还要担心刹车会失灵,这个能叫做"解决"问题么?
你的另一种方式,不是"解决"问题,相反,恰恰如我说的那样,是这种方式存在缺陷,你才要使用别的方式规避它,这也就反证了这个方式是存在缺陷的了.
你说到编译器不能解决所有的问题,我承认,但是要最大限度让编译器发挥作用来帮助解决问题,人的因素很不稳定,不能把项目的成败过多的放在这些不稳定因素中.
re: C++的流设计很糟糕 那谁 2010-07-09 00:47
说白了,你提供了这个机制,又不提供相应的检查机制,如何叫"解决"?
re: C++的流设计很糟糕 那谁 2010-07-09 00:45
@Noock
我上面已经回复了,你那个办法怎么叫解决?不是又引入了新的问题么?
"请问你如何从语法,编译器的角度避免用户没有输入最后那个end呢?"
你的另一种做法,不是解决,叫规避,谢谢.
re: C++的流设计很糟糕 那谁 2010-07-08 23:41
@Noock
行了,到此打住吧,我只想证明这个东西是确实有缺陷的.到此为止.
re: C++的流设计很糟糕 那谁 2010-07-08 23:27
@Noock
sprintf可以使用编译器的特性进行检查,gcc就可以做到.
re: C++的流设计很糟糕 那谁 2010-07-08 23:21
我在上面已经就这个方式进行了回复,恕我不再回复.
再说一句,给他人定性下结论之前,自己先看清楚问题,和别人的回复,同时自己去验证过可行性,谢谢.
re: C++的流设计很糟糕 那谁 2010-07-08 23:19
@Noock
请问你如何从语法,编译器的角度避免用户没有输入最后那个end呢?
re: C++的流设计很糟糕 那谁 2010-07-08 23:14
@Noock
你这个办法上面已经有人说过了.请看我的回复,谢谢.
re: C++的流设计很糟糕 那谁 2010-07-08 22:36
@陈煜
另外,这个问题跟flush没有一毛钱的关系,你这么问说明你对我提出的问题还是不了解,呵呵.
re: C++的流设计很糟糕 那谁 2010-07-08 22:04
@陈煜
行了,我证明了你说的办法不能解决我这里提的问题.就这样吧.
给他人下结论之前,麻烦你做过充分的验证,我在上面可是有给出可编译运行的程序的,谢谢.
re: C++的流设计很糟糕 那谁 2010-07-08 21:55
@陈煜
呵呵,我把那个codeproject的代码拉下来编译验证,正是我上面给出来的结论.麻烦你自己回头看看那份代码和我文章中的描述吧.
以那个项目的代码为例,在类basic_debugbuf的析构中调用了sync,这个函数中再调用output_debug_string输出字符.就是我文章中提到的情况:因为C++的流输出对输入参数的结束位置无法判断,只能在析构函数中做真正的输出.
另外那篇文章,太长了,我不去看了.
re: C++的流设计很糟糕 那谁 2010-07-08 18:11
@陈煜
那请您给出可运行的代码例子并且解决我上面的问题,谢谢.
re: 谈目前项目组的代码提交制度 那谁 2010-07-08 13:49
@sdww
提交到reviewboard,另一方面是为了让你做的改动是有白纸黑字可查的,如果只是口头上的说明,起不到这个效果,类似于工作中重要的事情需要发邮件确认.当然,这里也并没有排斥口头上的交流啊.
re: C++的流设计很糟糕 那谁 2010-07-08 13:08
@Noock
那请您就事论事说一说怎么解决我提的问题,谢谢.
re: 谈目前项目组的代码提交制度 那谁 2010-07-08 12:54
@陈梓瀚(vczh)
我是这么看的,因为linux下面并没有完整的这样一套系统,所以我们自己整合这些软件搭建这个系统的工作,类比于微软开发那套软件的工作.
而不是搭建这个系统的工作,类比于使用微软这套软件搭建系统的工作.
哦 我自己说的都拗口,但愿表达清楚意思了.
re: 谈目前项目组的代码提交制度 那谁 2010-07-08 11:55
@陈梓瀚(vczh)
另外,我们写的是服务器端的程序,必然不是跑在windows平台的,微软那套东西用不上.
re: 谈目前项目组的代码提交制度 那谁 2010-07-08 11:46
@陈梓瀚(vczh)
呵呵,请问你微软做好那个软件花了多少人力/时间呢?是不是说,你写一个软件完成要求的功能只花费了几秒,工作量就可以定为只有几秒呢?
re: 谈目前项目组的代码提交制度 那谁 2010-07-08 10:18
@cui
没懂你的意思?我是说把这些软件整合在一起搭建整个流程花了这么多时间.
re: 关于C++之“复杂” 那谁 2010-07-07 11:58
呵呵,那个帖子里面的意思不是为了说operator<<复杂,我那篇文章主要强调的是C++流输出对输入参数结束判断手段的缺失.那句"天哪"开头的抱怨,是指编译器在后面做了很多事情,要全部都了解到,代价太大.
re: C++的流设计很糟糕 那谁 2010-07-07 11:48
@陈梓瀚(vczh)
也有用模板,用模板创建callback,但是我不了解做法,只了解怎么使用,模板让我很崩溃,一直不想深究.
re: C++的流设计很糟糕 那谁 2010-07-07 11:47
@陈梓瀚(vczh)
"其实每一个细节都规定的十分清晰"
我还真没有觉得,也许是真的,但是要做到使用者也非常清晰,代价很大.就学一门语言的代价而言,我觉得过大,因为语言不是全部,还有很多需要学的,如果过分多的把精力放在语言学习上,我觉得有点本末倒置.所以,我现在只使用那些我清楚的,有把握的C++特性,你可以说我保守,但是我不是学生,没多少时间花在语言学习上.
re: C++的流设计很糟糕 那谁 2010-07-07 11:24
@陈梓瀚(vczh)
呵呵,不知道你有没有写过服务器端程序,多线程同时写log是肯定会存在的.
至于说的sprintf有缓冲区溢出问题,也可以有做法进行避免.
总之,我的结论是C++的流在判断输入结束方面存在缺陷,至于后面跟的帖子写的其他格式,则不是我关注的重点了,我这篇文章只为了说明C++的这个缺陷,这是我写这篇文章的目的.
另外,你那个微积分和几何的比喻放在这里不妥,两者不能解决相同的问题,不属于一个类型.
re: C++的流设计很糟糕 那谁 2010-07-06 22:35
to cui and cppexplore
我们看的不是一个地方,呵呵.
re: C++的流设计很糟糕 那谁 2010-07-06 22:26
@陈梓瀚(vczh)
另外,还有个问题,很难在编译语法层面保证你的最后一个输入是那个标记类吧....
re: C++的流设计很糟糕 那谁 2010-07-06 14:11
@陈梓瀚(vczh)
我想了想 你这样还是有问题的,比如一次输入几个参数 将会在几次函数调用中完成 如果我需要做到是多线程的 这一点如何保证呢?还是类sprintf那样的在一个函数中搞定所有的事情吧.
re: C++的流设计很糟糕 那谁 2010-07-06 14:03
@陈梓瀚(vczh)
C++的设计里面 编译器做了太多额外的事情 以至于你要用好这么语言不得不去多了解细节 我觉得这是很糟糕的地方 因为你需要付出很大的代价才能对这门语言有足够的了解.
re: C++的流设计很糟糕 那谁 2010-07-06 13:55
@陈梓瀚(vczh)
嗯,你说的那种方式 确实也是个办法吧.
@Kenny Yuan
我的意思是编译器生成的构造函数不知道会给类成员对象赋什么初值.如果自己写的话,给它们赋一个明确的初值,这样在出问题的时候一看,知道这些都是没有被初始化过的.
@OwnWaterloo
异常少量使用过,已经基本不用,观点已经在前面阐述过.如果一个特性,我认为会给我带来困扰,同时目前所掌握的,已经可以满足我的需求,为什么我还要花时间去多学呢.有时候选择过多,反而会带来困扰吧.这个是我的观点,无意强加于谁身上.同时,他人也无需强加于我身上.
"另外， 这种高压政策下的google的代码我没看过， 所以无法评论其质量高低。
但肯定是"原始且不美观"的。"
这句话里面的语调,我个人认为过于狂妄了,呵呵.
如果你不能心平气和的讨论问题,而使用一些自己臆断的词汇去描述,比如"原始切不美观","质量怎么可能高",我个人认为继续下去的意义不大.
@OwnWaterloo
我反对你以偏概全将使用异常的态度推及到指针使用,这不是具体问题具体分析的态度.
其次,你的语气有些过于狂妄了.就结果而言,google出品的这些软件,虽然大部分都看不到代码,从使用的角度看,质量是有目共睹的,反之看它们的一些规定做法,有可取之处,而不是像你所言的"质量怎么可能高".
我还是坚持我的看法,异常的使用导致了程序的走向难以从代码中一目了然的看出来,给问题定位带来困难.
@OwnWaterloo 另外,我见到的google开源出来的python代码不多,java我不会,就更没看过了,但是这份python代码: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py里面似乎就没有使用到异常.
@OwnWaterloo
那你能对规范中描述的异常的缺陷进行回复么?我里面提到的,由于引入了异常,导致代码走向难以预测,这一点如何解决?类似unix API那样的,根据返回值判断是否成功,根据errno判断失败原因,是非常简洁明了的做法,我更倾向于设计出这样的API.
@OwnWaterloo
又学了一个成语"因噎废食 ( yīn yē fèi shí )":原意是说，因为有人吃饭噎住了，索性连饭也不吃了，这太荒谬了。比喻要做的事情由于出了点小毛病或怕出问题就索性不去干
能解释一下在这里针对这个帖子做这个回复的含义么?
re: ccache0.6 版本发布 那谁 2010-05-06 00:39
@ping
你说的没错,之前这个问题一直没有发现,是因为我之前写的服务器程序都是父子进程的模式,能否给我留一个联系方式,我将在下一次修正这个BUG的时候在changelog中加入你的信息,谢谢.你可以在私人留言中给我留下联系方式.
re: ccache0.6 版本发布 那谁 2010-05-04 23:30
@ping
1.第一点我没太看明白,我的测试用例就是使用多进程去进行压力测试的,好像还没有发现问题.
2.这一点我也比较头疼,但是目前没有找到降低锁粒度的办法.find操作要加写锁,是因为根据LRU算法,每次访问过的节点,需要往链表头走一步,所以也有更新的操作.这样,经常被find的元素,就会越靠近链表头.
3.是的,这个算法类似STL中内存池的设计.
re: 方法与工具 那谁 2010-04-15 18:10
@陈梓瀚(vczh)
如你这样目标明确的使用工具,倒是很好,我不是反对使用工具,只是觉得不应该本末倒置,方法比工具重要.
re: 方法与工具 那谁 2010-04-15 12:54
@helloworld
呵呵,没有说不用吧,这里的意思只是强调方法比工具更重要些.
概念性的错误:mapreduce不是分布式文件系统,你说的应该是GFS.
re: memcached采用的网络模型 那谁 2010-03-12 14:02
@小阳
你的理解是正确的.
@阿福
当当前freepool超过一定数量时，会进行merge操作进行整理。
按位置排序是为了merge合并方便。
按尺寸排序是为了根据所要求的尺寸进行二分查找方便。
这两点前面一节都有提到。
@guest
因为tc相对而言较简单,对我入门阅读数据库实现比较方便
@helloword
推荐你去看看stevens的unix网络编程。
|