哈，关注~

@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 ?