If try to apply forin feature to tBits.
 But I have two problems
1. function FindFirstBit has bug
try:
  List := TEnumBits.Create(10);
  List.bits[1]:=true;
  List.bits[6]:=true;
  writeln(list.findFirstBit(true));
  writeln(list.findNextBit);
  writeln(list.findNextBit);

should return -1, but exception received

2. findfirstbit is not multithread aware (because state is per object, not local)

Should I prepare patch?
Whats about used names?

2009/11/7 Dariusz Mazur :

If try to apply forin feature to tBits. But I have two problems 1. function FindFirstBit has bug

[skipped]

2. findfirstbit is not multithread aware (because state is per object, not local)

Yes, this is a good example why separate iterators are preferable to the ones built into container.

Should I prepare patch? Whats about used names?

IMHO your names (EnumSet/EnumClear) are ok.
Obviously, the implementation should not call FindFirstBit, but copy it's logic. To avoid code duplication,

I think you can to it the other way around -- let FindFirstBit create a enumerator and store it inside the TBits instance. It would be even better to drop FindFirstBit/FindNextBit altogether, but I do not know how large compatibility problem it might cause.

[skipped most of code]

IMHO, this code demonstrates an inconvenience of the current for..in implementation.
The last "operator enumerator" declaration is clearly redundant. I have two alternative suggestions here:
1) Let for..in accept the enumerator instead of the container as the second argument.
2) Define the trivial "operator enumerator" as above for some basic type, e.g. TEnumerator,
maybe in Classes.pp or even System unit. After that, one can inherit TBitEnumerator from TEnumerator to avoid the need for "operator enumerator" declaration.

Paul Ishenin, what do you think?

I think that it will be nice to have some extension to select paticular enumerator for the for-in loop but it is not yet available. And I think that your first suggestion will add undeeded ambiguity to the compiler since the expression can be a container and enumerator at the same moment.

Best regards,
Paul Ishenin.

Alexander Klenin pisze:

I'm not sure, but if this solution is not multithread aware too?

I've thinking about second solution. Now enumerator is passed through operator and its better, when always is the same.
For me it should be done in sysutils, similar as Exception

Yes, as I wrote below, the best solution would be to drop the current interface...

> It would be even better to drop FindFirstBit/FindNextBit altogether, > but I do not know how large compatibility problem it might cause.

... but _if_ the backwards compatibility is deemed important enough, my suggestion will allow to maintain it with the minimal code duplication.