哈，關注~

@OwnWaterloo

那個反向迭代器，是不是可以把正向迭代器當模板參數，在++里讓正向迭代器--，在--里讓正向迭代器的++，正向迭代器的end狀態當成反向迭代器的end狀態？

@OwnWaterloo

其實我個人基本不怎么會去繼承，也基本不會去多態，我喜歡用組合。但是難保別人不會，所以我經常隨手丟下虛析構函數

@OwnWaterloo

這么說來好像也很有道理...發現OOP的影子被你砍得一點不剩了，哈哈

@OwnWaterloo

一般來說，虛析構函數用于告訴使用者該類“可繼承”，是嗎？既然這里沒有什么不可告人的秘密，那么就隨他去好了。（當然，如果有人真要繼承，則必須了解里面的運作機制。這是他自己的事。）這樣理解可以嗎？

@OwnWaterloo

定義一個相似的類？

@OwnWaterloo

放著讓好事者(也就是將來某一時刻的我自己)去繼承...

@codejie
那，木有了

enum T
{
T1 = 0,
T2,
// ...
Tn,
T_MAX
};

讀 T_MAX 確定個數

@OwnWaterloo

就是傳說中可以打包提交的？
我以前有一陣子一直在找代碼托管，可惜都開源的，google code 只允許有一個私人項目。。。可我哪有那么多東西能拿出手呀，，于是，只好在自己機器搭了個svn。。

@zdhsoft

google那個規則怎么樣的？別人可以改我的嗎？

“線程安全”其實也沒有那么必要處處提到的，有點過于炒作的感覺。真要計較起來，大部分代碼都不是線程安全的。

@OwnWaterloo
這點有點明白了，一開始多了，而以后必須向下兼容，于是肩上的包袱就永遠卸不下來了，是嗎？

@OwnWaterloo

添加到無法再添加 我并不十分支持。
但是 減少直到無法減少，我也不盡贊同。我覺得 STL 里的東西，就是這種狀況，要什么沒什么，只能根據已有的少得可憐的東西去湊出來，換句話說，要用到日常開發中來，經常需要自己再包一層。

我覺得還是以方便使用為原則合理添加一些可有可無的東西比較好。。。

——目前的觀點，呵呵

@OwnWaterloo
1、這種巧合就是你先前說的GP中的“契約”吧。我心里就是有道坎跨不過去，覺得沒法在語法層面顯式呈現這個契約，，，唉

2、關于零依賴
我知道很多東西不可能做到零依賴，或者做到零依賴代價很大。
只是我的設想是，在一套東西里，有一個基礎部分，它只和語言特性有關、只有邏輯意義，這一部分要保持零依賴。其它實現各種實際功能的東西，可以有選擇的去依賴別的。如果把 Format 看成 String 的一種擴展功能，我本身在寫 String，為了實現 String 的一個功能，去使用了現有庫的這種功能，那我不過在做包裝而已，而不是寫東西了。

也許 Format 也算不上純屬 String 的功能，你后面給我的啟示看上去很有意義……

3、
multimap 確實不是這個語義，可能可以勉強湊合吧。只是我想不到非用 multimap 的場合……

我原本想搞個
template <typename IFirst, typename ISecond>
class ComplexIterator

想先 ISecond ++ 上去，到 End() 了 IFirst++，ISecond=IFirst->Begin()

然后直接 typedef ComplexIterator<typename Set<List<T>>::Iterator, typename List<T>::Iterator> MultiSet::Iterator

后來發現需要迭代器自己確定自己是否是 Begin，于是暫時放棄

關于反向迭代器，以及正向的，我一開始想各個容器能否以某種形式提供某一個 ++，-- 的機制，然后統一實現 Iterator，但是想不好用怎樣的形式……

@lo

呵呵，雖然其實一樣，不過也算個手段~

@expter

謝謝支持！

@CornerZhang

是。追溯到很久以前，其實我發明輪子的最初動力是 STL 里的 string 太難用。我就是想提供不一樣的使用方式。也排斥迭代器。最早寫的是一個類 vector 的東西，就不提供迭代器，照樣可以用得很爽。到要寫 List 的時候，就不行了，如果要不暴露結點，那么必須有類似迭代器的一套東西了。于是回過頭來想想 STL 的這套方式，覺得倒真不錯。所以又反過來學著它了。

@OwnWaterloo

那么說基本上不可以咯?

恕我2b了，第二種是什么用法？

這種使用方式看上去還是很爽的
同求消息機制

mark. thx.

@Johnson
一種認為指針優于引用的理由是，指針有時候更醒目，提醒開發人員，該函數要對傳入參數進行修改:


我也這么認為

@Johnson

RE。這一段不知道摟住再說什么

Win32 Console Application 不是運行在DOS虛擬機（NTVDM）下的，它是一個真真實實的 Win32 程序。它同樣可以使用 MFC 中的類。

與 GUI 程序相比，其實只是 PE 頭中一處標記不同而已。

被這樣面試過，就是被刷了也服了

@路人
這個說法好不嚴謹，這條射線與多邊形頂點相交、與邊重合的情況

@Ocean.Tu

“像女生的裙子”是怎么樣的？

@陳梓瀚(vczh)

所以堅決 Unicode、遠離庫函數嘛~

文件讀寫我覺得還是直接用 API 比較好。特別是文本文件。
1、反正不可能跨平臺
2、為了更好的支持 Unicode

@陳梓瀚(vczh)

嗯！這個方法不錯！

這樣能過：

class ArrayDimension
{
public:
int Data[MAX_ARRAY];
int Dimension;

ArrayDimension();
ArrayDimension(const int index);
ArrayDimension(const ArrayDimension &that);
ArrayDimension& operator,(const int index);
};


template<typename _Type>
class Array
{
private:
ArrayDimension DimensionInfo;

public:
Array(const ArrayDimension Info);
};

Array<int> arr((3, 2, 1));

@foxinhongyan

在追求性能的地方（如 ACM），通常不容易看到好代碼:)

@OwnWaterloo

非常歡迎吐槽~哈哈
關于侵入式和非侵入式，說實話我也是前幾天第一次聽你說。我稍微查了下，不是很確切的了解其含義。前面我在 Iterator 里放了個 Array *m_pArray，后來拿掉了，改成放一個 ValueType *，有沒有改變侵入式/非侵入式方面的屬性呢？

@OwnWaterloo

讀了這么多文字，真是受益良多。

但必須指出的是，上面對于 OOP 和 GP 的某些比較是不公平的。在 OOP 中，只有你需要去繼承它的時候（即你需要修改這個類），你才需要了解源代碼，需要了解跟實現相關的“契約”。如果僅僅是使用的話，那么，給出全部 public class 的 public method 的聲明，應該所有的使用者都不會犯語法錯誤，編譯器會提供完備的類型檢查。而同樣是使用（并不是去修改），GP 中，卻需要去了解它的實現，這不是很不公平嗎？我們不是追求為了隱藏不必要的細節，讓使用者減輕負擔嗎？當然，如果要去修改它，那么對它的實現是必須要了解的了。

@陳梓瀚(vczh)

我覺得，出現在具體實現上的編譯錯誤，本不應該留給用戶的。最好是在類型檢查的時候就能報錯。

@陳梓瀚(vczh)

嗯……iterator 一般有哪些約定成俗的規則？

@陳梓瀚(vczh)

virtual IEnumerator<T>* CreateEnumerator()const=0;

這個，到使用的時候：
IEnumerator<T>* p = CreateEnumerator();
然后求用戶去 delete 嗎？

@OwnWaterloo

如果有個 template <T> where T is IIterator，用戶看接口定義就知道該怎么做了；可是現在，只能到調用 Iterator 的某個具體方法的時候才報錯，用戶理解這個錯誤，就要理解我的實現了。這不僅增加了學習代價，還在一定程度上違背了封裝的初衷，不是么？一點變通的辦法都沒有嗎？

何處下載?

@OwnWaterloo

是的，現在是用不著 DWORD，但是以后一些功能庫會用到。
stdint.h 中的類型名稱似乎也不怎么干凈利索。
要不就直接用標準名稱好了？只是我很不喜歡 unsigned int, size_t 這種寫法。

@OwnWaterloo

1、關于 typedef

第一，我想我要寫的庫要保持獨立性。如果去包含了 Winows.h 了，那么就失去了這一部分的獨立性了。在做容器方面的東西的時候，實際上我根本不會用到 Windwos API，而這一 include，增加無畏的依賴的同時，還把平臺陷死了（雖然我不準備搞多么跨平臺的東西，但是明明可以不依賴的，還是不要去依賴，是嗎？）

我想，庫的用戶可能不需要去寫太多次 a::DWORD、b::DWORD，只要他們的定義是兼容的，傳入的值就可以用。

其實我最頭痛的就是 Windows.h 把這些名字都占去了，而且是全局的，是的用戶無法簡單地寫一個 DWORD 來定義 Windows.h 中的 DWORD 了。我知道加前綴不是好的解決方案，可是還有其他一套如此通用的名字嗎？

@OwnWaterloo

先謝過您的這么詳細的指點。等我仔細看過后再來提后續問題：）

@Pencil.C++

呵呵，客氣客氣。我也想著什么時候出個新版本，然后把舊版也開源開源，可就是沒時間搞了，郁悶~

@陳梓瀚(vczh)

你的意思是說 Tree::Node 沒必要暴露出來嗎？再問一下問一下，你覺得基礎庫里有必要存在二叉樹這種結構嗎？還有沒有必要以及可能包含圖的結構呢？

@陳梓瀚(vczh)

陳老師你好，我一年多前實習的時候因為公司不允許使用STL、MFC等等所有流行的庫，叫我們“用到的數據結構自己寫”。當時只寫了個 Vector、String，足以應付任務了。不過我就是從那時開始明白寫庫的意義，以及感受到用自己的庫的那種爽快的感覺的。

很佩服你的技術，粗看過你的代碼，我知道你把基礎數據結構全部實現了一遍，甚至regex，以及在代碼里寫 EBNF，等等。（我第一篇日志的開頭語不知道您看過了沒，呵呵）

我也想不走老路，不過有些東西可能不走一遍不會明白，所以我想可能先自然一點，到第二遍、第三遍再來總結以及回避已知問題。關于你說的4點，我比較想了解原因以及大概做法，可否稍微解釋下？特別是1和2，這個是現在就擺在我面前的。然后是3、4，我可以聽一聽，雖然可能不是馬上體會得到。

請問你這個有沒有發布過，發布名稱叫啥？（我是 xlWarKey 作者，這廂有禮了~）

@msnegg

Why nmake? Why not devenv or VCBuild, or cl ?