Skip to content

Rewrite to C++ #431

Description

@Sapd

Background

At first, HeadsetControl only supported one device and one feature. No device registry, no feature handling, etc.

That's why in the past, there couldn't be a distinction between C and C++ - it would have been the same code.

However, the project grew considerably: supporting multiple devices, multiple output types, and many features. At some point libusb was switched to libhidapi for better cross-platform support. However, there was never a switch from C to C++.

Why Consider C++ Now?

Pros:

  • Would save ~20% duplicate code (device init boilerplate, repeated error handling patterns)
  • Some parts are already object-oriented (device registry, vtable-like pattern with function pointers)
  • Development would be easier (inheritance, RAII, std::string vs manual malloc/free)
  • Access to more libraries if needed (e.g., JSON output, CLI parsing)
  • Modern C++ has features we currently work around (asprintf, string handling)

Cons:

  • Almost none - performance would be the same, C++ compilers are bundled with C compilers

Why Not Other Languages?

  • Binary needs to stay small and performant
  • HIDAPI would require wrappers
  • Modern C++ with the right tools can be just as productive

Options

  1. Full migration to C++ - rewrite everything
  2. Hybrid approach - keep C API, migrate device implementations to C++ classes
  3. Stay in C - refactor to reduce duplication with helper functions

Thoughts are welcome

Activity

  1. ChrisLauinger77 commented on Oct 31, 2025

    @ChrisLauinger77
    Contributor

    How do you feel about rust ? Modern, fast and gains more popularity every day.

  2. Sapd commented on Nov 1, 2025

    @Sapd
    OwnerAuthor

    Rust would be a much bigger rewrite with a completely different toolchain.

    On C++ we could also just rewrite for example the devices and keep the rest as is or rewrite later

  3. Joaaoc commented on Nov 19, 2025

    @Joaaoc
    Contributor

    I believe that hybrid approach is an excellent idea, it would have a more clean/organized code by migrating most implementations to C++, and would maintain universal compatibility by keeping the APIs in C.

    Also, it would be amazing if the project could be structured as a Core Library (DLL on Windows / .so on Linux / idk in Mac) that contains all the device logic, and a separate CLI Executable that simply links to this library.

    libheadsetcontrol -> a lib file exposing api (battery, lights, sidetone, etc...)
    headsetcontrol-cli -> single-shot executable (exactly how it works now)

    This would allow developers to link against libheadsetcontrol directly in their own UI applications. We could keep a single USB handle open and query the battery status instantly without the overhead of spawning processes or re-initializing the USB stack constantly (which causes a little overhead, noticeable mainly when playing competitive games).

  4. Sapd commented on Nov 20, 2025

    @Sapd
    OwnerAuthor

    Also, it would be amazing if the project could be structured as a Core Library (DLL on Windows / .so on Linux / idk in Mac) that contains all the device logic, and a separate CLI Executable that simply links to this library.

    Thank you for your feedback. Indeed that is an excellent idea which I did not consider yet. I fully agree that it makes sense and see how it can be implemented in the best way.

  5. floraaubry commented on Dec 4, 2025

    @floraaubry
    Contributor

    I fully agree with the idea of splitting it into a separate library!

  6. Sapd commented on Dec 14, 2025

    @Sapd
    OwnerAuthor

    See here: #443

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions