2.x wont have breaking changes https://github.com/dotnet/Silk.NET/issues/887 so pop a report here an

2.x wont have breaking changes
https://github.com/dotnet/Silk.NET/issues/887
so pop a report here and we'll fix it in 3.0

GitHub

Tracking Issue for Bindings Generation & Improvements · Issue #887 ...

TODO We truly invite everyone to send us reports of any place where our bindings are not ideal. This issue will serve as a list of things we should fix in 3.0.

Eagle•5/23/22, 12:53 AM

Not sure if this is fixable by conventional means (if anything). A char pointer in itself can represent many things because it can be combined with an indexer (

[<index>]

[<index>]

) or even C strings on top of being a reference to a single 8 bits value (there's no byte type in C). Even an array of char, which narrows it down some, can be used to represent either strings or binary data in C. Semantic intent is probably gonna be difficult to guess from just the type/signature. C strings also don't hold anything special in memory to tell that we're dealing with a string aside from the null-terminating character (

\0

\0

or 0 as an integer value).

Lyris the KitoriOP•5/23/22, 12:54 AM

most of our other bindings have extra data we use to determine type but i guess we didnt have that here, so its not really fixable unless we make that data ourself, find some copy of it, or manually fix all the broken parts

Eagle•5/23/22, 12:54 AM

If you assume all of them are strings, it might be weird to see a binding method need a string when a stream of bytes is needed.

Eagle•5/23/22, 12:54 AM

Yeah, it has to be marked manually somehow.

Lyris the KitoriOP•5/23/22, 12:55 AM

and either way, 2.x isnt getting breaking changes, so it likely wont be fixed in any way till 3.0

Eagle•5/23/22, 12:55 AM

Right. Was just saying in general. I wasn't sure if marking/manual fixes were options for Silk as a whole, and from what I know of C, there's not enough clues to tell what this type of data can hold just from parsing code.

LLyris the Kitori 2.x wont have breaking changes https://github.com/dotnet/Silk.NET/issues/887 so ...

Lyris the KitoriOP•5/23/22, 12:55 AM

best way to make sure it gets fixed in 3.0 is making a response here

EEagle Not sure if this is fixable by conventional means (if anything). A char pointer ...

Opcode_•5/23/22, 2:37 AM

I'm a little surprised at the prevalence of char* or even char[] in any modern code. Since its basically just "a place in memory" it seems inherently unsafe

Lyris the KitoriOP•5/23/22, 2:37 AM

welcome to C

Lyris the KitoriOP•5/23/22, 2:37 AM

its the

Lyris the KitoriOP•5/23/22, 2:37 AM

only

Lyris the KitoriOP•5/23/22, 2:37 AM

option

Lyris the KitoriOP•5/23/22, 2:37 AM

that is portable

Opcode_•5/23/22, 2:38 AM

must OpenXR be implemented in strictly C? Not C++?

Lyris the KitoriOP•5/23/22, 2:38 AM

we cant bind to C++

Lyris the KitoriOP•5/23/22, 2:38 AM

we can only bind to C

Opcode_•5/23/22, 2:38 AM

Oh?

Lyris the KitoriOP•5/23/22, 2:38 AM

we cant call C++ functions from C#

Lyris the KitoriOP•5/23/22, 2:39 AM

theres no standardized convention for doing so

LLyris the Kitori theres no standardized convention for doing so

Opcode_•5/23/22, 2:41 AM

Really? So a .dll written in C++ that you might want to somewhere outside of C++ is just a no-go? It becomes a C library?

Lyris the KitoriOP•5/23/22, 2:41 AM

you have to bind to it from C, then bind to the C

Lyris the KitoriOP•5/23/22, 2:42 AM

its how ImGui.NET works at all

Lyris the KitoriOP•5/23/22, 2:42 AM

given ImGui is C++

Redhacker2•5/23/22, 3:47 AM

Yeah

Redhacker2•5/23/22, 3:47 AM

There is no standard C++ ABI, Each compiler does it differently

Redhacker2•5/23/22, 3:47 AM

C is much easier in that regard

Lyris the KitoriOP•5/23/22, 3:48 AM

you can pretty much assume a standard ABI with C

Redhacker2•5/23/22, 3:48 AM

Silk.net 3.0 is poised to hopefully change this though

Redhacker2•5/23/22, 3:48 AM

With clangsharp being the basis of silktouch

Lyris the KitoriOP•5/23/22, 3:48 AM

im guessing we are going to precompile everything with a single compiler so we can be sure

Kai•5/23/22, 5:23 AM

yep, clang will handle all the things for us

Kai•5/23/22, 5:24 AM

also pointing out that the Vulkan / OpenXR and in general the khronos specs are all largely C oriented. They have C++ headers which might have better information in terms of "this should be a string" but the spec doesn't actually say that

OOpcode_I'm a little surprised at the prevalence of char* or even char[] in any modern c...

Eagle•5/23/22, 12:55 PM

If we're talking about C, it doesn't have anything else natively. To my knowledge, the only concept of immutability there is probably constants. The language was developed in the 70s and despite its abstractions from machine language, it's still relatively close to the low level concepts, even to the point where its strong typing nature can be ignored entirely.

The language also has such a long history in programming it can hardly change from what it is, or then you get a mess like C++.

C++ is also a reason C doesn't get much feature updates, I guess.
C is also still used for embedded applications on low-power devices (microcontrollers etc...). It's a neat small and robust language for small applications, and because of its past popularity, it's supported pretty much everywhere.
In C# though, I do agree that there should be no need for pointers in any program. References are their managed equivalent, and coming from a guy that's learned programming from the id Tech 3/Quake III Arena engine (using ANSI C and some x86 assembly), it's worked just fine for me so far. The only reason they are supported is probably interop, and they're technically even more limited than they are in C/C++, if I'm not mistaken. The only probable downside of not using pointers may be performance on immutable types (strings, delegates), since it requires reallocation and garbage collection, but the standard library (.NET) likely provides something to help with that.

StringBuilder

StringBuilder

and the more recent

Span<>

Span<>

are examples of that.

Kai•5/23/22, 12:58 PM

Yeah where zero cost abstractions (or very very close to zero cost, think span) are possible we want them for sure. For non-zero cost abstractions we're looking to find a good way to expose the native / zero cost + managed values in a way that is ergonomic but keeps the zero costness

Ҡєʀ๓aℓıѕ•5/23/22, 8:56 PM

Unrelated to silk but I posted in another discord and got no response:

am I stupid or is Half not working? I'm using Half.MinValue and it returns -65500 instead of -65504 like expected. I can't add 0.5 either to -65500. I know there's lower accuracy but I feel like the value doesn't move at all. Doing -65500 + 25 gives me -65470

Ҡєʀ๓aℓıѕ•5/23/22, 8:56 PM

https://cdn.discordapp.com/attachments/169726586931773440/978399593408639046/unknown.png