Board index » delphi » FPC & BP- Set type problems

FPC & BP- Set type problems

(Crossposted to TP/BP newsgroup too, since it is now about BP too)

Quote
> >However it will probably get modeled after Delphi, and a 100% TP compatible
> >mode will only get implemented if it is possible.

> AFAICS, the only relevant difference between set storage in TP, BP, & D3
> is that a set which would need 3 bytes in TP & BP will need 4,
> inevitably, in Delphi.

No. There is at least one difference between the two, and at least
another one (though bigger) difference from the ideal situation
(ideal IMHO of course, only the number of elements determines the size
of the set, which is what you expect):

Thanks to FPC developper Jonas Maebe, who pointed this out. I often
played with sets, but always of enumerations like enum=(black,white);
which always start on 0, so this bug (also the initial report) was new
for me. (Both the BP as the FPC case, I generally don't know Delphi that
intimate)

If you use sets of subranges, you find most of the differences.
Specially if the ranges go over a multiple of 8.

-----------
{$apptype console} {for delphi. I tested with 4}

type enum1=set of 0..3;
     enum2=set of 1..4;
     enum3=set of 2..5;
     enum4=set of 3..6;
     enum5=set of 4..7;
     enum6=set of 5..8;
     enum7=set of 13..17;
     enum8=set of 15..24;

begin                    {first: BP 7.0 second: Delphi Third: (if
specified: (#elements div 8)}
                          {FPC are all 4}
 writeln(sizeof(enum1));  { 1 1 }
 writeln(sizeof(enum2));  { 1 1 }  
 writeln(sizeof(enum3));  { 1 1}
 writeln(sizeof(enum4));  { 1 1}
 writeln(sizeof(enum5));  { 1 1}
 writeln(sizeof(enum6));  { 2 2 1}
 writeln(sizeof(enum7));  { 2 2 1}
 writeln(sizeof(enum8));  { 3 4 2}

end.

 

Re:FPC & BP- Set type problems


JRS:  In article <397F4568.2057B...@stack.nl> of Wed, 26 Jul 2000
22:09:12 seen in news:comp.lang.pascal.borland, Marco van de Voort

Quote
<mar...@stack.nl> wrote:

>(Crossposted to TP/BP newsgroup too, since it is now about BP too)

>> AFAICS, the only relevant difference between set storage in TP, BP, & D3
>> is that a set which would need 3 bytes in TP & BP will need 4,
>> inevitably, in Delphi.

>No. There is at least one difference between the two, and at least
>another one (though bigger) difference from the ideal situation
>(ideal IMHO of course, only the number of elements determines the size
>of the set, which is what you expect):

Not if one has read the manual; possibly not if one has considered
implementation efficiency.

Quote
>Thanks to FPC developper Jonas Maebe, who pointed this out. I often
>played with sets, but always of enumerations like enum=(black,white);
>which always start on 0, so this bug (also the initial report) was new
>for me. (Both the BP as the FPC case, I generally don't know Delphi that
>intimate)

>If you use sets of subranges, you find most of the differences.
>Specially if the ranges go over a multiple of 8.

>-----------
>{$apptype console} {for delphi. I tested with 4}

>type enum1=set of 0..3;
>     enum2=set of 1..4;
>     enum3=set of 2..5;
>     enum4=set of 3..6;
>     enum5=set of 4..7;
>     enum6=set of 5..8;
>     enum7=set of 13..17;
>     enum8=set of 15..24;

>begin                    {first: BP 7.0 second: Delphi Third: (if
>specified: (#elements div 8)}
>                          {FPC are all 4}
> writeln(sizeof(enum1));  { 1 1 }
> writeln(sizeof(enum2));  { 1 1 }  
> writeln(sizeof(enum3));  { 1 1}
> writeln(sizeof(enum4));  { 1 1}
> writeln(sizeof(enum5));  { 1 1}
> writeln(sizeof(enum6));  { 2 2 1}
> writeln(sizeof(enum7));  { 2 2 1}
> writeln(sizeof(enum8));  { 3 4 2}

>end.

So where is the difference between BP7 & Delphi, other than the case
which in BP7 would have a size of 3 bytes?

Every set takes the 32 bytes which a full set of 0..255 would need,
minus those bytes which can never contain a member of the actual set,
plus padding from 3 to 4 in Delphi.  Elements div 8 only gives a lower
limit; an extra byte may be needed because of the alignment within the
byte.

--
? John Stockton, Surrey, UK.  j...@merlyn.demon.co.uk   Turnpike v4.00   MIME. ?
 <URL: http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
 <URL: ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ;
 <URL: http://www.merlyn.demon.co.uk/clpb-faq.txt> Pedt Scragg: c.l.p.b. mFAQ.

Re:FPC & BP- Set type problems


Quote
> So where is the difference between BP7 & Delphi, other than the case
> which in BP7 would have a size of 3 bytes?

I probably misread something when I was merging this together, or forgot
the 3 byte thing for a moment.

Quote
> Every set takes the 32 bytes which a full set of 0..255 would need,
> minus those bytes which can never contain a member of the actual set,
> plus padding from 3 to 4 in Delphi.  Elements div 8 only gives a lower
> limit; an extra byte may be needed because of the alignment within the
> byte.

Sounds reasonable. Hmm. I still think the ideal case (with the pipelined
machines of today) would be ((elements+7) div 8), but I can see where it
is coming from, and maybe the wasted space is less important then
Delphi/TP compability.

P.s. Can Delphi do sets > 256 elements?

--

Marco van de Voort (Mar...@stack.nl or ma...@freepascal.org)

Re:FPC & BP- Set type problems


Dr John Stockton <j...@merlyn.demon.co.uk> wrote in message
news:313hhzGLr9f5EwQp@merlyn.demon.co.uk...

Quote
> JRS:  In article <397F4568.2057B...@stack.nl> of Wed, 26 Jul 2000
> 22:09:12 seen in news:comp.lang.pascal.borland, Marco van de Voort
> <mar...@stack.nl> wrote:
> >No. There is at least one difference between the two, and at least
> >another one (though bigger) difference from the ideal situation
> >(ideal IMHO of course, only the number of elements determines the size
> >of the set, which is what you expect):

> Not if one has read the manual; possibly not if one has considered
> implementation efficiency.

True, but a Set implementation that used the ~range~ of the members could be
implemented more efficiently, and would reduce their size and increase their
speed in many sets. A simple compile-time generated constant (the set type's
minimum value) could be subtracted from the passed ordinal value before it's
used to index the set.

Jay
--

Jason Burgon - Author of "Graphic Vision"
Professional Win95-style GUI for DOS/DPMI
Graphic Vision evaluation (version 2.04) available from:
http://www.jayman.demon.co.uk

Re:FPC & BP- Set type problems


JRS:  In article <39801FEE.B90A0...@stack.nl> of Thu, 27 Jul 2000
13:41:34 seen in news:comp.lang.pascal.borland, Marco van de Voort

Quote
<mar...@stack.nl> wrote:

>P.s. Can Delphi do sets > 256 elements?

AFAIK, no.  The Delphi 3 Language Guide just has sets of up to 256
elements; and when more is asked for in the Newsgroups, ISTR that use of
the TBits type is commended.

TBits gives a resizeable array [0..Size-1] of BIT, but as a replacement
for "set" it is rather severely (IMHO) handicapped by an apparent
complete lack of anything resembling a set operation.  It does have a
means of locating the first "0" bit.

I suppose one could define procedures & functions on TBits corresponding
to set operators - they should IMHO be impressively slow.

It should be better, though maybe less general, to use an array of sets
- cf. my pas-opt1.htm "Larger Sets".

--
? John Stockton, Surrey, UK.  j...@merlyn.demon.co.uk   Turnpike v4.00   MIME. ?
 <URL: http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
 <URL: ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ;
 <URL: http://www.merlyn.demon.co.uk/clpb-faq.txt> Pedt Scragg: c.l.p.b. mFAQ.

Other Threads