Try this:
unit genericset (t);
interface
type genset=pointer;
(*! The functions getnext, getlast and getfirst must never be called on an
empty set. The function
getnext should never be called on the last element of a set. *)
procedure genericsetnext(var v:t;s:genset);
procedure genericsetfirst(
On Mon, Mar 11, 2013 at 10:54 AM, Daniel Gaspary wrote:
> On Mon, Mar 11, 2013 at 10:43 AM, Jonas Maebe
> wrote:
>> A set is basically a bitpacked array of boolean. Element X is set to true if
>> you add X to the set, and to false if you remove it again. That means that
>> if you have a set with
Ewald wrote:
Once upon a time, Mark Morgan Lloyd said:
No, because the elements in a set are dictated by their position. A
set that can contain anything between 0 and 256 elements occupies 8
bytes in memory with the (bit representing the) 0 element at one end
and the (bit representing the) 256 e
Once upon a time, Mark Morgan Lloyd said:
> No, because the elements in a set are dictated by their position. A
> set that can contain anything between 0 and 256 elements occupies 8
> bytes in memory with the (bit representing the) 0 element at one end
> and the (bit representing the) 256 element a
nday, March 11, 2013 7:42 PM
Subject: Re: [fpc-pascal] Set size limit
Here is a unit that could be useful.
Works with pentium and Win32; not tested with other CPUs or operating
system.
I hope you have 7zip, or I will create a zip file.
Greetings
Gerhard
- Original Message -
F
uot;
Sent: Saturday, March 09, 2013 9:52 PM
Subject: [fpc-pascal] Set size limit
Hi,
I am trying to create a Set Type...
TMyEnum = (me1, me2, me3); // more than 500 elements
TMySet = set of TMyEnum;
...but I get the following error:
"Error: illegal type declaration of set element
11.03.13, 22:10, Sven Barth wrote:
Generics do work for array, but maybe not for indices.
Only for type of element as I remember.
Also you'd need
to declare the operators anyway. Best solution in this case might be to
encapsulate the array in a record and define the operators there...
Maybe
Am 11.03.2013 14:59, schrieb Jonas Maebe:
On 11 Mar 2013, at 14:52, Sven Barth wrote:
If the array is a named one (e.g. "TMyArraySet = bitpacked
array[TMyEnum] of Boolean") then operator overloading could be used...
Yes, but since neither open nor dynamic bitpacked arrays are
supported, you
Daniel Gaspary wrote:
On Mon, Mar 11, 2013 at 7:09 AM, Mark Morgan Lloyd
wrote:
That was pretty much my gist. Since these days Unicode is larger than 65536
codepoints I don't think there's any advantage to expanding sets from 256 to
65536 elements, efficient operations on sparse arrays of 256-e
On 11 Mar 2013, at 14:52, Sven Barth wrote:
If the array is a named one (e.g. "TMyArraySet = bitpacked
array[TMyEnum] of Boolean") then operator overloading could be used...
Yes, but since neither open nor dynamic bitpacked arrays are
supported, you'd have to reimplement this for every sin
On Mon, Mar 11, 2013 at 10:43 AM, Jonas Maebe wrote:
> A set is basically a bitpacked array of boolean. Element X is set to true if
> you add X to the set, and to false if you remove it again. That means that
> if you have a set with 600 possible values, you need at least 600 bits,
> regardless of
Am 11.03.2013 14:43, schrieb Jonas Maebe:
On 11 Mar 2013, at 14:32, Daniel Gaspary wrote:
In my case the enum has near 600 elements.
TMyEnum = (me1, me2...);
The set though would never be used to contain more than 256.
TMySet = set of TMyEnum;
Is it not viable to modify the compiler to com
On 11 Mar 2013, at 14:32, Daniel Gaspary wrote:
In my case the enum has near 600 elements.
TMyEnum = (me1, me2...);
The set though would never be used to contain more than 256.
TMySet = set of TMyEnum;
Is it not viable to modify the compiler to compile the code and raise
an exception if I t
On Mon, Mar 11, 2013 at 7:09 AM, Mark Morgan Lloyd
wrote:
> That was pretty much my gist. Since these days Unicode is larger than 65536
> codepoints I don't think there's any advantage to expanding sets from 256 to
> 65536 elements, efficient operations on sparse arrays of 256-element sets
> would
Jonas Maebe wrote:
Provided that one calls a Z80 16-bit :-) More to the point: do any
current CPUs have e.g. vector operations that suggest a realistic
maximum size?
The current x86's bit test/set instructions support addressing the
complete 32/64 bit address space. But the original 8086 did
On 11 Mar 2013, at 10:39, Mark Morgan Lloyd wrote:
Jonas Maebe wrote:
On 10 Mar 2013, at 15:00, Juha Manninen wrote:
There are no 8-bit CPUs
supported by FPC that would justify it.
It is unrelated to 8 bit cpus. Even Turbo Pascal 1.0 ran on a 16
bit cpu.
Provided that one calls a Z80 16-b
Jonas Maebe wrote:
On 10 Mar 2013, at 15:00, Juha Manninen wrote:
There are no 8-bit CPUs
supported by FPC that would justify it.
It is unrelated to 8 bit cpus. Even Turbo Pascal 1.0 ran on a 16 bit cpu.
Provided that one calls a Z80 16-bit :-) More to the point: do any
current CPUs have e
Juha Manninen wrote:
No. As far as I understand, sets are stored in 1 byte internally - as
binary values. 256 is the max number of elements (bit values) it can
hold in a byte.
This is one area where FPC could actually improve things.
The 1 byte limit is purely historical. There are no 8-bit C
On 13-03-09 03:56 PM, Jonas Maebe wrote:
On 09 Mar 2013, at 21:52, Daniel Gaspary wrote:
The problem seems to be that TMyEnum has more than 256 elements.
Can I specify such Set with some compiler option ?
No.
My fpc is pre 2.6, any change on new versions concerning Sets limits?
No.
Jo
On 10/03/13 2:12, Jonas Maebe wrote:
There is a already a test for larger set support:
http://svn.freepascal.org/svn/fpc/trunk/tests/test/tset6.pp
Nobody has worked yet on implementing it, but if anyone thinks it's easy to do,
please go ahead. For larger sets,
especially if they are sparse,
On Sun, Mar 10, 2013 at 4:19 PM, Florian Klämpfl wrote:
>> This issue is similar. This kind of artificial limitation
> I always wonder how people know more than me about the compiler :)
>
>> could easily be fixed.
> Go ahead.
:)
Ok, I sent my reply too quickly. I must study the compiler at some d
On Sun, Mar 10, 2013 at 11:12 AM, Jonas Maebe wrote:
> For larger sets, especially if they are sparse, a simple hashtable-based class
> would probably be much faster and memory efficient
Just some background..
I was using a Set because I needed a initialized constant "container"
with a variable
Am 10.03.2013 15:00, schrieb Juha Manninen:
> This issue is similar. This kind of artificial limitation
I always wonder how people know more than me about the compiler :)
> could easily be fixed.
Go ahead.
___
fpc-pascal maillist - fpc-pascal@lists
On Sun, Mar 10, 2013 at 3:45 PM, Marco van de Voort wrote:
> Sets are up to 32-byte (256bits), enums can be up to 32-bit.
Ok, sorry. The limitation for sets is not one byte.
Still, FPC could add support for still more bytes. 64-bit CPUs are now
popular and the feature could easily be implemented
On 10 Mar 2013, at 15:00, Juha Manninen wrote:
> There are no 8-bit CPUs
> supported by FPC that would justify it.
It is unrelated to 8 bit cpus. Even Turbo Pascal 1.0 ran on a 16 bit cpu.
> I am annoyed by some LCL bugs which are there only for Delphi compatibility.
> This issue is similar.
I
On Sun, Mar 10, 2013 at 2:38 PM, Graeme Geldenhuys
wrote:
> No. As far as I understand, sets are stored in 1 byte internally - as
> binary values. 256 is the max number of elements (bit values) it can
> hold in a byte.
This is one area where FPC could actually improve things.
The 1 byte limit is
In our previous episode, Graeme Geldenhuys said:
> On 2013-03-09 20:52, Daniel Gaspary wrote:
> >
> > The problem seems to be that TMyEnum has more than 256 elements.
> > Can I specify such Set with some compiler option ?
>
> No. As far as I understand, sets are stored in 1 byte internally - as
On 2013-03-09 20:52, Daniel Gaspary wrote:
>
> The problem seems to be that TMyEnum has more than 256 elements.
> Can I specify such Set with some compiler option ?
No. As far as I understand, sets are stored in 1 byte internally - as
binary values. 256 is the max number of elements (bit values)
On 09 Mar 2013, at 21:52, Daniel Gaspary wrote:
> The problem seems to be that TMyEnum has more than 256 elements.
>
> Can I specify such Set with some compiler option ?
No.
> My fpc is pre 2.6, any change on new versions concerning Sets limits?
No.
Jonas
Hi,
I am trying to create a Set Type...
TMyEnum = (me1, me2, me3); // more than 500 elements
TMySet = set of TMyEnum;
...but I get the following error:
"Error: illegal type declaration of set elements" [1]
The problem seems to be that TMyEnum has more than 256 elements.
Can I specif
30 matches
Mail list logo
