1. 避免对shared_ptr所管理的对象的直接内存管理操作,以免造成该对象的重释放
    shared_ptr并不能对循环引用的对象内存自动管理(这点是其它各种引用计数管理内存方式的通病)。

  2. 不要构造一个临时的shared_ptr作为函数的参数。
    如下列代码则可能导致内存泄漏:
    void test()
    {
        foo(boost::shared_ptr<implementation>(new    implementation()),g());
    }
    正确的用法

    void test()
    {
        boost::shared_ptr<implementation> sp    (new implementation());
        foo(sp,g());
    }
  3. Employee boss("Morris, Melinda", 83000);

    Employee* s = &boss;

    This is usually not a good idea. As a rule of thumb, C++ pointers should only refer to objects allocated wth new.


copy:http://www.diybl.com/course/3_program/c++/cppjs/20090403/163770.html
posted @ 2009-10-27 18:54 西津渡 阅读(276) | 评论 (0)编辑 收藏
 
抄录备忘:
其实没有.h也能很好的工作,但是当你发现一个外部链接的函数或外部变量,需要许多份

声明,因为c++这种语言,在使用函数和变量的时候,必须将他声明,为何要声明?声明之后才

知道他的规格,才能更好的发现不和规格的部分.你别妄想一个编译单元,会自动从另一个

编译单元那里得到什么信息,知道你是如何定义这个函数的.

    所以说,只要使用到该函数的单元,就必须写一份声明在那个.cpp里面,这样是不是很麻烦,

而且,如果要修改,就必须一个一个修改.这真让人受不了.


.h就是为了解决这个问题而诞生,他包含了这些公共的东西.然后所有需要使用该函数的.cpp,只需要

用#include包含进去便可.以后需要修改,也只是修改一份内容.


请注意不要滥用.h,.h里面不要写代码,.h不是.cpp的仓库,什么都塞到里面.

如果在里面写代码,当其他.cpp包含他的时候,就会出现重复定义的情况,

比如将函数func(){printf};放到头文件a.h,里面还有一些a.cpp需要的声明等;

然后你发现b.cpp需要用到a.cpp里面的一个函数,就很高兴的将a.h包含进来.

注意,#include并不是什么申请指令,他就是将指定的文件的内容,原封不动的拷贝

进来.


这时候实际上a.cpp和b.cpp都有一个func()函数的定义.

如果这个函数是内部链接static的话,还好,浪费了一倍空间;

如果是extern,外部链接(这个是默认情况),那么根据在同一个程序内不可出现

同名函数的要求,连接器会毫不留情给你一个连接错误!

http://www.cnblogs.com/shelvenn/archive/2008/02/02/1062446.html



posted @ 2009-10-27 11:13 西津渡 阅读(164) | 评论 (0)编辑 收藏
 
 一.    Perspective and Metaphor

Platform
Kernel
Framework
二.    Philosophy and discipline
Be aware of context
Extreme maintenance
Be pragmatic
Extreme abstract: Program to an interface (abstraction), not an implementation
  
Extreme separation of concerns
Extreme readability
Testability
No side effect
Do not repeat yourself
三.    Principle
DIP ,dependency inversion of control
OCP , open close
LSP , liskov substitute
ISP , interface segregation
SRP , single responsibility
LKP, Lease knowledge principle
四.    design pattern
Construction
Behavior
Structure

五.    anti-pattern、bad smell
Long method
Diverse change
    Repeated code
    Talk to stranger
    Pre optimize
六.    algorithms
 nLongN
 Divided and conqueror
 

七.    architecture
Hierarchal
Pipes and filter
Micro kernel
Broker
Black Board
    Interpreter
   
八.    Distributed & concurrent
What to concurrent

Scalability
    Stretch key dimensions to see what breaks
九.    languages
Ruby
Erlang
assemble
C
C++
Java
Python
Scala

Be ware of different program paradigms.
十.    Performance
 Minimize remote calls and other I/O
 Speed-up data conversion
 release resource as soon as possible 

十一.    architectures' future
软件设计思想的发展逻辑,大致是提高抽象程度 ,separation of concern 程度。
    fn(design )=  fn1(abstraction )+ fn2(separation of concern).

由于大规模数据处理时代的来临,下一代设计范式的重点:
1.    将是如何提高distributed(--concurrent) programing 的抽象程度 和 separation of concern 程度。
2.    dsl ,按照以上的公式,也确实是一个好的方向。
十二.    Reference
<art agile software development>
<prerefactor>
<design patterns>
<beautiful architecture>
<refactor>
<pattern oriented software architecture>
<extreme software development>
<beautiful code>
<patterns for parallel programming>
<java concurrent programming in practice>
<java performance tuning>
<the definite guide to hadoop>
<greenplum>
<DryadLINQ>
<software architecture in practice>
<97 things architecture should known>
http://en.wikipedia.org/wiki/Programming_paradigm



posted @ 2009-10-16 13:13 西津渡 阅读(2076) | 评论 (0)编辑 收藏
 
拷贝
mingliu.ttc  simsun.ttf  SURSONG.TTF  tahomabd.ttf  tahoma.ttf  verdanab.ttf  verdanai.ttf  verdana.ttf  verdanaz.ttf

 #mv simsun.ttc /usr/share/fonts/local/simsun.ttf
#cd /usr/share/fonts/local/
sudo mkfontscale
sudo mkfontdir

sudo fc-cache
cp fonts.scale fonts.dir
sudo chmod 755 *
sudo chkfontpath --add /usr/share/fonts/local/

#/etc/init.d/xfs restart
查检是否安装成功

fc-list |grep Sim

 NSimSun:style=Regular
SimSun:style=Regular
SimSun\-PUA:style=Regular




posted @ 2009-08-14 17:48 西津渡| 编辑 收藏
 
experience learned.

1. first think algorithm before concurrent
2. first solve top problem
3. memory can be problem with huge data processing
4.  not to use refletion frequently
5. prefering strategy that can optimize both cpu and memory .

technical
1. thread synchronizing is how to queuing
   be sure to use "while(!Thread.currentThread.isInterupted())

2. prefer high level  synchronizing facility to low level methodology such as await,notify

3. dedicated sorter is much faster


 








posted @ 2009-07-22 18:07 西津渡 阅读(138) | 评论 (0)编辑 收藏
 
以前听过用友的牛人关于软件设计范型的时代划分,记得不太准确,不过基本上是业界公认的。
大致上是:过程式、面向对象、组件、面向服务。
未来呢?我忘记了,抑或是 dsl ?

我以往也没有自己的认识,不过,最近我有自己的看法

软件设计思想的发展逻辑,大致是提高抽象程度 ,seperation of concern 程度。
    fn(design )=  fn1(abstraction )+ fn2(seperation of concern).


由于大规模数据处理时代的来临,下一代设计范式的重点:

  1. 将是如何提高concurrent programing 的抽象程度 和 seperation of concern 程度。
  2. 至于dsl ,我研究不多,不过,按照以上的公式,也确实是一个好的方向。

对于英文词语的使用,是因为,我想更能表达我的意思,不至于误解。见谅。
欢迎批评指正!
posted @ 2009-07-13 12:33 西津渡 阅读(1208) | 评论 (1)编辑 收藏
 
    只有注册用户登录后才能阅读该文。阅读全文
posted @ 2009-07-10 13:40 西津渡 阅读(1017) | 评论 (6)编辑 收藏
 
最近看的东西,备忘。
Dryad
DryadLinq
GreenPlum。

技术上看:
 Dryad 牛
 
商业上看,
  只有microsoft(Dryad),oracle (?),ibm (?)

  其他的cloud data engine 似乎难免被收购宿命,一如bea 。。。。etc .
  ?google (Sawzall) ?amazon
  ?hadoop ,pig

中国:
  ?友友系统
 




posted @ 2009-05-26 20:02 西津渡 阅读(149) | 评论 (0)编辑 收藏
 
Saas business

一.    chain
    customer : operator :application :feature: platform .
   
二.    operator
三.    application
    office
    erp
    mall
    game
四.    feature

    search engine
    monitor system
    security
    dynamic language
    special db system
    special file system
五.    platform
    virtual computing resource system
    cloud file system
    cloud db system
    cloud os

六.    chance
    big fish or small fish should find their way to survive.
posted @ 2009-05-22 18:34 西津渡 阅读(131) | 评论 (0)编辑 收藏
 
     摘要:   阅读全文
posted @ 2009-05-19 20:20 西津渡 阅读(1455) | 评论 (0)编辑 收藏
仅列出标题
共11页: 上一页 1 2 3 4 5 6 7 8 9 下一页 Last