Replies: 2 comments 5 replies
-
Native interoperability best practices has up-to-date recommendations: plain string marked as Charset.Unicode for readonly string, char array for read & write. Other pages you linked are in .NET Framework section, which means they are sort of maintainence-only and might be not updated to latest best practices. They might use StringBuilder for read & write string buffers, because it used to be common practice. You could try submitting PR to update them if you care, but for starters it would be good to figure out whether it really makes difference on .NET Framework (i.e. StringBuilder is significantly slower then char[]). It could be that the difference only comes from recent optimizations in .NET Core. |
Beta Was this translation helpful? Give feedback.
-
I recommend closing this and moving the conversation to dotnet/docs#29542 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
The official docs are just bouncing around each other, for example you go here and it says for more information go here which then also says for more information go to [first link]. Both however say: Avoid using
StringBuilder
. But there is one example given which usesStringBuilder
🤷♂️I've reported to update the docs showing an example without StringBuilder, unfortunately it got "solved" by just updating the description but leaving the example untouched 🤷♂️
I've looked at the code in this repo but there are so many different versions all over the place. Some are using
StringBuilders
, others usestring
orValueStringBuilder
which is unfortunately not public.Can someone provide a correct and performant example of what we should use nowadays? For example on
GetModuleFileName
WinAPI which second parameter returns the filename asstring
.Beta Was this translation helpful? Give feedback.
All reactions