Skip to content

Conversation

edsko
Copy link
Collaborator

@edsko edsko commented Jun 27, 2025

Demonstration of the discussion at #788 (comment) ; not intended for merging.

@edsko edsko mentioned this pull request Jun 27, 2025
@edsko edsko force-pushed the edsko/zero-copy-demo branch 2 times, most recently from cf646eb to 0fade2f Compare June 28, 2025 06:15
@edsko edsko force-pushed the edsko/zero-copy-demo branch from 0fade2f to 87e275b Compare June 28, 2025 06:20
@dschrempf
Copy link
Collaborator

dschrempf commented Jun 30, 2025

I just had a look at this. Do I understand correctly:

The advantage of this approach is that we can directly refer to inner elements of nested structures/unions, without the need to first extract them level-by-level. This is because we provide composable, optics-like getters and setters (peekField/pokeField).

I like the approach. The generated code looks much cleaner also, but I guess this is partly because it was written by you :-).

@bolt12
Copy link
Collaborator

bolt12 commented Jun 30, 2025

I also took a look at this, looks nice, but I also wonder about if there are any cons of making a heavier use of type classes for larger code bases. I think it looks nicer and more correct in this way, but I think I find the currently generated code, more straightforward to read and a more direct translation of the C code. If the idea is to have a high level layer on top of the low-level layer anyway, is it worth the hassle of how things are generated ?

@dschrempf
Copy link
Collaborator

I think in this case it is also about speed. Copying fewer values is faster. But I totally see your point!

@bolt12
Copy link
Collaborator

bolt12 commented Jun 30, 2025

Oh that's right, I completely overlooked that! I think that's enough of a reason to do this then!

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

Successfully merging this pull request may close these issues.

3 participants