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

Redundent transmute in osmflat_generated #72

Open
hallahan opened this issue Oct 25, 2022 · 3 comments
Open

Redundent transmute in osmflat_generated #72

hallahan opened this issue Oct 25, 2022 · 3 comments

Comments

@hallahan
Copy link
Contributor

Often times there are accessors that transmute the same time into itself such as:

pub fn id(&self) -> i64 {
let value = flatdata_read_bytes!(i64, self.data.as_ptr(), 0, 40);
unsafe { std::mem::transmute::<i64, i64>(value) }
}

Is there any reason why this is being done, or is it something odd with the code generator? In this instance, the id is already an i64. Why transmute?

@VeaaC
Copy link
Collaborator

VeaaC commented Oct 25, 2022

This is due to the generator supporting to deserialize enumerations: Those need to be transmuted. The generator could theoretically skip the useless transmute by checking if target type matches source type, but the way it was implemented right now it just always transmutes, even if it is a no-op.

@hallahan
Copy link
Contributor Author

I wonder if there is any performance hit?

@VeaaC
Copy link
Collaborator

VeaaC commented Oct 26, 2022

Only in debug mode, release mode optimizes everything away. Similarly the flatdata_read_bytes macro is fully optimized to generate code similar to C++ bitfields.

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

2 participants