<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Hairy Pixels via fpc-pascal <<a href="mailto:fpc-pascal@lists.freepascal.org" target="_blank" rel="noreferrer">fpc-pascal@lists.freepascal.org</a>> schrieb am Sa., 11. Jan. 2025, 14:17:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="ltr">I was curious, is there any practical limit on the size of a set (32 bits and 256 values) and why they couldn’t be 64 bit or any other arbitrary size? The floor seems to be 4 bytes too but why not allow smaller sizes to save memory? Perhaps just a historical artifact but I was curious.</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Set are a minimum of 4 Byte by default cause that's how Delphi does them. Ifets you want smaller sets then use the $PackSets directive as Martin had written. </div><div dir="auto"><br></div><div dir="auto">The maximum is also based on what TP and Delphi allow. ISO Pascal for example suggests a maximum of 1024 elements instead, though they define this number to be implementation specific.</div><div dir="auto">In the end it's a decision of where to do the cut as at some size the majority of the set will be sparsely populated so it makes more sense to use a dedicated type instead (e.g. a hash set or something like that) that wastes less memory. </div><div dir="auto"><br></div><div dir="auto">Regards, </div><div dir="auto">Sven </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>