贴一个BitSet类，请大家拍砖^_^

tyc611

首先感谢你提出的建议，下面是我的一些看法

>> 考虑使用unsigned char代替unsigned long
请说明理由，谢谢。我之所以用unsigned long主要是从移位的效率来考虑的，因为当初的应用中存在大量移位运算

>> 去掉所有的inline关键字
大多数函数比较小，内联比较合适，可能个别需要商榷

>> 把所有的typedef和常数放在class之内
常数只用于类实现，应该放在类内部；但ULONG是提供给用户的接口中的类型，放在头文件中比较合适吧？

>> 不要检查内存分配失败
why?

>> friend函数不必成为friend
其实除了必须实现为friend的接口外，对于其它接口，是实现为friend还是成员函数，我一直不知道以何为标准，请指教

>> operator<<()是否应该为const？
恩，你是对的

>> 考虑使用numeric_limits<unsigned long>::digits。
这个用不着这么麻烦吧？

>> 考虑提供命名操作，如and。
>> 考虑提供swap操作
从执行效率来讲，应该实现swap操作，不然用等价操作代价太大。
其它这类操作还很多，这里并没有完全实现，如果需要可以自己做照写就行了。

awake

呵呵，我也只是按我的经验说的一点想法。

效率的问题，这里我不是很清楚，我建议你测试一下，改起来应该很方便吧。我人比较倾向于使用unsigned char而已。

inline关键字只是一个建议，有些编译器直接忽略了这个关键字。而且究竟什么时候inline，编译器会更清楚。

typedef放在类中也是可以提供给用户的。比如Container::value_type。

不要检查内存分配失败，这一点可以参考《Exceptional C++ Style》。1、似乎从标准上来将，当内存分配失败的时候是不应该返回空指针的。2、很多平台上从来不会出现内存分配失败的情况。3、真正没有内存的时候，你恐怕没有空间抛出异常了。4、其他。

那些friend函数好像没有访问私有成员，为什么要加为friend呢？

据说有些机器上不是每个字节都8位，这应该可以成为使用umeric_limits<unsigned long>::digits的理由了。

tyc611

>> 那些friend函数好像没有访问私有成员，为什么要加为friend呢？
对，我疏忽了
>> 据说有些机器上不是每个字节都8位，这应该可以成为使用umeric_limits<unsigned long>::digits的理由了。
接受建议，呵呵，不过我还真没见过这种机子

其它我再考虑下下，再次感谢