我的评论 - huaxiazhihuo

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++本身也太复杂太自由了，对于同一个问题，总有很多种不同解决方法，并且每一种都有其存在的理由

re: 略说成员函数指针及其模板的精简实现华夏之火 2012-11-22 09:27

@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++就会变得很乱，现在到处一片混乱

re: 略说成员函数指针及其模板的精简实现华夏之火 2012-11-16 17:55

@Richard Wei
直接用function，会有心理负担，虽然没有必要

re: 范型编程杂谈华夏之火 2012-11-16 17:52

在下比较喜欢使用C++中template的代码自动生成技术，由此感觉C++已通过泛型进入一个新的阶段。只可惜目前还曲高和寡

re: 轻量级共享对象的灵巧指针的实现华夏之火 2012-10-31 23:45

@罗朝辉
本灵巧指针只为构造共享对象，自产自毁，从不考虑承接外界的原生指针。提供思路而已，至于具体语法形式的考究，在下也不大感兴趣。

re: 轻量级共享对象的灵巧指针的实现华夏之火 2012-10-31 13:40

@无
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类型的，没有构造析构，这样用户想要指定什么内存池，就用什么内存池

re: 消息发送VS设计模式 C++沉思录的一练习题的另解华夏之火 2012-06-12 20:46

嗯，这个，我也承认，努力进步吧。当然，在下也不奢望一个小时内就写完的代码，能显示出多大的火候@春秋十二月

re: 消息发送VS设计模式 C++沉思录的一练习题的另解华夏之火 2012-06-12 20:43

至于《C++沉思录》，早在很久以前，就翻烂了。c++中的书，大概也只有老爷子的书还有点看头。现在写代码，做设计，都尽量不用继承，连接口，可免则免@Richard Wei

re: 消息发送VS设计模式 C++沉思录的一练习题的另解华夏之火 2012-06-12 20:40

这种消息处理的方式，大概是仁者见仁，智者见智吧。这里的实现，让你觉得很难看，那只是因为缺乏了消息框架的支持，并且也是在下代码写得很急，没进行任何优化。但即使这样，也能显示出这种方式的好处，那就是这个类的任何变化，都仅仅是只需要再增加几个新的消息而已，不会影响用户的原有代码，也不要求重新编译。@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之间还不兼容呢@春秋十二月

re: 高效、实用、安全的字符串，语法糖？奇技淫巧？华夏之火 2012-06-08 09:04

是的，这个设计很丑陋很限制。我已作了修改@Richard Wei

re: 模板技术与应用(2): 类型选择华夏之火 2012-06-06 14:14

第一次看到这些神码时，很激动。这么长时间过去了，现实中还真不容易找到它们的应用场合

re: WINDOWS与设计模式华夏之火 2012-06-05 11:46

或者，设计模式能帮助码农写出好一点的所谓的面向对象的代码，但也可能将代码搞得更加复杂难懂了@123