size_t wrong mapping

[amerkoleci]

Hey,
Hope you're having good day!

I have issue on windows where the size_t maps to unsigned long long on windows, any idea why?

You can take look here at the code if you want:

https://github.com/amerkoleci/Vortice.Vulkan/tree/main/src/Generator

Thanks in advance,

Amer

[xoofx]

I have issue on windows where the size_t maps to unsigned long long on windows, any idea why?

It is usually that C++ headers will map such type to unsigned long long on 64-bit and probably unsigned long on 32-bit. They won't map it to e.g. intptr_t uintptr_t so you need to handle it in your code generator specifically (e.g. for example in CppAst.CodeGen here)

[amerkoleci]

I have issue on windows where the size_t maps to unsigned long long on windows, any idea why?

It is usually that C++ headers will map such type to unsigned long long on 64-bit and probably unsigned long on 32-bit. They won't map it to e.g. intptr_t uintptr_t so you need to handle it in your code generator specifically (e.g. for example in CppAst.CodeGen here)

Hey, thanks for answer, the issue happens after version 0.22.0, I don't ever get to perform the remapping (as statet by you), the typedef is already resolved when I have access to it, indeed I reverted my CppAst version to '0.22.0' and it works as expected.

Thanks again

[xoofx]

I reverted my CppAst version to '0.22.0' and it works as expected.

It is not really as expected. If you look at the C++ type, in most headers the typedef is not intptr_t, but is an actual type (e.g. unsigned long long). Long long types are a pain when you work cross platform, e.g. Windows vs Unix/Linux as they can lead to very different sizes, so that's why it was corrected to reflect it.

The current state of the library is correct, and the remapping has to be handled at a higher level.

[amerkoleci]

I see, the "problem" is that I didn't find point where I would be able to handle the remapping at high level and cannot know the difference between size_t (mapped as unsigned long long) and uint64_t (mapped as unsigned long long), any idea how to handle this scenario?

Thanks again