You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently our BSTR implementation uses SysAllocString, etc. methods from the Windows API. This is the de facto way to allocate/deallocate BSTRs on Windows.
For cross platform purposes we need an alternative way. One option would be to statically implement a IStringAllocator interface with a known GUID. This allows the COM client to acquire a IStringAllocator interface that provides FreeString(BSTR) method. This method can then allocate/deallocate the BSTR properly.
The only important consideration with the implementation is that the allocation and deallocation is done in a compatible way with each other. Thus if we allocate the BSTR from Rust heap, the deallocate must free the BSTR into Rust heap. If we use SysAllocString then the freeing must be done with SysFreeString.
Tasks:
Define the interface as intercom::IStringAllocator or similar trait. The implementation can be static intercom::StringAllocator as well. We might not even need the trait but instead just use the implicit impl instead.
Modify the #[com_library] code gen to include the StringAllocator in the ClassFactory constructor.
Implement string allocation with SysAllocString in Windows and something else (such as Rust heap/Box) on other platforms.
The text was updated successfully, but these errors were encountered:
I would like to have the ability to pass raw strings as well. Going through Bstr requires additional effort especially on Linux since the native character type is char. And when the machine's locale is set to UTF-8 we could omit all conversions and just verify that the string we receive from C++ is a valid UTF-8 string. This topic was discussed on IRC quite a bit already.
This is my current understanding and a summary of the earlier discussion:
We will generate two interfaces for traits.
The default version shall pass Strings and &str's as native character type by default.
The other, fast but unsafe, version shall pass strings as U8Str structs with the promise that they contain a valid UTF-8 string which we just cast directly into &str in Rust. This enables a fast and somewhat safe way for C++ applications to pass strings to Rust code.
The default character type for Strings and &strs will be the native character type of the platform. On Windows this will be "wchar_t" and on others it will be "char"
We will probably need an attribute which allows the developer specify the exact type.
The Bstr type will function identically on all platforms. We will need to implement it manually on non-Windows platforms.
Typedef of the BSTR must be char16_t on non-Windows platforms. The size of "wchar_t" may be 32-bits.
We have an allocator for BStrings and raw memory. Once we support U8Strings (or whatever we end up calling them) we can add that to the IAllocator interface.
Currently our
BSTR
implementation usesSysAllocString
, etc. methods from the Windows API. This is the de facto way to allocate/deallocate BSTRs on Windows.For cross platform purposes we need an alternative way. One option would be to statically implement a
IStringAllocator
interface with a known GUID. This allows the COM client to acquire aIStringAllocator
interface that providesFreeString(BSTR)
method. This method can then allocate/deallocate the BSTR properly.The only important consideration with the implementation is that the allocation and deallocation is done in a compatible way with each other. Thus if we allocate the BSTR from Rust heap, the deallocate must free the BSTR into Rust heap. If we use
SysAllocString
then the freeing must be done withSysFreeString
.Tasks:
intercom::IStringAllocator
or similar trait. The implementation can be staticintercom::StringAllocator
as well. We might not even need the trait but instead just use the implicitimpl
instead.#[com_library]
code gen to include theStringAllocator
in theClassFactory
constructor.SysAllocString
in Windows and something else (such as Rust heap/Box
) on other platforms.The text was updated successfully, but these errors were encountered: