finally i realized that it does not take ownership of the memory you pass into it
finally i realized that
it does not take ownership of the memory you pass into it
it does not take ownership of the memory you pass into it
Athat was
Aa literal fucking revelation
Koof
Aeven still it was surprisingly stable using freed memory
which thinking about it
i find hilarious
which thinking about it
i find hilarious
Lits C, there is no real ownership model
Kunless youre using ogg
Ayeah, although most c libraries i've used tend to take a copy
Kin which case its nonsense
L"ownership" is just whether it makes a copy or not, which is not ideal for large data structures
Aeehhhhhhh
i wrote my rust audio library to take ownership of whatever you pass into it
but not like
the rust way of taking ownership
it copies whatever you pass into it
i wrote my rust audio library to take ownership of whatever you pass into it
but not like
the rust way of taking ownership
it copies whatever you pass into it
Aalthough its quite necessary for it to do that
Abecause it is intentionally designed so that it has full control over the data you pass into it, while still allowing you to retain control of your data
Lthen its not "taking ownership" then, its just making a copy of memory someone else is in control of
Lyou still have to free the memory you pass into it, its still owned by you
Lits just that theres now 2 copies of the same data, with different owners
Afair point
La better way of phrasing it in documentation is, "this function makes a copy of
paramName, you are able to deallocate paramName after this method exits"Atell that to the freetype people
they made it a tiny ass footnote
they made it a tiny ass footnote
Amy library uses the concept of buffers so its just assumed that it is entirely in control of its own memory
Athis design decision still haunts me to this day cause it can make certain things a royal pain
MReadOnlySpan<int> daysToMonth365 = [0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334, 365];okay, this shit is good
MDOES. NOT. ALLOCATE.
Kyup
MThe new UnsafeAccessor attribute (introduced in and supported by dotnet/runtime#86932, dotnet/runtime#88626, and dotnet/runtime#88925) lets you define an extern method that bypasses visibility. In this case, I’ve used it to get a ref to the private field, at which point I can just assign null through the ref.
Mwhat the fuck
Myou can't just hide this at the bottom
Kon little endian anyway, it allocates once globally to convert on other endianness
Mbig endian users can get fucked
Kits an implementation detail of the benchmarks lol so they didnt want to draw attention
Ktrue
Mif i can avoid writing expression emit code for field access, that makes things cleaner
Malso this avoids the overhead of a DynamicMethod not scoped to the same module
Mwhich is a stupid thing to care about but FastExpressionCompiler cares about it so
Kyeah i think they just want to try and not draw attention to it lmao
Kbut it is useful in some cases
M
Kdefining an extern method that does private field modification is extremely the sort of thing you dont advertise because its so absurd and unsafe lmao
MIT'S FUN
Koh i agree
Kim with you on this one lmao
Kits just objectively not the sort of thing thats not getting advertised prominently
Mi silly goofy with the obscure runtime errors
Klol
KUtf8.TryWrite is still by far my fav thing
Mbeing cursed aside, that library looks pretty cool. i should fork it
Mreminds me of protobuf
MCompositeFormat is such a pathetic optimization
Klmao
Mno way this shit was anyone's bottleneck
Mit turns an already pretty fast thing... slightly faster
