[solved] macro for code ?

[MarkMLl]

The ordering is mandatory for sets and documented in ISO 7185.
As per my demo, the compiler is aware of that.

Yes, but the ordering is by virtue of the ordinal base type. It says nothing about the ordering of the storage.

MarkMLl

[440bx]

Yes, but the ordering is by virtue of the ordinal base type. It says nothing about the ordering of the storage.

MarkMLl

It is NOT by virtue of the ordinal base type.  ONLY an ordinal type can be used because there must be a 1 to 1 correspondence between a set element and a bit that represents the set element.

For instance, the range TRANGE = 500..550 is most definitely an ordinal base type but, it is not "virtuous" enough to be used in a Pascal set (at least not an FPC one.)  Therefore: that the base type is an ordinal type is NOT SUFFICIENT, which means, there are countless ordinal base types that cannot be used in the definition of a set because for one reason or another the compiler cannot establish a 1 to 1 correspondence between the type's ordinal values and the bit indexes.

In the case of 500..550, the problem is that FPC cannot use a base other than zero.  in a range such as 0..299, the problem is that while the starting ordinal is fine, the ending one exceeds the number of elements that FPC can have in a set.  I hope that this makes it crystal clear that "ordinal base type" is totally insufficient.

In the case of FPC, the only ordinal ranges that can be used must be in the range 0..255. if it's not in there, it's not usable because FPC enumerates the set elements 0..255.  In case it is not painfully obvious yet, that means FPC orders the elements of the set.

It is the internal implementation of sets in Pascal (and FPC) that puts strict limits on the ordinal types that can be used in a set definition.

In FPC, the ordering of the set elements will always be the same 0..255 (or less), therefore the ordering is not dependent on the base type, the only thing that is dependent on the base type is the number of elements in the set.   

all this is made patently obvious by the following definitions and the corresponding compiler behavior.

Code: Pascal  [Select][+][-]

1.  
2. type
3.   EnumA = (aa = 5, ab = 10, ad = 255);
4.   EnumB = (ba = 5, bb = 10, bd = 256);  { <-- this is an ordinal type }
5.   EnumC = (ca = 400, cb = 410);         { <-- also an ordinal type    }
6.  
7. var
8.   x : set of EnumA;  { 0..255 -> no problem }
9.  
10.   y : set of EnumB;  { <-- no can do        }
11.   z : set of EnumC;  { <-- no can do either }
12.  

[Joanna from IRC]

Is it really that hard to gather knowledge beyond what is documented ?  Just for the record, a lot of programmers don't find it difficult and in addition to that, some even find it rewarding. 

This phenomenon is not limited to programmers 

[TRon]

It's not an insult, it's worse, it's a fact.

I was not referring to that and you bloody well know that.

Anyone who has read documentation knows that it very rarely covers every detail, it's up to the programmer (well... I should say, some programmers) to go beyond what is documented.  Again, that's not an insult, that's a fact.

In general, yes. In this particular case, no as it is documented and the compiler has provision for it to prevent the user from making that mistake. That someone chooses to ignore it is not on my account.

Just like, internally, FPC orders the elements that make up a set (can't say that sets are ordered because apparently it isn't obvious that it is their elements that are ordered) and it is at least good to be aware of that, because "for" loops absolutely need to have the elements they act on to be ordered for them to operate properly.

The obsession with wanting to know how a byte is ordered in memory is a basic understanding of how computers work. Can be ignored and then blame the compiler for behaving exactly as described but I find it silly with a capital S.

Is it really that hard to gather knowledge beyond what is documented ?  Just for the record, a lot of programmers don't find it difficult and in addition to that, some even find it rewarding. 

No idea why you would want to gain knowledge on a topic that is behaving exactly as described. Must be silly me to just accept what is documented and expect for this example of yours to fail. But you already knew that as well, which is why these exact numbers where chosen. Still that seems to not have been enough to make you understand, instead redirect to something silly as how things are internally stored while the internal storage has nothing to do with the topic.

Let's state the obvious again, by definition sets are collections of unordered elements, HOWEVER, for performance and implementation simplicity reasons, Pascal DOES order set elements.   Is it really that hard to comprehend that ?

And yet you seem to mistake sets for ranges. And nobody should care about internal storage whatsoever, again with the exception being a compiler developer, writing a debugger or are a reverse engineer. All of which are not of any concern for an ordinary developer.

riot is an option, not a verb 

[440bx]

"ordinary"... yes, that's a good description.

[TBMan]

I'm a new guy here, but how did the forum go from a sharing information for the betterment of all forum, to a "I know more than you, nah nah nah" forum?

[Joanna from IRC]

I'm a new guy here, but how did the forum go from a sharing information for the betterment of all forum, to a "I know more than you, nah nah nah" forum?

the simple answer would be because they are allowed to.. the more complicated answer would be that they have character flaws that make them feel entitled to sneer at any code that isn’t theirs. I’ve seen the same behavior as this on a dying gaming server. Small group of not so fun people looking for fights.. something really should be done about this....

[440bx]

... they have character flaws that make them feel entitled to sneer at any code that isn’t theirs. I’ve seen the same behavior as this on a dying gaming server. Small group of not so fun people looking for fights.. something really should be done about this....

LOL... at least you don't hide where you're coming from.   Good one!

[Tomas Hajny]

It seems that the discussion of the original topic is finished now, let's not continue with something not belonging here... The topic is locked now.