很久沒有來過了，都忘了自己曾經雄心勃勃的在這兒開了個博客~ 雖然天天在用C++，卻越發覺得自己的淺薄了；呵呵，年紀一大把了，也不知何時才能靜下心來真正的做點事情。

推薦兩個相關的RSS吧
http://www.ddj.com/rss/cpp.xml
http://www.ddj.com/rss/architect.xml

自己也要多看看，才能不斷的進步啊~

剛剛裝上VC8，發現VC8現在也支持hash_map了，終于可以不用STLPort了（不是不想用，而是在VC里面用太TNND麻煩了）。不過VC8上的hash-map還是有不爽的地方 1。它定義在stdext namespace 中 2。它需要至少specialize兩個template來添加自定義類。。。不過終究還是算不小的的進步啦;D =====================================


============ VC2005 ================
// test.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include
#include
#include

struct Key{
  int i;
};


namespace std {
  template <> struct less<::Key>
   : public binary_function<::Key, ::Key, bool>
  {
    bool operator()(const ::Key& _Left, const ::Key& _Right) const
    { // apply operator< to operands
      return (_Left.i < _Right.i);
    }
  };
}

namespace stdext {
  template <> size_t hash_value(const Key &key){
    return hash_value(key.i);
  }
}

int _tmain(int argc, _TCHAR* argv[])
{
  stdext::hash_map testmap; 
  Key k;
  k.i = 1;
  testmap[k] = std::string("hello, world");
  testmap[k] = std::string("hello, again");

  std::cout << "size of map: " << testmap.size() << std::endl;
  return 0;
}

============GCC + STLPort ===========
struct Key {
  ...
};


namespace std {
  template <> struct hash {
    size_t operator()(const Key &key) const {
        ...
    };
  }
}


int main()
{
  ...
}

posted @ 2007-04-03 14:01 Neal 閱讀(2029) | 評論 (1) | 編輯 收藏

呵呵，歡迎大家訪問偶的網站哈
http://travian.infinites.net

做的很丑陋，不過偶不善于HTML嘛
嘿嘿

一種語言代表了一種思維，而思維決定了問題的解決方式。

?

從程序設計語言出現到現在已經經歷了四代。大多數高級語言都對應到第三代或四代程序設計語言。按其主要支持的編程模型（思維模式）分類，大致可以分為如下類型

1 ． 過程型：這類語言把應用抽象為序列化的操作步驟，其典型代表如PASCAL，C等。

2 ． 函數型：這類語言把應用抽象為函數（按定義，函數是從一個域到另一個域的映射）；它們試圖把問題分解為集合和集合間的函數關系。典型代表是LISP。

3 ． 邏輯型：這類語言把問題抽象為事實與規則的結合，試圖通過邏輯演算解決實際問題。典型代表是PROLOG。

4 ． 面向對象型：這類語言從上世紀80年代后迅速發展，這類語言試圖將實際問題抽象為獨立的對象以及對象間的交互，典型代表是早期的SmallTalk和Eiffel。

5 ． 面向數據結構型：這類語言將問題抽象為對結構化數據的操作，例如現在常用的SQL。

?

作為一個誕生與上世紀80年代初期的編程語言，C++被廣泛的認為是一種支持面向對象的語言；但是，我認為C++的偉大之處卻更多的在于（除了所提供完備的面向對象支持）它同樣提供了C的面向過程的編程模型以及只有少數高級語言能支持的范型編程（我更喜歡叫它面向算法的編程）。在實際的應用過程中，我們往往需要不同層次的抽象，C++所支持的廣泛的編程模型為我們提供了強大和靈活的工具，使得我們在設計和實現時能自如的選擇不同的模型，以最合理的（組合）方式解決問題。

?

不可否認，在當今的程序設計中，面向對象已經基本上是一統江湖，但它往往并不是最合理的選擇；例如在針對協議棧的開發中，使用面向過程的模型往往優于使用面向對象的模型（或許這也是為什么主流的電信設備供應商堅持使用C的原因？）；而在針對算法進行抽象時，使用面向對象的思維模式幾乎完全是不可行的（算法和對象間的不同之處是顯而易見的）；如果機械的運用面向對象思維，只能使最終產品的質量、可維護性、可讀性下降。

?

或許有人會問，那么應該如何選擇抽象方式呢？我覺得這個應該是因人和問題的不同而不同的，關鍵是在使用C++的過程中，多從這些方面進行思考、總結，以體會采用不同模式解決問題的優缺點，努力使用最合理的方式（或組合）對問題進行抽象并加以解決。我也常常為這些種種選擇而迷惑，因此在這兒也希望那些已經到了“不惑”層次的哥們多多指教。

?

當然，從另一方面來說，越多的選擇往往意味著越難的選擇，這或許也是為什么現在這么多人趨騖與更單純、更簡單的JAVA，C#的原因吧；但是當我們真正理解并掌握C++提供的這些編程模型時，我想我們會更加堅定當初選擇C++的信念;D

?

時間倉促，不正之處敬請指教。

C++中，經常用到對象（Object）、類（Class）和實例（Instance）等概念，一直對這幾個概念有些混淆，今天算是整理一下自己的思路，談談自己對這幾個概念的看法吧；希望不當之處大家能夠指出，也歡迎大家看看自己的看法。

從其定義來看，對象是指一個能完成特定操作，具有特定屬性的實體（Component）；類是具有相同屬性對象的集合（Group of Objects）。實例則往往被理解為一個對象的具體化。

對象更多的是一個概念，在象SmallTalk這類純粹的OO語言中，所有東西都是對象（MetaClass, Class, Instances）；而類在不過是一個特殊的、能作為模板創建實例的對象。（一直想弄個SmallTalk來玩玩，但終究沒有時間和精力去學習。）

在C++中，“對象”概念往往被模糊化，它不是一個能包括一切的概念，而在某些環境下成為能和類與實例相互替換的概念。

原因之一，或許是在C++對類的定義。C++把類定義為一個抽象數據類型（ADT）。而ADT只是一個實現上的概念，它在運行時并不存在一個對象所應該具有的特征（屬性和行為）。雖然C++中引入了運行時類型信息（RTTI，參看type_info類），但仍然很難把類當成一個對象。從這個角度來說，在實現時類可以看作是對象概念的代名詞。

原因之二，個人覺得應該是和使用這些概念的上下文有關。在使用C++時（包括設計模式），往往需要考慮兩個層次的抽象：
1. 編碼（實現）時的抽象
2. 運行時的抽象

在實現時，C++中，無疑類的概念和對象的概念是一致的，而實例則可以理解為一個類的實例化或一個對象的具體化；對應與Design Pattern，那些結構化的模式（Structural Patterns）更適合與這一層次的抽象。

在運行時，個人覺得對象更多的是和實例等同的。我們說某個對象和另外一個對象交互更多的是在表達某個類的一個實例和另一個類的一個實例進行交互，這個時候，對象不再是一個概念，而是被具體化了。而設計模式中的行為模式（Behavioral Patterns）則更適合與這個層次的抽象。

以上是我對這幾個基本概念的理解，請大家批評指教！
//bow

"C++ is a Culture"

這是我的第一篇文章，就用標準的C++思維開始吧。

"Hello, World"是我寫的第一個程序，它也是我第一篇文章的標題。以前很少寫東西，原因之一是發現自己總是無法表達自己。最近越來越發現能表達自己的重要性了，萬事開頭難，何不就從C++開始呢？就象十年前剛剛接觸C++時從一個"Hello, World"開始一樣。

C++的迷人之處在于它能讓我自由的表達自己的思想，能自由的控制自己的一切……它對我，或者對廣大C++愛好者而言，已經不僅僅是編程語言了，它是一種文化！文化是會發展的，所以我不會感到厭倦；文化是博大的，所以我感到自己的渺小；文化是包容的，所以我才希望自己能為它做出自己的貢獻，哪怕是一點點，自己也滿足了。

今后我會慢慢寫出一些我的心得，對C++，對Design Patterns以及一切我對這個文化的感悟……希望大家能喜歡，也希望大家和我一樣對C++充滿敬畏之情。

向Bjarne Stroustrup致敬！