因为没有用Singleton模式，被人批不懂OOP！

alexhappy

原帖由 太平绅士 于 2009-1-12 16:47 发表
你帮我想想如何去掉main中这句吧, 我要u_once.hpp是header file only的, 不需要其他cpp的支持. 相信你的能力
__u_once< u_mutex >( );

如果没有这句话,
某些极端的多线程情况下, u_mutex对象仍旧可能被两次 ...

你用static type u_mutex = pthread_.....不就完了么

Kendiv

LZ的实现还是有问题，没有考虑线程安全。

使用C++的大多数项目，都存在“严重的过度设计”，为了那根本不知道再哪儿的所谓“弹性”，把代码弄的像鬼一样。

C++不是不好，大多数人根本不会用而已。谁还记得“简单就是美”的基本设计理念？

zt2620zt

把构造函数弄为private就够了。。。

fera

原帖由 emacsnw 于 2009-1-12 06:23 发表


本来懒得拍的，呵呵。
就事论事：
1）全局变量含有自定义类型的对象是大忌
2）全局变量的定义有依赖关系，更坏的是不同编译单元之间全局变量的依赖关系，一般来说应绝对避免。解决办法也是有的，比如通过 ...

回一个再接着看。

全局变量间有依赖关系是非常糟糕的情况，一般可以通过调整模块设计使他们变成模块间初始化关系的依赖，这样在系统bootstrap时可以按照模块的依赖顺序来加载。

一家之言。

fera

哥们你能看到symbian源码？nokia的？索爱的？samsung？~还是symbian的？

fera

原帖由 wwwsq 于 2009-1-12 14:29 发表
世界上有没有比操作系统更复杂更庞大的项目？没有吧？

真的假的？

lauxp

RemoteServer::RemoteServer()
{
       static int count;
      
       if (count++ > 0) {
            fprintf("只能存在一个RemoteServer实例\n");
            exit(0);
       }
       ....
}

有人竟然写出这样的代码..

zdschinaunix

从楼主的贴子来看，技术水平是很高的，但是有些观点完全不能认同。
1) 犯两次实例化的错误的概率本身就很小。
    必现的BUG一般都很好处理，只有小概率的BUG才难以修正，比如好几天才重现一次。必须认真对待。
2) 一般来说就是Fatal Error
    高质量的软件尽量排除Fatal Error，程序直接死掉是不能接受的.连内存不够，文件不存在都不能挂掉(exit)，需要提示用户错误原因，否则用户会非常困惑，感觉软件产品很不可靠。
3) 开发的时候打印一个错误信息.fprintf("只能存在一个RemoteServer实例\n");exit(0);
     a.在多线程下，打印是错乱的，很难看；
     b.如果打印很多，分析打印时可能会没有注意到一些关键的打印；
     c.LOG打印一般都是有缓存的，所以最后几句打印很可能不会被flush出来.
     d.发行版本一般都没有打印。
     e.测试人员很难看懂打印，用户更不用说。分析日志会占用开发人员时间，提高了软件成本。
4) 两次new RemoteServer()是完全可能的。
    只有LIB库或者对这段代码不熟悉的人完全有可能再new一次。这就带来了出错的可能。为了解决这个可能性，你必须要写文档说明或者注释，这会无谓地花费时间。且也许代码与文档不同步，也许根本就没有人看文档（谁喜欢看文档？）。
5) 在运行时才捕获这样的错误，但这样的错误很容易修正
     软件不可能完全“一次做好”，但是我们要尽量“一次做好”。如果单子模式能够一次做好，为什么不呢？
    与楼主共勉。

realmon

原帖由 duanjigang 于 2009-1-10 19:14 发表
不懂模式的路过。。。
大学时有个同学算法特别强，别人看到他解决了问题，总是很惊讶：呀。。。你这个是动态规划算法。。咦。。这个是分治算法。。。。。。
他很懵：我也不知道这个叫啥算法。。就这么解决的。 ...

这样的人多着呢

Knort

有时候不根据实际情况而盲目的一味套用模式，有时可能会适得其反