huaxiazhihuo

 
共2页: 1 2 
re: 回顾C++ 华夏之火 2017-07-17 11:32
@天下
C形式的dll显然不够用。其实,只要在c的基础上再做多一些工作,情况就会好很多,但是委员会向来追求大而全的陋习,比如要支持虚继承、要支持各种函数调用规定,要照顾各个编译器的自定义等等因素,因此导致就连最基本的统一的面向对象模型都迟迟未曾出现
re: 再议c++的面向对象能力之上 华夏之火 2017-07-12 13:45
@天下
不要天真,动态语言比c++好多了,c++内核就是一团混乱,只有独特口味的猿猴才会痴迷破烂c++,对这些geek来说,这并不是什么光彩的事情
re: stl的缺陷抽象不足 华夏之火 2017-07-10 14:08
@天下
mfc,xtream,qt都是垃圾,都不值得花时间。c++的gui开发,除了qt,似乎也没有更好的选择
re: 非完美的stl 华夏之火 2017-07-09 09:57
@万连文
系统api的标准化是客观原因,但是stl在二进制层面上的复用之难,真是令人发指。知乎c++板块上的人气比cppblog要更热闹。
re: 非完美的stl 华夏之火 2017-07-09 09:54
@天下
从c++17的提案上看,标准会对于stl的保守改进和迷糊认识,个人是彻底失望了。所幸的是,c++在大节上的进化还是可取的
re: 迭代器的抽象 华夏之火 2016-05-25 11:21
@linda
迭代器不仅仅是好东西,而是必须物,不可或缺。没有迭代器的抽象,要么就是延迟求值,要么代码就会写起来很痛苦
re: 挖坑,有空填坑 华夏之火 2016-05-11 19:12
@春秋十二月
和c++无关的事情。C#,java,python,javascript等,主要还是C#
re: 挖坑,有空填坑 华夏之火 2016-05-10 18:20
@Richard Wei
一直都想回来的,不过,可能也来不了,很多代码要写,并且还不是用C++开发。很久没用C++了
re: 挖坑,有空填坑 华夏之火 2016-05-10 10:03
老朽也排斥宏啊,但是,c++又没有反射,没有模式匹配,没有原生的tupple支持等等,在用这些好东西的时候,不用宏,就要写大量的重复代码。比如,f1函数返回值为tupple<int,string>。与其写:auto tt = f1();auto num=get<1>(tt);auto text=get<2>(tt);就不如用宏自动生成这三行代码,TUPPLE_VALUES(num,text,f1)
re: MFC,一开始就错了 华夏之火 2016-05-10 09:55
@呵呵
以90年代的标准来看,mfc还是很不错的。那个时候没有template,没有exception,业界对于面向对象的思考也没那么深刻。以那时的标准c++,没有编译器扩展,mfc真是相当不错
re: C语言复杂声明的本质与局限 华夏之火 2013-07-02 09:39
@tangzhnju
C++的复杂是多方面的,但引入更多关键字,估计将更加复杂
re: C语言复杂声明的本质与局限 华夏之火 2013-07-02 09:35
@Quon
不采用C专家编程的那一套办法,自然是故意的。但实质上,两者的本质都是一致的,你应该看得出来,因为你应该已经完整看完了 C专家编程
re: 键盘布局的改进之道 华夏之火 2013-06-29 16:25
@waiting4you
骂得好
re: 键盘布局的改进之道 华夏之火 2013-06-29 10:22
@jl
所有一直在做MFC的人都很悲哀,大悲剧。仔细学习Vczh大神的博客,不失为开阔眼界的捷径。在下眼界的开阔,走的是另外一条很长很长的弯路
re: 非理性拥护C++ 华夏之火 2012-11-23 23:21
@其实俺不是坏人
c的副作用相对来说没那么变态,只是细节太繁琐了,缺乏有效的语言工具来组织细节
re: 非理性拥护C++ 华夏之火 2012-11-23 23:19
@ooseven
c++本身也太复杂太自由了,对于同一个问题,总有很多种不同解决方法,并且每一种都有其存在的理由
@fzy
有必要支持那么多吗,只要typedef TRET (TClass::*P_METHOD)( TPARAM... )这一个就行了,void 确实比较特别
re: 非理性拥护C++ 华夏之火 2012-11-21 22:19
@人贵有自知之明
都已经说是非理性了,阁下又何必当真
re: 非理性拥护C++ 华夏之火 2012-11-21 22:17
@marvin
C++的语言核心还是很好的,就是整个业界很奇怪,都不知大家都在干什么。感觉应该是语言内部没有统一的表现,c只要内存二进制兼容就好了,而其他语言,基本上一开始就统一了平台,没有那么多鬼鬼怪怪
re: 非理性拥护C++ 华夏之火 2012-11-21 22:09
@123
谢谢,其实说得不好,很情绪化
re: 非理性拥护C++ 华夏之火 2012-11-21 22:08
@fzy
的确,一不小心,c++就会变得很乱,现在到处一片混乱
@Richard Wei
直接用function,会有心理负担,虽然没有必要
re: 范型编程杂谈 华夏之火 2012-11-16 17:52
在下比较喜欢使用C++中template的代码自动生成技术,由此感觉C++已通过泛型进入一个新的阶段。只可惜目前还曲高和寡
@罗朝辉
本灵巧指针只为构造共享对象,自产自毁,从不考虑承接外界的原生指针。提供思路而已,至于具体语法形式的考究,在下也不大感兴趣。
@无
2、在下觉得shared_ptr背后做的事情太多了,超出了它的原本要求。3、侵入式的理解,应该是针对是否影响了类的代码而言,与内存在哪应该无关,好比在下的这个实现,就是非侵入式。4、拷贝构造函数中确实笔误了,可参考后文改进版,析构也有改进,只是没写出来。5、开玩笑而已,感觉应该没问题的,在下暂时还看不出来,你帮忙分析分析
re: 基于堆栈上的字符串实现 华夏之火 2012-09-05 11:01
CStackString<1>......CStackString<N>会导致编译器生成N个类,确实会生成这么多类,但是,这些类的函数都在基类中了,只有一分。C++中,最后的执行文件中,不存在类这个概念,只有类的函数,也即是函数。至于构造函数,则全部被内联@zgpxgame
re: 难以割舍的二段构造 华夏之火 2012-07-09 17:11
NEW/DELETE的问题不大,主要是某些较耗资源的玩意,好比线程、文件、数据库连接,直接在构造函数中启动,会让人很纠结,觉得隐藏太多细节@哥没注册
re: 试论C++类库开发之难 华夏之火 2012-07-09 17:09
说得好,关键是这盘菜是否标准化,能否到处通吃。@哥没注册
re: 试论C++类库开发之难 华夏之火 2012-06-18 09:21
@jrry7
也许C++本身就不容许一统天下的东西存在。它喜欢自由、多样化的世界。就算没有性能的要求,开发人员都有自己喜欢的风格口味,众口难调
re: 难以割舍的二段构造 华夏之火 2012-06-18 08:59
受教了,可能是在下内心对于异常的排斥,所以总是要尽量避免这个东西@guilin
re: 难以割舍的二段构造 华夏之火 2012-06-15 17:13
好比一个服务器类,我们一般都是先定义一个对象变量,然后让变量开始监听端口并启动监听的线程,这也可以看成二段构造吧。难道你要定义服务器对象的时候,就让它在构造函数里面直接就开始监听并启动线程吗@guilin
re: 跨越Win8 Metro开发 华夏之火 2012-06-15 12:11
大家都在Windows和C++上练就一身过硬内功,不惧怕任何跨越
re: 难以割舍的二段构造 华夏之火 2012-06-15 11:42
在下也知道不应该这样用,只是碰到这样的需求,该怎么办,难道要用指针吗?@guilin
re: 难以割舍的二段构造 华夏之火 2012-06-14 20:41
?这些都是深度探索c++对象模型中的内容,每一个想在c++上有所作为的人必须先深度探索这本书。@春秋十二月
re: 难以割舍的二段构造 华夏之火 2012-06-14 17:45
是啊,在下也偏向于精简构造函数。对于多事的构造函数的代码,内心总是很排斥,本能的对于细节的感兴趣,或者这也是C++者们的通病@Richard Wei
re: 软命令接口的适用场合 华夏之火 2012-06-13 11:21
在这种软命令下,只能给对象发送消息,对象可以采取种种方式响应消息,甚至可在对象外面响应消息,在外面截取消息,不让消息流进到之前的消息处理中。这样,就不会存在什么复杂类层次结构。这种方式,在下认为并不是“单一入口的Faced模式”,而是几乎包含了所有接口的变种桥接模式
re: C++11新特性不完全测试 华夏之火 2012-06-13 00:27
夜盼日盼,盼C++11横行天下,到时用c++来写代码就爽了,最起码,函数式的编程,在c++中,不会显得那么丑陋。要是c++11不丢弃concept,那么,我会考虑全信心投入template中。
re: 一个高效的内存池实现 华夏之火 2012-06-13 00:23
对于c++类中的这种通过operator new,来使用特制的内存池的接口方式,我咋觉得很难受。如果类的内存池可由用户来指定,那就很好了。不过我思考了很久,一直都找不到好的方式,实现出来的效果,总是使用的接口太难看了。最后,我心一横,需要内存分配的对象,全部都是POD类型的,没有构造析构,这样用户想要指定什么内存池,就用什么内存池
嗯,这个,我也承认,努力进步吧。当然,在下也不奢望一个小时内就写完的代码,能显示出多大的火候@春秋十二月
至于《C++沉思录》,早在很久以前,就翻烂了。c++中的书,大概也只有老爷子的书还有点看头。现在写代码,做设计,都尽量不用继承,连接口,可免则免@Richard Wei
这种消息处理的方式,大概是仁者见仁,智者见智吧。这里的实现,让你觉得很难看,那只是因为缺乏了消息框架的支持,并且也是在下代码写得很急,没进行任何优化。但即使这样,也能显示出这种方式的好处,那就是这个类的任何变化,都仅仅是只需要再增加几个新的消息而已,不会影响用户的原有代码,也不要求重新编译。@Richard Wei
re: 基于堆栈上的字符串实现 华夏之火 2012-06-08 13:58
_alloca,在C++中,貌似并不是很推荐,据说会带来一些什么问题@春秋十一月
re: 基于堆栈上的字符串实现 华夏之火 2012-06-08 13:46
基于栈的内存分配器?在下也想看到,能否推荐一下。至于代码膨胀,在这里的实现中,自然不会存在,你应该知道WHY的@zgpxgame
re: 基于堆栈上的字符串实现 华夏之火 2012-06-08 09:52
代码中,我又作了修改。至于形如std::allocator的那种定制,也有其不足,比如,vector,因为采用不同的std::allocator的容器,都属于不同的类型的vector,并且vector之间还不兼容呢@春秋十二月
是的,这个设计很丑陋很限制。我已作了修改@Richard Wei
re: 模板技术与应用(2): 类型选择 华夏之火 2012-06-06 14:14
第一次看到这些神码时,很激动。这么长时间过去了,现实中还真不容易找到它们的应用场合
re: WINDOWS与设计模式 华夏之火 2012-06-05 11:46
或者,设计模式能帮助码农写出好一点的所谓的面向对象的代码,但也可能将代码搞得更加复杂难懂了@123
re: 试论C++类库开发之难 华夏之火 2012-06-04 00:03
我也深受C++毒害,咱俩算是同病相怜@10年码农
re: MFC,一开始就错了 华夏之火 2012-06-02 02:08
可是,我要说的是,即使没有异常、dynamic_cast、type_info、template,甚至连虚函数都没有,都可以写出比MFC更好的框架@坏
re: 神奇的C数组 华夏之火 2012-06-01 23:08
先生要是觉得在下那样写变味了,那就算变味吧,在下只是表达自己对c数组的一点理解,旨在抛砖引玉,这不,就引来了您老人家的两块大玉了@泡菜
共2页: 1 2 

导航

统计

常用链接

留言簿(2)

随笔分类

随笔档案

搜索

积分与排名

最新评论

阅读排行榜

评论排行榜

60天内阅读排行