4 ms·

I don't have this luxury if I want to learn about ffmpeg libraries, its all written in c, almost all media and hardware accelerator libraries are written in c,

I don't have this luxury if I want to learn about ffmpeg libraries, its all written in c, almost all media and hardware accelerator libraries are written in c, you go to another language they just bind to c. its soo frustrating but I've no choice but to stick with c.

ammar2 4y ago
huh? What's wrong with using the higher level languages if they take care of binding to the C parts for you. (I know these are far an in-between for ffmpeg, too many leaky abstractions.)
- flohofwoe 4y ago
  Usually increased build system complexity, outdated manually maintained bindings, etc etc... - in some languages (like Zig) this is really trivial, in other languages it can be much harder.
- jalino23 4y ago
  try to find ffmpeg in go or rust that is < 5 years old and complete. how about intel libva,
jpollock 4y ago
Most languages have the ability to call C functions. Use the language that helps you write your code and convert to call the third party API. For example, a C++ Vector provides a generic container and the code can still call C functions with the underlying array. This is in the "Doctor it hurts if I do X" bucket. https://stackoverflow.com/questions/2923272/how-to-convert-vector-to-array https://stackoverflow.com/questions/2923272/how-to-convert-v...
- flohofwoe 4y ago
  Mixing high level C++ stdlib classes with low level C APIs is often not exactly trivial, for instance most C++ containers expect that their items are RAII compatibel, and the resulting memory corruption errors will be harder to debug than plain old C code because the shit hits the fan deep inside some completely unreadable C++ stdlib implementation code.
- cozzyd 4y ago
  Yes, but if you're writing code that you want to be bindable to other languages, you essentially have to follow the C ABI, in which case, writing in C is a natural choice (yes, you can expose a C ABI from other languages, but that's usually not natural and you sort of have to understand C anyway to do that).
  - int_19h 4y ago
    Unless your API surface constitutes the majority of your code, writing in C still doesn't make sense, because you're paying the tax every time you have to manually juggle strings and whatnot. C++ is a more sensible choice for this - you can still write C-compatible headers (and it's trivial to verify in builds - just include it in a .c file and see if that compiles!) while using STL etc in the implementation.
    - cozzyd 4y ago
      Yeah if you're using opaque handles (where what you have is really a pointer to some C++ thing), this can work well. If you're exposing structs that are passed back and forth for state, it's a bit more cumbersome.
WalterBright 4y ago
D code can call C functions directly.

ammar2 4y ago

huh? What's wrong with using the higher level languages if they take care of binding to the C parts for you. (I know these are far an in-between for ffmpeg, too many leaky abstractions.)

flohofwoe 4y ago
Usually increased build system complexity, outdated manually maintained bindings, etc etc... - in some languages (like Zig) this is really trivial, in other languages it can be much harder.
jalino23 4y ago
try to find ffmpeg in go or rust that is < 5 years old and complete. how about intel libva,

jpollock 4y ago

Most languages have the ability to call C functions. Use the language that helps you write your code and convert to call the third party API. For example, a C++ Vector provides a generic container and the code can still call C functions with the underlying array. This is in the "Doctor it hurts if I do X" bucket. https://stackoverflow.com/questions/2923272/how-to-convert-vector-to-array https://stackoverflow.com/questions/2923272/how-to-convert-v...

flohofwoe 4y ago
Mixing high level C++ stdlib classes with low level C APIs is often not exactly trivial, for instance most C++ containers expect that their items are RAII compatibel, and the resulting memory corruption errors will be harder to debug than plain old C code because the shit hits the fan deep inside some completely unreadable C++ stdlib implementation code.
cozzyd 4y ago
Yes, but if you're writing code that you want to be bindable to other languages, you essentially have to follow the C ABI, in which case, writing in C is a natural choice (yes, you can expose a C ABI from other languages, but that's usually not natural and you sort of have to understand C anyway to do that).
- int_19h 4y ago
  Unless your API surface constitutes the majority of your code, writing in C still doesn't make sense, because you're paying the tax every time you have to manually juggle strings and whatnot. C++ is a more sensible choice for this - you can still write C-compatible headers (and it's trivial to verify in builds - just include it in a .c file and see if that compiles!) while using STL etc in the implementation.
  - cozzyd 4y ago
    Yeah if you're using opaque handles (where what you have is really a pointer to some C++ thing), this can work well. If you're exposing structs that are passed back and forth for state, it's a bit more cumbersome.

WalterBright 4y ago

D code can call C functions directly.