Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feedbacks to design native memory methods #13

Open
elect86 opened this issue Dec 10, 2019 · 0 comments
Open

Feedbacks to design native memory methods #13

elect86 opened this issue Dec 10, 2019 · 0 comments

Comments

@elect86
Copy link
Collaborator

elect86 commented Dec 10, 2019

So, I'm getting some dilemmas right now and I'd like to hear some feedbacks

I finally recently implemented inline classes into native pointer management in kool (I was eager to do it, but always postponed because of other priorities)

Where you basically can do something like:

val intPtr = IntPtr(x) // x is a valid, already allocated area of memory
intPtr[1] = 5
val r = intPtr[0]

all for free, offsets are set accordingly to the pointer type

Now I already used that in the vkk playground (tmp branch) and I went for expliciteness, so write(adr: Adr) or write(stack: MemoryStack) to write the current struct at the given memory address or in the given MemoryStack. On the other side, constructor(ptr: BytePtr)s and read/native { } methods to read from native memory.

Here in glm, there was only some raw simple methods

// Vec2
    infix fun to(ptr: Ptr) {
        memPutFloat(ptr, x)
        memPutFloat(ptr + Float.BYTES, y)
    }

// Vec2 companion object
fun fromPointer(ptr: Ptr) = Vec2(memGetFloat(ptr), memGetFloat(ptr + Float.BYTES))

I'm planning to expand this area, by providing a constructor

constructor(ptr: FloatPtr) : this( { i -> ptr[i] } )

calling the corresponding functional programming constructor

This will work for all the vector and matrices, except the vectors using Longs (Vec1l, Vec2l, Vec3l and Vec4l), because they have the convenience constructor accepting just one Long, whose signature will clash with construct(ptr: LongPtr). In this cases, I'll keep the convenience constructor and renounce to the pointer one.

I'm incline to accept this small incoherence for these vectors type and provide a static method for those.

This is my first dilemma.

Second issue is the naming. At the begin I thought to go with to for writing and from for reading into an existing class (constructor otherwise).

But a part of me is pushing for explicit read and write methods.

What do you think, guys?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant