3 ms·

Another point for this, besides optimization, is easier interop with existing technologies. The memory layout is identical to Windows' BSTR, as far as I know, a

by ygra 10y ago

Another point for this, besides optimization, is easier interop with existing technologies. The memory layout is identical to Windows' BSTR, as far as I know, and also includes a terminating U+0000. All of that makes it possible to marshal a CLR string as is in many circumstances without the need to copy or convert the characters around.

MarkSweep 10y ago
There is an amusing comment in the CLR about it's support for odd length BSTRs[0]. There can be an extra wchar after the null terminator to store the extra byte. It looks like if you use the automatic BSTR marshaler it creates a copy[1], though the CLR is so big it's hard for me to say that with confidence. Taking the address of a string with the fixed statement in C# of course won't allocate and that pointer can be passed to APIs that expected Unicode strings. [0]: https://github.com/dotnet/coreclr/blob/a123c3972c447c8bcfa1810fde0c7ffb842fa31b/src/vm/object.cpp#L1853-L1869 https://github.com/dotnet/coreclr/blob/a123c3972c447c8bcfa18... [1]: https://github.com/dotnet/coreclr/blob/a123c3972c447c8bcfa1810fde0c7ffb842fa31b/src/vm/olevariant.cpp#L5250-L5275 https://github.com/dotnet/coreclr/blob/a123c3972c447c8bcfa18...
- matthewwarren 10y ago
  I love comments like that, it's almost a history lesson on VB and the CLR!
  - adzm 10y ago
    Then you'd probably love to know why the OLE DATE epoch is 1899-12-30... also the B in BSTR is for Basic! https://blogs.msdn.microsoft.com/ericlippert/2003/09/16/erics-complete-guide-to-vt_date/ https://blogs.msdn.microsoft.com/ericlippert/2003/09/16/eric...
- asveikau 10y ago
  I would think, especially for out parameters and return values, you would need to copy to interop with BSTRs because they are supposed to live on the COM heap (SysAllocString) and CLR wouldn't use that by default.
matthewwarren 10y ago
Yeah that's a good point, I completely steered clear from talking about marshalling and/or interop (mostly due to lack of time), maybe I'll do a Part 2 and include that.

by ygra 10y ago

MarkSweep 10y ago

There is an amusing comment in the CLR about it's support for odd length BSTRs[0]. There can be an extra wchar after the null terminator to store the extra byte. It looks like if you use the automatic BSTR marshaler it creates a copy[1], though the CLR is so big it's hard for me to say that with confidence. Taking the address of a string with the fixed statement in C# of course won't allocate and that pointer can be passed to APIs that expected Unicode strings. [0]: https://github.com/dotnet/coreclr/blob/a123c3972c447c8bcfa1810fde0c7ffb842fa31b/src/vm/object.cpp#L1853-L1869 https://github.com/dotnet/coreclr/blob/a123c3972c447c8bcfa18... [1]: https://github.com/dotnet/coreclr/blob/a123c3972c447c8bcfa1810fde0c7ffb842fa31b/src/vm/olevariant.cpp#L5250-L5275 https://github.com/dotnet/coreclr/blob/a123c3972c447c8bcfa18...

matthewwarren 10y ago
I love comments like that, it's almost a history lesson on VB and the CLR!
- adzm 10y ago
  Then you'd probably love to know why the OLE DATE epoch is 1899-12-30... also the B in BSTR is for Basic! https://blogs.msdn.microsoft.com/ericlippert/2003/09/16/erics-complete-guide-to-vt_date/ https://blogs.msdn.microsoft.com/ericlippert/2003/09/16/eric...
asveikau 10y ago
I would think, especially for out parameters and return values, you would need to copy to interop with BSTRs because they are supposed to live on the COM heap (SysAllocString) and CLR wouldn't use that by default.

matthewwarren 10y ago

Yeah that's a good point, I completely steered clear from talking about marshalling and/or interop (mostly due to lack of time), maybe I'll do a Part 2 and include that.