首先想用彙編寫的。但寫到最後暈頭轉向。沒辦法。先用c++驗證一遍自己的思路吧。**如下。
chashmap::chashmap()
chashmap::~chashmap()
free(m_nodes);
}bool chashmap::set(dword key,dword value)
}//刪除舊的.
free(m_nodes);
m_nodes = new_nodes;
m_size = new_size;
}pcnode node;
if(node= _getaddress_x(m_nodes,m_size,key))
return false;
}dword chashmap::get(dword key)
return null;
}bool chashmap::exists(dword key)
return false;
}bool chashmap::del(dword key)
else
if(keykey)else
}if(!node) return false; //沒有找到 返回了
if(!par_node) //根節點的情況
cur_node->left = left_node;
}}else
if(cur_node->left)
else
return true;
}/* 不是根節點的情況 需要 釋放 cur_node*/
if(cur_node->right)
node->left=cur_node->left;
}}else
if(cur_node->left)else
free(cur_node);
return true;
}// 這是乙個靜態方法，複製新的節點，並刪除舊的節點。
void chashmap::_setanddel_x(pcnode arg_nodes,dword arg_size,pcnode arg_node)
void chashmap::_del_x(pcnode arg_node)
/*如果相同鍵值的資料存在，會返回空。
這個方法是靜態的。
如果存在，它會給我乙個空間。如果不存在。它會分配好乙個新的位址。
*/pcnode chashmap::_getaddress_x(pcnode arg_node,dword arg_size,dword key)
while (node)
node = (pcnode)malloc(sizeof(cnode));
node->key=key;node->left=node->right = null;
if(key>t_node->key)
t_node->right = node;
else
t_node->left = node;
return node;
}標頭檔案:
class chashmap
//取容量尺寸
dword count() //取資料數目
dword get(dword key); //取資料
bool del(dword key); //刪除資料
bool exists(dword key); //資料是否存在
virtual ~chashmap();
private:
static pcnode _getaddress_x(pcnode arg_node,dword arg_size,dword key);
static
void _setanddel_x(pcnode arg_nodes,dword arg_size,pcnode arg_node);
void _del_x(pcnode arg_node);
protected:
dword m_size;
dword m_count;
pcnode m_nodes;};
重複發明輪子又何妨？
不要重 明輪子 軟體工程大師如此告誡。然而在我看來，很多情況下重 明輪子是非常必要的，按現在流行的話就是 必須的 當然，重 明輪子是需要特別慎重的，有意義並且值得做方可，而且這個要發明的輪子要具備足夠的創新。前些日子，乙個師弟要來我們公司實習，由於沒什麼相關經驗沒能如願。然後他就問，如何積累原始經驗...
發明輪子和學會發明輪子
一直以來,我都覺得現在中國的技術氣氛很浮躁.研究的都是別人的東西怎麼用,卻沒有辦法研究自己的技術.或許一直以來困擾我們的就是 不要重 明輪子 這句話.一直以來我們都認為自己不需要去研究底層的東西,因為那些輪子已經 發明 好了,不需要我們再去發明一次了.但是不需要重 明,不等於我們可以不會發明 輪子 ...
HTTPWebRequest請求 重複傳送
使用httpwebrequest請求別人的介面，請求了一次，但是對方卻收到了兩次同樣的請求，而且間隔時間為一分鐘，並且只有處理資料比較多的時候才會出現。因為我自己的 裡是有設定超時時間的，且時間設定的是5分鐘，webrequest.timeout 300000 排查了很久，最後發現是因為對方使用的 ...