(Not hitchhiking the other thread...)

Mohsen wrote

Pascal sets can only contain values/enumerations whose ordinal value is <= 255.

As currently new language features are discussed I would vote to drop (or relax to some K ) this limitation. This would not break any existing code.

-Michael

What if someone is storing a set in a file, or a stream? Old version saves it, new version reads it, and all of the sudden the data isn't in the same format.

Jeff.

2015-10-15 14:58 GMT+02:00 DaWorm :

Currently size of sets can be different for different compiler options -
{$Z1}, {$Z2}, {$Z4}

2015-10-15 15:05 GMT+02:00 Maciej Izak:

Currently size of sets can be different for different compiler options - {$Z1}, {$Z2}, {$Z4}

Ops. It is for enums :\ my bad.

2015-10-15 14:58 GMT+02:00 DaWorm :

Yes, this would be a problem. But wouldn't this be an acceptable price for the improvement? After all, similar things happen with integers, which don't always mean the same thing, reals which changed format at least once in TP/Delphi's history, strings... Sure, we could stick with 256 elements sets, 16 bits integers, 255 characters strings, but we'd lose a lot of possibilities, wouldn't we?

No, it is not that simple. Lazarus would stop working completely.

Michael.

DaWorm wrote on Thu, 15 Oct 2015:

What if someone is storing a set in a file, or a stream? Old version saves it, new version reads it, and all of the sudden the data isn't in the same format.

Support for larger sets would not change the format of smaller sets. The amount of space a set takes up depends on the element type of the set and the {$packset x} setting. Neither of these would automatically change for existing sets.

That said, sets for 256 elements already take up 32 bytes. Larger sets will usually be quite sparse, which means that just increasing the size will end up wasting a lot of memory. It would probably be better to use a dedicated bitmap class (generic or not) instead that is more clever than just using a bit array (although you could still do that in the class, using a bitpacked array of boolean).

Jonas

Can you elaborate please?

Mattias

In our previous episode, Michael Van Canneyt said:

Sets have a size that is a function of the number of elements. (delphi mode per byte, fpc mode per 32-bit). I don't see how raising the max number of elements would affect Lazarus. F(nr of elements) would still give the same allocation size.

(it does matter that sets are allocated always from element 0 though)

There already is a lot of variation just run the below program for mode delphi and objfpc

{$mode objfpc}
type txxx = set of 50..60;
var x : txxx;
begin
  writeln(sizeof(x));
end.

mode delphi prints "2", objfpc prints "32"

I always considered the 256 extremely annoying since it makes sets and enums not very scalable. Raising the limit would also make bitindexing with larger numbers easier.

2015-10-15 16:14 GMT+02:00 Michael Van Canneyt :

Would you care to explain?

Well. Streaming allows max 32 elements in a set.
Since the current max size (256) is above that raising it, will not matter.

I wrote too quickly, it will not affect lazarus...

Michael.