1. 
   避免對(duì)shared_ptr所管理的對(duì)象的直接內(nèi)存管理操作，以免造成該對(duì)象的重釋放
   shared_ptr并不能對(duì)循環(huán)引用的對(duì)象內(nèi)存自動(dòng)管理（這點(diǎn)是其它各種引用計(jì)數(shù)管理內(nèi)存方式的通病）。
2. 
   不要構(gòu)造一個(gè)臨時(shí)的shared_ptr作為函數(shù)的參數(shù)。
   如下列代碼則可能導(dǎo)致內(nèi)存泄漏：
   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

抄錄備忘：
其實(shí)沒有.h也能很好的工作,但是當(dāng)你發(fā)現(xiàn)一個(gè)外部鏈接的函數(shù)或外部變量,需要許多份

聲明,因?yàn)閏++這種語言,在使用函數(shù)和變量的時(shí)候,必須將他聲明,為何要聲明?聲明之后才

知道他的規(guī)格,才能更好的發(fā)現(xiàn)不和規(guī)格的部分.你別妄想一個(gè)編譯單元,會(huì)自動(dòng)從另一個(gè)

編譯單元那里得到什么信息,知道你是如何定義這個(gè)函數(shù)的.

    所以說,只要使用到該函數(shù)的單元,就必須寫一份聲明在那個(gè).cpp里面,這樣是不是很麻煩,

而且,如果要修改,就必須一個(gè)一個(gè)修改.這真讓人受不了.

.h就是為了解決這個(gè)問題而誕生,他包含了這些公共的東西.然后所有需要使用該函數(shù)的.cpp,只需要

用#include包含進(jìn)去便可.以后需要修改,也只是修改一份內(nèi)容.

請(qǐng)注意不要濫用.h,.h里面不要寫代碼,.h不是.cpp的倉庫,什么都塞到里面.

如果在里面寫代碼,當(dāng)其他.cpp包含他的時(shí)候,就會(huì)出現(xiàn)重復(fù)定義的情況,

比如將函數(shù)func(){printf}；放到頭文件a.h,里面還有一些a.cpp需要的聲明等；

然后你發(fā)現(xiàn)b.cpp需要用到a.cpp里面的一個(gè)函數(shù),就很高興的將a.h包含進(jìn)來.

注意,#include并不是什么申請(qǐng)指令,他就是將指定的文件的內(nèi)容,原封不動(dòng)的拷貝

進(jìn)來.

這時(shí)候?qū)嶋H上a.cpp和b.cpp都有一個(gè)func()函數(shù)的定義.

如果這個(gè)函數(shù)是內(nèi)部鏈接static的話,還好,浪費(fèi)了一倍空間；

如果是extern,外部鏈接(這個(gè)是默認(rèn)情況),那么根據(jù)在同一個(gè)程序內(nèi)不可出現(xiàn)

同名函數(shù)的要求,連接器會(huì)毫不留情給你一個(gè)連接錯(cuò)誤!

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

 一.    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

軟件設(shè)計(jì)思想的發(fā)展邏輯，大致是提高抽象程度 ，separation of concern 程度。
    fn(design )=  fn1(abstraction )+ fn2(separation of concern).

由于大規(guī)模數(shù)據(jù)處理時(shí)代的來臨，下一代設(shè)計(jì)范式的重點(diǎn)：
1.    將是如何提高distributed(--concurrent) programing 的抽象程度 和 separation of concern 程度。
2.    dsl ，按照以上的公式，也確實(shí)是一個(gè)好的方向。

十二.    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

拷貝
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

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


 

以前聽過用友的牛人關(guān)于軟件設(shè)計(jì)范型的時(shí)代劃分，記得不太準(zhǔn)確，不過基本上是業(yè)界公認(rèn)的。
大致上是：過程式、面向?qū)ο蟆⒔M件、面向服務(wù)。
未來呢？我忘記了，抑或是 dsl ？

我以往也沒有自己的認(rèn)識(shí)，不過，最近我有自己的看法

軟件設(shè)計(jì)思想的發(fā)展邏輯，大致是提高抽象程度 ，seperation of concern 程度。
    fn(design )=  fn1(abstraction )+ fn2(seperation of concern).


由于大規(guī)模數(shù)據(jù)處理時(shí)代的來臨，下一代設(shè)計(jì)范式的重點(diǎn)：

1. 將是如何提高concurrent programing 的抽象程度 和 seperation of concern 程度。
2. 至于dsl ，我研究不多，不過，按照以上的公式，也確實(shí)是一個(gè)好的方向。

對(duì)于英文詞語的使用，是因?yàn)椋蚁敫鼙磉_(dá)我的意思，不至于誤解。見諒。
歡迎批評(píng)指正！

    只有注冊(cè)用戶登錄后才能閱讀該文。閱讀全文

最近看的東西，備忘。
Dryad
DryadLinq
GreenPlum。

技術(shù)上看：
 Dryad 牛
 
商業(yè)上看，
  只有microsoft(Dryad),oracle (?),ibm (?)

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

中國(guó)：
  ?友友系統(tǒng)
 

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.

     摘要:   閱讀全文