Simplify SortStructuredArray / SortStructuredField

[helpy]

Starting with Version 5.10 the SortStructured... functions can be called like this:

Code: Select all

SortStructuredArray(Array(), Options, OffsetOf(Structure\Field), TypeOf(Structure\Field) [, Start, End])
SortStructuredList(List(), Options, OffsetOf(Structure\Field), TypeOf(Structure\Field) [, Start, End])

This could be simplified like this:

Code: Select all

SortStructuredArray(Array(), Options, Structure\Field [, Start, End])
SortStructuredList(List(), Options, Structure\Field [, Start, End])

PB can calculate Offset and Type from the given Structure\Field.

cu,
guido

[Little John]

+ 1

[Psychophanta]

+1

[Shield]

This wouldn't work since these are procedures. It would require special handling of those functions
by the compiler which isn't really a good way to go. What keeps you from just using a macro?

[luis]

I'm not sure it's a good idea.

You can use a macro to do exactly what you propose, and the current implementation makes possible to sort even through subfields not explicitly made available in the structure definition.
If you created the structure, you can edit the definition and split one field in two.
If you didn't, you must make a copy of the original definition and alter it, for example if you have a LONG field containing two distinct WORDS having separate meanings.
With the current version, you can sort by one of the words just by calculating the offset and using the #PB_Word flag.

I admit it's not something you do every day, but the current implementation is versatile and the macro can give you 100% of the functionality you requested.

Just pointing this out, it's up to the devs obviously.

[Little John]

for example if you have a LONG field containing two distinct WORDS having separate meanings.
With the current version, you can sort by one of the words just by calculating the offset and using the #PB_Word flag.

I'm not sure if that's a good idea. In a case like that, it would probably be much clearer and less error prone if the structure would actually contain two distinct WORD fields ("StructureUnion" can also be used if wanted).

I admit it's not something you do every day

I never did it during the last 20 years, and I'll probably not do it during the next 50 years.

the macro can give you 100% of the functionality you requested.

Of course it would be much more elegant, if this would be built directly into the respective sorting procedures.

E.g. now we have this in PB:

Position = FindString(String$, SuchString$ [, StartPosition [, Modus]])

Not long ago in an earlier PB version, the parameter StartPosition was not optional, and people made a request for that. This functionality could also very well be achieved by using a macro, but nevertheless in a subsequent PB version it has been built directly into the FindString() function ...

[luis]

I'm not sure if that's a good idea. In a case like that, it would probably be much clearer and less error prone if the structure would actually contain two distinct WORD fields ("StructureUnion" can also be used if wanted).

I said if you didn't create the structure. Why would I have suggested the possibility of copying it and modify the copy splitting the field otherwise ?

That said, ok, no problem, I can work around the problem by creating a copy of the struct... if this will be implemented.

I never did it during the last 20 years, and I'll probably not do it during the next 50 years.

Probably we did many different things we didn't share in the past, no good reason.

The findstring example is not pertinent in my opinion, making the param optional didn't make impossible to do something that was possible before. This does. It's possible to do the same again only indirectly through a copy and modification of the target.

But as I said, no big problem in any case.

[Little John]

I'm not sure if that's a good idea. In a case like that, it would probably be much clearer and less error prone if the structure would actually contain two distinct WORD fields ("StructureUnion" can also be used if wanted).

I said if you didn't create the structure. Why would I have suggested the possibility of copying it and modify the copy splitting the field otherwise ?

That was the part of your previous post which I didn't understand. Why would I use SortStructuredArray() or SortStructuredList() when I don't have a structure?

I never did it during the last 20 years, and I'll probably not do it during the next 50 years.

Probably we did many different things we didn't share in the past, no good reason.

That wasn't meant to be a "reason" for anything.
It was a reply to what you previously wrote:

I admit it's not something you do every day.

"Not every day" is very vague, and I just wanted to make a more precise statement in this regard (according to my own experience, of course).

The findstring example is not pertinent in my opinion, making the param optional didn't make impossible to do something was possible before.

As I tried to express, the FindString() example wasn't meant to be an example for the whole case which is discussed here, but only for the point that "You can do it with a macro" isn't in general a reason for not building a feature directly into a PureBasic function.

[luis]

That was the part of your previous post which I didn't understand. Why would I use SortStructuredArray() or SortStructuredList() when I don't have a structure?

You have instantiated the structure. You haven't defined the structure. Someone else did.
API maybe ? A third-party lib ?

Supposed there is a field as the one I described: a long. Used for example to store a Windows message code and a value associated with it, in its low and high words.

You want to sort by the message code. Now you can. Offset + #PB_Word.

With the proposed version you can't. You need to make a copy of the structure, split the long in two words, then use the new definition instead of the original.

That's what I meant. Again it's not Earth shattering, I just wanted to point it out since I prefer something versatile vs specialized when possible.

[Little John]

Luis, thanks for the explanation.

That was the part of your previous post which I didn't understand. Why would I use SortStructuredArray() or SortStructuredList() when I don't have a structure?

You have instantiated the structure. You haven't defined the structure. Someone else did.
API maybe ? A third-party lib ?

Supposed there is a field as the one I described: a long. Used for example to store a Windows message code and a value associated with it, in its low and high words.

You want to sort by the message code. Now you can. Offset + #PB_Word.

With the proposed version you can't. You need to make a copy of the structure, split the long in two words, then use the new definition instead of the original.

Yes, but that's the whole point of structures anyway: to have names for particular (adjacent) parts in memory, that allow us to write clearer and less error prone code.

Again it's not Earth shattering

I know. And I think the feature request itself is not earth shattering either.