just internally convert it to a pointer?
just internally convert it to a pointer?
Ktbh I'm not against having TerraFX style functions with raw ptr + the typed ptrs
Monly works one way
KI don't see why not + it provides compat with external libs that work with ptrs
A
VDeleted User#0000
I just submitted repro code for an issue regarding AggressiveInlining that doesn't even contain a single AggressiveInlining
Original Message
Quoted by kaijellinghaus#0000
Kmore inlining docs
Kbut what do we do for char**
Kconst char** to be specificKwe can't do T[][] that's just not correct
Mthat would be ref T[]?
Kand
T*[] helps with nothingKand
ROSpan<Span<T>> is just not validAno - and that will potentially require some allocation
but again, very easy for the user
and the performance hit that will be encountered is really not enough to matter
but again, very easy for the user
and the performance hit that will be encountered is really not enough to matter
Ai created a very fast alloc + buffer copy system in pie and you can't tell the difference between using that system and just sending the data over raw in tests
Pfor reference, these were the overloads in 1.9:
https://github.com/dotnet/Silk.NET/blob/v1.9.0/src/Vulkan/Silk.NET.Vulkan/Vk.gen.cs
https://github.com/dotnet/Silk.NET/blob/v1.9.0/src/OpenGL/Silk.NET.OpenGL/GL.gen.cs
https://github.com/dotnet/Silk.NET/blob/v1.9.0/src/Vulkan/Silk.NET.Vulkan/Vk.gen.cs
https://github.com/dotnet/Silk.NET/blob/v1.9.0/src/OpenGL/Silk.NET.OpenGL/GL.gen.cs
Athe thing is, with any safe context, you will always lose some performance to make it clean
if you wanted raw performance, don't use C#, simple as
if you wanted raw performance, don't use C#, simple as
Athe garbage collector gives far more of a performance hit than a little bit of allocation here and there
Ato make something safe, there is always some compromise
KIs C# the best language to do this? Maybe not. But there's very good reason you and everyone else here does it anyways....
And the GC hurting performance more then a little bit of allocation is just wrong. The whole reason the GC may hurt performance is because of those allocations
And the GC hurting performance more then a little bit of allocation is just wrong. The whole reason the GC may hurt performance is because of those allocations
KIt's well established that with performance and allocation minded code C# can be some of the fastest code around
Ksee ASP.NET Core
Mif what you want are very high level bindings can't cppsharp do that
Keeeeh
KI mean that's what TerraFX does, provide 100% unsafe raw methods
Apersonally the main reason I use C# is because I hate C++ headers and rust sucks for gamedev
that is literally the only reason
my opinion of C# as a language has gone way down the drain, I wish I did not have to use it
however that's not to say it doesn't have its merits, and clean and understandable code is one major benefit of the language, no need for unsafe, no need for weird types, just give something an array and it works
that is literally the only reason
my opinion of C# as a language has gone way down the drain, I wish I did not have to use it
however that's not to say it doesn't have its merits, and clean and understandable code is one major benefit of the language, no need for unsafe, no need for weird types, just give something an array and it works
Mi meant the opposite, 100% safe methods
KNo
Kno one can do 100% safe methods
M90% safe
Mno pointers
Ksure, but we have been able to do that for a long time
Kthe problem is more what to do in those edge cases
Mso what is silk adding to the table if we go back to working on that principle
Kwhat if some things are a ptr and some things are a safe array
KIdeally you can use a
int*[] no problemKI get this a lot, but then I'm not sure what your problem with the idea of wrapped pointers are?
Kno need for unsafe, no need for weird types, just give something an array and it worksis exactly what we try to enable here
VDeleted User#0000
we can't abolish any of those parameters, and can't really choose which ones are the right ones
Original Message
Quoted by perksey#0000
Pthis is really what it boils down to
Kyeah, and in cases like
f(int***, void**, uint**, res*, float**) it's just ???Klike which ones are the right overloads to have here
Ai don't see why it's something that couldn't be returned to, just because it was in 1.0?
i'm not dismissing this
now having documentation is fine, but personally if I were coming from say C++ opengl, I should not have to read documentation to be able to use it in C#, I should just be able to give it an array of data like normal and it just works
the intellisense says it is an array, I can see that it is an array, I give it array data, and it just works, no questions or errors or warnings asked by the compiler
sure there's faster options available, but it just works
for me, that is the advantage of C#
stuff just works, the intellisense makes it obvious what it does, no need to mess around reading documentation, you just give stuff data and off it goes.. then it doesn't work because you gave it the wrong offset but we don't talk about that
i'm not dismissing this
Ptr<T> idea of course, i am just trying to suggest stuff from a user's perspective. i love C#'s unsafe, but I don't think it should be the norm for the end user, and I don't think that a custom type is the right way to do things - simply because to an end user, it is a type they may have never seen before, and may be confusing to use, to the point where one may have to read documentation to find out how to use itnow having documentation is fine, but personally if I were coming from say C++ opengl, I should not have to read documentation to be able to use it in C#, I should just be able to give it an array of data like normal and it just works
the intellisense says it is an array, I can see that it is an array, I give it array data, and it just works, no questions or errors or warnings asked by the compiler
sure there's faster options available, but it just works
for me, that is the advantage of C#
stuff just works, the intellisense makes it obvious what it does, no need to mess around reading documentation, you just give stuff data and off it goes.. then it doesn't work because you gave it the wrong offset but we don't talk about that
Kyeah this is great that we talk about this tbh
Kso the concern that we have had a few times when talking about this is that for functions like the one I gave above, it's really unclear to us which overloads to expose
Poh yeah sure, but all i'm saying there's a reason we moved away from the rigid 1.0 structure primarily because we got complaints about the overloads kinda being naff to use
Kand exposing all of them is problematic because then you get no intellisense and maybe your IDE just dies
Kwhich... yeah that's super bad
Pfor sure, this is also why we refused to include overloads in the original 3.0 proposals haha
Kf(int***, void**, uint**, res*, float**)here there is a very good argument that we should support passing
T[] in place of T* everywhere, I think everyone agrees?f(int**[], void*[], uint*[], res[], float*[]) should be a valid way to pass the argsMimplicit casts to ptr might genuinely be a good alternative to having every permutation of argument as an overload
