人生半路, 杀出个程序

release下的?

@欣萌
啊哦, 有眼不识泰山, 真遇到做编解码器的了...

代码没看，但是要如lz所说的话，好无厘头的错误啊。。。

这个是引用计数的，没问题。
想想看，如果这个函数没有引用计数，那会带来无数的问题。

@欣萌
难不成您想自己做个ffmpeg？

@路过
ps：apr真的是做得很好：）

@路过
回访，容我说一句，lz这个东西写的确实不够好，这个不用看高超的实现就能判断。简单的说就是这个实现“不能用”。但是也不能说是垃圾吧？至少lz写的代码整整齐齐，没有注释也很容易看懂，基本方法也对。

“垃圾”这种说法，还是尽量别出现在这个站点比较好。

说到底boost是用事先构造单例对象的方法规避使用锁。
看来不使用锁和“使用时构造”这两个便利只能取一个，具体实现时要分析利弊了。

我觉得auto_ptr是C++里面典型的“因为设想太过宏伟，从而产生问题”的范例。

事实上大多数人为什么会想到用一个包装过的指针？害怕内存泄漏。那么我们需要的就是一个确定会在某一个域结束时把自身携带对象析构掉的指针，就这么简单。那么我们就实现一个没有赋值功能的auto_ptr就好了，一了百了。

而且我觉得这里面有一个逻辑问题：假设我们在大括号开始处建立一个携带对象的指针，并且确定在大括号结束的时候对象会析构掉，那我们有什么理由把它传递给大括号之外的代码呢？

debug的时候用的吧？

你不觉得把读取的每个单位的尺寸和单位数分开可读性更高么？一个函数调用的实参中出现了乘法，第一眼看上去肯定会觉得费解。

而且往高里说这是个设计理念问题，作为一个接口，让用户越少思考越好。

sizeof(XXX) * count = 总字节数，这是你想出来的，想这个问题难道不需要费力么？

第二个问题嘛，通用的解决方案是“优先级”

自动加一句日志指令？这个很难想象。。。倒是可以用宏实现。

我猜想如果没有(void)ERROR_##msg;这句，编译器会把前面的变量定义优化掉从而断言失效？

只是猜想。

两点不同意见：

1.
Mutex::~Mutex()
{
...
throw MutexError("pthread_mutex_destroy error");
...
}

这个绝对不可以有。。。

2.我觉得lock和unlock之间的代码不安全，如果抛出异常可能导致死锁。

—— xml和log

你说的这个问题， 是不能靠语言提供标准库来做的。
很简单， Qt用std::string了吗？ ACE用了吗？ MFC用了吗？

=============

这一句说的太好了，C++很大一部分的混乱的起因不是“没有标准实现”——当然很多时候确实没有标准实现，而是大家都要去实现。而且，那boost来说，boost曾经拒掉一个log方面的库，但是就算是boost里面有这个库，有多少人会去用？很多时候不是主观上不喜欢用，而是说boost，包括像stl这种东西，它们的编程哲学太强势，并且经常迥异于我们惯常的代码。

加法满足交换律

恩，上面那个回复里用“指针的指针”规避对象指针和函数指针的大小不一样这一点，挺好的。

给楼主提个建议: 这样的文章可能对写作者来说意义和乐趣都很大, 但是作为一个读者, 我实在感觉不出来"阅读的快感".

这种时候最好加上一个#pragma pack命令，对应于gcc好像是__attribute吧。

普遍的通用方法.

@yew98
同意, 排除写日志动作的互斥性还是得考虑一下.

@forgot
好啊, 你帮大家写一个吧, 我反正写不出来.@yew98

再来个迭代器吧, 这样就能方便使用那些算法了.

@陈梓瀚(vczh)
哦, 你说的是对的, 中看走眼了, 看见123就下意识的一位是尺度.

@陈梓瀚(vczh)
模板参数只能是常量的前提下, 这样搞和 intArray[3][4][5];有啥区别?

谢谢分享，很通用的设计，VCL类库里的TThread类基本就是这个样子。

说一点个人的想法：我自己写的类也差不多是这样，不过有一点差别：我个人认为“线程”和“线程要跑的任务”是两个东西，前者是内核对象（抱歉，我总是改不了用win32本位思考）的抽象，跟具体功能没关系，后者是功能的抽象，跟具体程序有关系。

所以我倾向于把static THREAD_API Routine(void* arg)分离出来，成为一个ITask接口。

这样做还有一个好处，当Thread跑完了Task的代码后可以阻塞在那里等待跑别的Task。

另外我对protobuf也蛮感兴趣的，但是我有点看不懂那个东西，功力太浅：）

这个东西的难度ms是解决"闪"的问题.

1 这个东西能实现逻辑层和UI层在不同线程里的事件机制? 没看出来.

2 这么执着的降低耦合,应该是比较大的程序里才有用吧? 但是模板机制只能在一个模块里使用,这个限制还是比较大的.

3 把耦合降到最小,似乎需要加一层"事件解释机制". 逻辑和UI的最大耦合不在于回调的形式上,而在于事件解释机制的分散.逻辑层发生的事件是诸如"底层数据更新"的事件,UI层的响应是"ListView重载入" 这样的, 把这些之间的解释和映射放到一起,无论什么形式的回调机制都可以.

纯个人感觉, 不要相信:)

这种只读内存的代码不会有什么问题。而且你这个代码访问的是静态内存sum。

@absolute
呵呵，我又来了：P
在只有debug使用的情况下，选个大差不差的常数就好了，狼不浪费其实也没什么关系，我自己要是搞这种东西一般都是为了查查内存泄露什么的

@expter
你这个重载的new其实不就是个mempool么？只不过分配的空间大小是个常数而已。

内存池这个东西，除了在频繁的申请和释放小块内存的情况下以外，似乎也没有多大效率优势吧。如果单单为了防治内存泄漏启用内存池，会不会有点得不偿失？而且对于服务类软件，仅仅在软件结束运行的时候成功释放掉所有内存这种防泄漏方式，是很不够的，因为服务一般会运行很长时间。

不过内存池在调试的时候倒是蛮有用的。

那些关于模板的标准问题我也不知道，但是那些关于引用的，是符合标准的。现行的标准（非c++09）规定右值只能绑定到const引用上。

编译器崩溃是bcb的bug，并且没有解决方案，我找过很久，根本没有。

关于那个我根本看不懂的宏，更不知道了。。。

总的来说，像你这种情况，我建议你用BCB制作界面，把功能代码全用MSVC搞成dll。

哈哈，有此经历人飘过。这种分号一般都是不小心打上的然后编译器检查不出来。

到底iter++和++iter有什么区别呢？
除了重载的操作符参数类型不一样以外。

你一个线程select几十个不就行了？

@金庆
要是把本该是参数的变量转换成成员变量,会带来更多的问题:
如何初始化? 你怎么设置它? 设置了以后能不能随便改动? 要不要加锁?...

而且你每次改动这个参数的类型都要找到头文件里再改一遍, 很麻烦.

本质上说, 一个只与某个方法有关的变量, 为什么要让类知道他的存在?

对,应该需要几个用几个

@mybios
一维的显示器？您没事吧？

另外，这个投影是成立的，4维投3维，三维再投成2维。

这个结果是动画还是静止的？

有一个纪录片专门讲述这方面，好像叫dimensions，你可以去找找

@黑色灵猫
良好的架构和程序员自身的习惯比什么机制都来的好,正解。可是也没好到连智能指针这种几乎没什么坏处的东西都丢弃吧？

这个看起来是客户端用的dll的一部分吧？

从代码没看出来“远程对象调用”这个主题啊，感觉就是把client和server之间的通信协议封装起来了，client看到的是一个接口，或者说proxy类，调用它的方法，它就按照一定的通信规约把命令传给server，再接收server传过来的结果，是这个意思吧？

这个还真么注意到，放在命名空间里也会替换么？

呵呵，这可能就是我不敢用boost的原因。
而且公司的人也不让用，连模板都不让用。

工作线程里最好还是不要做与界面相关的工作。这样很容易锁死，有时候根本注意不到，比如一不小心在工作线程里弹出个messagebox什么的。还是跟主线程发消息解决比较安全。

另外也很难搞清楚界面控件的线程安全性。

要想不携带void *参数，还是得用模板。