5 ms·

Wow. What industry is this?

nyanpasu64 5y ago
Not the parent, but miniaudio.h is a single C header containing both interface and (ifdef'd) implementation, which is 89k lines long. It horrifies me.
- titzer 5y ago
  Do you mean this [1]? [1] https://raw.githubusercontent.com/mackron/miniaudio/master/miniaudio.h https://raw.githubusercontent.com/mackron/miniaudio/master/m... Holy moley, yuck. It would truly suck to have a project that used that header in more than one file!
  - nyanpasu64 5y ago
    Yep, that. Many of the backends are ifdef'd away, but it's still a trainwreck to include an audio interface, mixer, and MP3/FLAC decoder implementation in a single header (you can disable the decoders but not the mixer).
  - junon 5y ago
    You wouldn't, hopefully. You'd create your own application-specific set of functions where the implemenation used this header and included it in exactly one translation unit.
    - titzer 5y ago
      Sounds like a real failure of API design, TBH.
      - junon 5y ago
        Not really, just a side effect of tons of code and lack of agreed upon specification cross-platform. I've worked with audio programming before and it's an absolute mess - namely Windows, which uses archaic and obtuse COM APIs.
      - nyanpasu64 5y ago
        I work in audio and (so far) primarily use audio libraries to output sound straight to the speakers, rather than having the library perform mixing for me. In this case, you generally write a callback to generate sound (which can be called by the audio library and outputting the results to speakers, or directly by unit tests and having the resulting audio analyzed in tests). This callback can often be entirely unaware of which audio library is being used (this may not be possible if your callback needs to react to latency and overruns), and you pass a function pointer and void* data to the audio library. The only real loss of only referencing audio-library-specific types in 1 translation unit is that the class you write to wrap audio-library-specific types must be located behind a pointer (either forward-declare class LibraryType and embed unique_ptr<AudioLibraryType>, or put AudioLibraryType or unique_ptr<AudioLibraryType> in a TU-local subclass of a public interface). Meanwhile Rust lacks the concept of translation units (instead each crate is a single rustc invocation which may sometimes be split into codegen units), and hides the presence/absence and location of compilation firewalls from the user. I don't actually know how to trigger or avoid cascading recompilations when using Rust's cpal audio library.
ameliaquining 5y ago
https://github.com/microsoft/TypeScript/blob/main/src/compiler/checker.ts https://github.com/microsoft/TypeScript/blob/main/src/compil...
maccard 5y ago
Video games. It's often in the "glue" components of the code that this happens in my experience.

Not the parent, but miniaudio.h is a single C header containing both interface and (ifdef'd) implementation, which is 89k lines long. It horrifies me.

titzer 5y ago
Do you mean this [1]? [1] https://raw.githubusercontent.com/mackron/miniaudio/master/miniaudio.h https://raw.githubusercontent.com/mackron/miniaudio/master/m... Holy moley, yuck. It would truly suck to have a project that used that header in more than one file!
- nyanpasu64 5y ago
  Yep, that. Many of the backends are ifdef'd away, but it's still a trainwreck to include an audio interface, mixer, and MP3/FLAC decoder implementation in a single header (you can disable the decoders but not the mixer).
- junon 5y ago
  You wouldn't, hopefully. You'd create your own application-specific set of functions where the implemenation used this header and included it in exactly one translation unit.
  - titzer 5y ago
    Sounds like a real failure of API design, TBH.
    - junon 5y ago
      Not really, just a side effect of tons of code and lack of agreed upon specification cross-platform. I've worked with audio programming before and it's an absolute mess - namely Windows, which uses archaic and obtuse COM APIs.
    - nyanpasu64 5y ago
      I work in audio and (so far) primarily use audio libraries to output sound straight to the speakers, rather than having the library perform mixing for me. In this case, you generally write a callback to generate sound (which can be called by the audio library and outputting the results to speakers, or directly by unit tests and having the resulting audio analyzed in tests). This callback can often be entirely unaware of which audio library is being used (this may not be possible if your callback needs to react to latency and overruns), and you pass a function pointer and void* data to the audio library. The only real loss of only referencing audio-library-specific types in 1 translation unit is that the class you write to wrap audio-library-specific types must be located behind a pointer (either forward-declare class LibraryType and embed unique_ptr<AudioLibraryType>, or put AudioLibraryType or unique_ptr<AudioLibraryType> in a TU-local subclass of a public interface). Meanwhile Rust lacks the concept of translation units (instead each crate is a single rustc invocation which may sometimes be split into codegen units), and hides the presence/absence and location of compilation firewalls from the user. I don't actually know how to trigger or avoid cascading recompilations when using Rust's cpal audio library.

ameliaquining 5y ago

https://github.com/microsoft/TypeScript/blob/main/src/compiler/checker.ts https://github.com/microsoft/TypeScript/blob/main/src/compil...

maccard 5y ago

Video games. It's often in the "glue" components of the code that this happens in my experience.