4 ms·

I think the parent means native implementations so that these bindings are not necessary. The bindings are an interface to a C library that should be shipped wi

I think the parent means native implementations so that these bindings are not necessary. The bindings are an interface to a C library that should be shipped with the device. I can see how that can be problematic if you're targeting OS X, Windows, and Unix systems

masklinn 9y ago
The OP is saying problems exist before even deployment concerns: > even if it actually starts working nobody really knows how to deploy such an app on another computer (especially if it runs a different kind of OS) correctly. emphasis mine. (and portability could obviously be solved the same way it was in Python: ship sqlite as part of the core system)
marcosdumay 9y ago
> The bindings are an interface to a C library that should be shipped with the device. There is nothing stopping you from statically linking it with the rest of your code.
- weberc2 9y ago
  Not all languages are compiled.
  - paulddraper 9y ago
    If your language has no possibility of ffi, that's kinda an issue on that language. Good luck using portable libraries.
    - weberc2 9y ago
      Maybe you could help me understand why static linking is a requisite of FFI?
      - paulddraper 9y ago
        Oh, d--n it, misread. Never mind.
        weberc2 9y ago
        No problem; it happens!
- juliangoldsmith 9y ago
  How exactly would you link a C library to a .NET application? Apart from compiling it using something like ilcc, that is.
  - WorldMaker 9y ago
    .NET has always had a foreign function interface (FFI) system called P/Invoke [1] or Platform Invoke. You build a DLL and ask the .NET runtime through metadata to load that DLL for you and call the functions you need. It's not entirely cross-platform, but it is possible. Example: https://developers.redhat.com/blog/2016/09/14/pinvoke-in-net-core-rhel/ https://developers.redhat.com/blog/2016/09/14/pinvoke-in-net... More details in the .NET Standard: https://docs.microsoft.com/en-us/dotnet/standard/native-interop https://docs.microsoft.com/en-us/dotnet/standard/native-inte... [1] One interesting reference site: https://www.pinvoke.net/ https://www.pinvoke.net/
    - juliangoldsmith 9y ago
      I'm aware of P/Invoke. I'm pretty sure that's how the ADO.NET wrapper to SQLite works. GP was referring to statically linking a native binary to a .NET application, and as far as I know, there's no way to do that.
      - WorldMaker 9y ago
        I was curious. One approach is apparently to include it as a binary resource, extract it to temporary space at runtime, then P/Invoke: https://stackoverflow.com/a/768429 https://stackoverflow.com/a/768429 That seems a bit much to simulate static linking, but doesn't sound like it would be too noticeable to users.
        juliangoldsmith 9y ago
        That's an interesting technique, and would certainly work. You could probably even make it cross-platform that way.
    - 9y ago
nightcracker 9y ago
The value of SQLite lies in its implementation, and a native implementation would be immensely costly.

masklinn 9y ago

The OP is saying problems exist before even deployment concerns: > even if it actually starts working nobody really knows how to deploy such an app on another computer (especially if it runs a different kind of OS) correctly. emphasis mine. (and portability could obviously be solved the same way it was in Python: ship sqlite as part of the core system)

marcosdumay 9y ago

> The bindings are an interface to a C library that should be shipped with the device. There is nothing stopping you from statically linking it with the rest of your code.

weberc2 9y ago
Not all languages are compiled.
- paulddraper 9y ago
  If your language has no possibility of ffi, that's kinda an issue on that language. Good luck using portable libraries.
  - weberc2 9y ago
    Maybe you could help me understand why static linking is a requisite of FFI?
    - paulddraper 9y ago
      Oh, d--n it, misread. Never mind.
      - weberc2 9y ago
        No problem; it happens!
juliangoldsmith 9y ago
How exactly would you link a C library to a .NET application? Apart from compiling it using something like ilcc, that is.
- WorldMaker 9y ago
  .NET has always had a foreign function interface (FFI) system called P/Invoke [1] or Platform Invoke. You build a DLL and ask the .NET runtime through metadata to load that DLL for you and call the functions you need. It's not entirely cross-platform, but it is possible. Example: https://developers.redhat.com/blog/2016/09/14/pinvoke-in-net-core-rhel/ https://developers.redhat.com/blog/2016/09/14/pinvoke-in-net... More details in the .NET Standard: https://docs.microsoft.com/en-us/dotnet/standard/native-interop https://docs.microsoft.com/en-us/dotnet/standard/native-inte... [1] One interesting reference site: https://www.pinvoke.net/ https://www.pinvoke.net/
  - juliangoldsmith 9y ago
    I'm aware of P/Invoke. I'm pretty sure that's how the ADO.NET wrapper to SQLite works. GP was referring to statically linking a native binary to a .NET application, and as far as I know, there's no way to do that.
    - WorldMaker 9y ago
      I was curious. One approach is apparently to include it as a binary resource, extract it to temporary space at runtime, then P/Invoke: https://stackoverflow.com/a/768429 https://stackoverflow.com/a/768429 That seems a bit much to simulate static linking, but doesn't sound like it would be too noticeable to users.
      - juliangoldsmith 9y ago
        That's an interesting technique, and would certainly work. You could probably even make it cross-platform that way.
  - 9y ago

nightcracker 9y ago

The value of SQLite lies in its implementation, and a native implementation would be immensely costly.