Skip to content

Conversation

@iscgar
Copy link
Contributor

@iscgar iscgar commented Mar 1, 2025

Rework the object attributes to avoid needlessly iterating over all of them when needing to save a specific object or load a specific attribute of an object.

While at it, add type verification for member serialisation. This caught an issue with the Group::forceToMesh member, which was incorrectly serialised as an int, rather than as a bool. Thankfully this didn't overwrite the next member because there are padding bytes in between, but we shouldn't continue to rely on this broken behaviour.

However, this change unfortunately breaks the tests, since the save logic skips int members which are set to 0, but not boolean members which are set to false. This now causes the Group::forceToMesh member to be emitted into the file where it previously wasn't. If we add the same logic to boolean as well, this would still break the tests because other boolean values were previously serialised. So we need to update the tests either way, but I'm not sure if I should just change the existing files, or back them up with _v31 added to their name, like the other ones which have _v20 and _v21. @ruevs, @phkahler please advise on the way to do it, and if I should change the boolean serialisation logic to match the one used for ints, and skip members set to false.

Also change the file saving logic so that it doesn't have to go through the sv member of SolveSpaceUI, which needlessly requires copying objects over and over.

This leaves sv to be used only as a temporary during file loading, but there's no reason to keep it as a member for this, so it is now made a local variable in the two functions that need it.

Rework the object attributes to avoid needlessly iterating over all of
them when needing to save a specific object or load a specific attribute
of an object.

While at it, add type verification for member serialisation. This caught
an issue with the `Group::forceToMesh` member, which was incorrectly
serialised as an `int`, rather than as a `bool`.

Also change the file saving logic so that it doesn't have to go through
the `sv` member of `SolveSpaceUI`, which needlessly requires copying
objects over and over.

This leaves `sv` to be used only as a temporary during file loading, but
there's no reason to keep it as a member for this, so it is now made a
local variable in the two functions that need it.
@phkahler
Copy link
Member

phkahler commented Mar 4, 2025

@rpavlik What do you think of this? I'm a huge anti-fan of templates, closures, and other "advanced" C++ features. It just seems overly complicated. This makes the code less maintainable by me, but I try to focus on other areas like geometry anyway. I like the part about sv becoming local ;-) What do you think of this change overall?

@ruevs
Copy link
Member

ruevs commented Mar 7, 2025

I'd also like to hear what @rpavlik thinks. of this.

In my opinion this is mostly syntactic sugar - makes the code longer and less readable.

Group::forceToMesh being saved as an int ('d') is strictly incorrect but is completely harmless.

@ruevs ruevs requested a review from rpavlik March 7, 2025 08:55
@iscgar
Copy link
Contributor Author

iscgar commented Mar 7, 2025

In my opinion this is mostly syntactic sugar - makes the code longer and less readable.

My motivation for doing it is mainly to avoid the copy needed during save, which with my work on reworking List<T> can become quite expensive on large models. In order to get rid of it, I had to find a way to specify member offsets which didn't rely on SS.sv, and as the comment in the code explains, I couldn't use offsetof() because it doesn't work with types that are not standard layout, so I had to resort to the lamdba boilerplate. The formatting helper functions were added only as a sugar indeed, but I left them in after they caught the issue with Group::forceToMesh as I think avoiding type safety issues is useful.

Group::forceToMesh being saved as an int ('d') is strictly incorrect but is completely harmless.

For now it is indeed harmless in practice, but if a member which has an alignment requirement that is less than int is added right after it in the future, debugging the overwrite would not be fun, so I think we should fix it (and the tests as a consequence) regardless of the enhancement that this PR is intended to bring.

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