Features for Oxygene?

oxygene

(SH) #1

Good evening :slight_smile:

this thread is used for (possible) features for Oxygene and when possible JUST here.

So I would start with:

1)
Bitfields, like C does have, where you can define a struct with just bits and a proper syntax to it
(https://www.tutorialspoint.com/cprogramming/c_bit_fields.htm)

2)
Array of Const, like older Pascal supports (https://www.freepascal.org/docs-html/current/ref/refsu69.html#x181-20300014.4.6)

3)
Open Arrays, like older Pascal supports (was disscused in another thread here, but just for a summary of all possible features) (https://www.freepascal.org/docs-html/current/ref/refsu68.html#x180-20200014.4.5)

4)
An “Unaligned” Keyword like older Pascal has it (https://www.freepascal.org/docs-html/current/ref/refse82.html#x145-16700012.6)

Those were some features, which MAY be interessting for the RO-Team to implement, idk I just wanted to list them up and mark them as disscusable :wink:

P.S Does actually inherit Oxygene the “ordinal-principle” of object-pascal, because a subrange of this, which was posseble in the older-pascal,"TAlphabet = 'A'..'Z' which means, create a own char-type, which just allows A to Z and none other charachter from ASCII/Ansi/UJnicode…

https://www.freepascal.org/docs-html/current/ref/refsu4.html#x26-250003.1.1

Or this was also possible back then:
TEnum = enum(A, B, C,D) of Byte; TBla = TEnum.A..TEnum.C;
Which creates a type TBla, which just allows values between A and D (A,B,C,D)

Best regards,

Shpend


(Carlo Kok) #2

maybe. I have an issue for that somewhere, but the use of these is very rare.

Array of Object works just as well.

Again, array of something works just as well.

Afaik we don’t target a processor that doesn’t explicitly support unaligned access.

yes.

Not sure if we support that one. Never had a request for it.


(SH) #3

Wow, ok first thx for the response of it, but unfortunately, I have to say, that the last of your answering is not supported and it is a very cool feature and i used it much in fpc back then and it is a helpful way to limit some possibilities without being concerned about the checking because the compiler does it

Also, the TAlphabet = ‘A’…‘Z’ doesnt work, it fails at compiletime :frowning:

And for the openarrays, on the one hand it is right what you have said, but with one exception: the open_arrays in fpc were stack-allocated, so the function took ALSO stackallocated-arrays, which length was unknown to the compiletime, that was the good thing :slight_smile:

Lastly, Its correct, that they are not often used, honestly, I asked because he will use some of this in the livestream he mentioned, to optimize something for the rendering process on the gpu… so I wanted actually to also make use of it and avoid some ugly workarounds of it, but what to do.


(RemObjects) #4

Thanks, logged as bugs://79536


(Carlo Kok) #5

Logged a bug for a…z and enum ranges.

Not sure what you are referring to in your last paragraph


(SH) #6

With the last paragraph I meant the “Bitfields of C”.

Ok cool :slight_smile:

And am I still able to inspire you for the open-array stuff :smiley:

Whats your opinion about that, because I said for clarity, that the fpc functions could also take stackalloc-arrays which currently isnt supported in island/oxygene, just dyn. arrays which are heap-based allocated.
Actually a really good thing for performance issues ofc

And AFAIK, I think that on the compiler-implementation-lvl this shouldnt be THAT MUCH, to create, because its just should accept undefined-array-length of a stack-array


(Carlo Kok) #7

static arrays are support, have been for as long as Island is around though:

var x: array[0…10] of Byte; << 11 bytes, on the stack.


(SH) #8

Sry, seemingly I wrote to unspecific.

I know that oxygene does support the static-array which you mentioned above, but:

I mean that oxygene doesnt support that a method, which can take ANY static-array, which length is unknown at compiletime, for instance:

   method TakeAnySizedArray<T>(const any: array of T);   //any MUST BE a static-array butit can be any-sized, nevermind if passing 5-elements-array, or 100-elements-array or 10000-elements-array,, so the function takes always a reference to stack-allocated-array!

Because how it is at the moment:

method TakeAnySizedArray<T>(const any: array of T); //any is a dynamic array!

(RemObjects) #11

Thanks, logged as bugs://79540


(SH) #12

Guys, what actually are ur feelings about named tuples ?

Because, that would totally kill all useless senseless dataholder-records which are doing nearly nothing but keeps some data and being used in some methods, but with the unfortunate need of their names, so when you have more than 2 Values, it is quiet more useful when you have names to access them, because my own experience shows that this can truely leed to buggy code easily^^, when you made a mistake with the itemX…


(RemObjects) #13

Thanks, logged as bugs://79558


(RemObjects) #14

bugs://79558 got closed with status fixed.


(RemObjects) #15

bugs://79540 got closed with status fixed.


(Carlo Kok) #16

see https://github.com/remobjects/IslandRTL/blob/master/Source/Span.pas


(SH) #17

Aha, cool:

So when I create an instance-variable of Span for example, like:

myStackAllocatedArray := [0, 1, 2, 3, 4, 5, 6];

var span: Span<Char> := new Span<Char>(myStackAllocatedArray, 0, 3);

The span will understand “myStackAllocatedAray” as really stack-based and will not complain,that it must be a dynamic array?


(Carlo Kok) #18

Prety much. Except you’re mixing up integers and chars there.

These both work:


      var myStackAllocatedArray: array[0..6] of Integer := [0, 1, 2, 3, 4, 5, 6];

        var span: Span<Integer> := new Span<Integer>(@myStackAllocatedArray[2], 3); // starts at 2
        var span2: Span<Integer> := new Span<Integer>(myStackAllocatedArray, 3); // << starts at 0

(SH) #19

I just forgot to replace Char with integer ^^

But yeah, really nice, well done :slight_smile:

But I need to ask a bullet-question:

does here the span-constructor also understands a dynamic array, hmm, because otherwise it could get a bit handy when one just has a dynamic-array

But seen from the defintion, it pretty looks like, it should understands a dynamic array as well. because:

…Slice(aArray: array of T)… // looks like it understands it


(Carlo Kok) #20

It supports both pointers (and thus static arrays) and dynamic arrays.


(SH) #21

pretty damn nice :slight_smile:

Because, I have such a scenario in my 2D - Engine, where I can now just pass my raw pointer in there, really cool :slight_smile:


(Carlo Kok) #22

This topic was automatically closed 12 hours after the last reply. New replies are no longer allowed.