Forum > LCL
[solved] strange behavior with constant set
jamie:
For a test, and this would confirm if there were an issue building a SET parameter for the function of that or I am just blowing smoke! :o
have you tried using a CONSTREF instead of CONST?
Joanna from IRC:
--- Quote from: jamie on September 05, 2024, 01:09:53 pm ---For a test, and this would confirm if there were an issue building a SET parameter for the function of that or I am just blowing smoke! :o
have you tried using a CONSTREF instead of CONST?
--- End quote ---
I’m not sure what a consfref is?
--- Quote --- And I expect that OP's got range checking etc. turned off.
MarkMLl
--- End quote ---
that’s a bizarre accusation. Why would I not want range checking?
I’m using fpc mode but I never knew about the default set being truncated.
Cdbc I tried what you told me and it works. I’m still flabbergasted That it would truncate a set rather than adjust to the size needed.
Thanks everyone for the insights
MarkMLl:
--- Quote from: Joanna on September 05, 2024, 03:58:47 pm ---
--- Quote --- And I expect that OP's got range checking etc. turned off.
MarkMLl
--- End quote ---
that’s a bizarre accusation. Why would I not want range checking?
I’m still flabbergasted That it would truncate a set rather than adjust to the size needed.
--- End quote ---
If your range checking is on but a set is being truncated without warning at either compilation or runtime, my own feeling is that that should be considered an error. But you'd not posted a compilable example or told us exactly how you were building... /fortunately/ we can't all read your mind.
Somebody's mentioned that sets can contain 256 elements, but that is the /maximum/ number they can contain, and the manual is explicit that by default they're a longint... you did read that bit I quoted, didn't you?
So what's happening is that because you hadn't specified a set type it was defaulting to 32 elements, but then- apparently- silently discarding bits from an allocation. That's /wrong/, but at the same time your use of an implicit set type in that parameter list was arguably a bit dodgy... only a bit though, and I can sympathise.
There's a related problem where the shifting operator silently ignores an operand of larger than (I think) 31.
MarkMLl
Bart:
It seems that at least Delphi 7 behaves similar.
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---program test;{$ifdef fpc}{$mode objfpc}{$h+}//{$mode delphi}{$endif}{$apptype console} uses sysutils; Var Z: TIntegerSet; L: LongInt absolute Z; //using typecast here since D7 cannot do for..in loopbegin {$R+} if SizeOf(TIntegerSet) <> SizeOf(LongInt) then RunError(1); Z := [0,28]; writeln(IntToHex(L,4)); Z := [0,28,101,102]; writeln(IntToHex(L,4));end.
--- Code: ---C:\Users\Bart\LazarusProjecten\ConsoleProjecten>fpc test.pas
Free Pascal Compiler version 3.3.1 [2024/03/12] for i386
...
26 lines compiled, 0.2 sec, 73024 bytes code, 4580 bytes data
1 warning(s) issued
C:\Users\Bart\LazarusProjecten\ConsoleProjecten>test
10000001
10000001
C:\Users\Bart\LazarusProjecten\ConsoleProjecten>dcc32 test.pas
Borland Delphi Version 15.0
Copyright (c) 1983,2002 Borland Software Corporation
test.pas(27)
28 lines, 0.03 seconds, 29244 bytes code, 2973 bytes data.
C:\Users\Bart\LazarusProjecten\ConsoleProjecten>test
10000001
10000001
--- End code ---
As you can see both sets [0,28] and [0,28,101,102] are the same and no runtime error occurs with RangeChecking on.
Bart
Joanna from IRC:
Markml that might explain the cutting off adding things at 31 items but it doesn’t explain it ignoring the set of values over 100. They are perfectly valid. So there are really two issues, the truncating at 31 items and the ignoring a set of higher values.
Navigation
[0] Message Index
[#] Next page
[*] Previous page