Header-only utilities for C++20* and up. Name inspired by stb (in part so I can have stb, stc, and std in some of my projects :) )

_{*: Subject to change in the future}

stc has documentation generated by doxygen. An online version is available on GitHub pages

Some of the modules in this library depend on other modules. These are explicitly labelled to make it easier to identify what dependencies are necessary for minimal builds.

Aside the modules in stc's core library, there are some standalone modules that aren't included by default.

• stc::testutil: includes several test utilities, either aimed at use with Catch2, or more general-purpose that works with anything.
  • This should not be included outside tests; I cannot stop you, but the APIs are designed for use in tests, not in production code, and at worst, have severe flaws that may even be intentional design, as test environments have fewer weird things that need to be accounted for.

Note that the key here can be used for linking, like target_link_libraries(tests PUBLIC stc::testutil)

For the most part, cross-platform support is attempted, as that's a large part of why this library exists; me being tired of dealing with cross-platform bullshit in downstream products. However, there are some exceptions to this.

Certain functions have been walled off from certain operating systems. In functions, this is not as clearly labelled as it should be. In classes, things that only support specific operating systems (or realistically, classes of operating systems, since UNIX is very broad but still has enough commonalities to mostly just work:tm:) are scoped by folder. stc/unix, for example, only contains UNIX-specific features.

The goal is to be as portable as possible, but not all features are going to work across all platforms nearly as easily. Process.hpp, at the time of writing, is over 410 lines of fairly involved UNIX API stuff. Trying to add Windows support into that would be far too difficult to attempt.

The general support priority is:

1. Linux/UNIX, broad UNIX support is incidental
2. Windows
3. Crapple, though crapple being in third place is misleading. It's far behind Windows, as I have no real interest in developing for an operating system with a 2000 EUR entry fee.

The main reason many of the cross-platform wrappers exist is because I'm a Linux main who occasionally wants Windows support, and can't be bothered reimplementing all the Windows-specific shit. That and, as much as I like the Linux/UNIX API, it has enough pitfalls that I don't want to work with it directly by default; wrapping it is still necessary, especially to make good use of RAII in certain cases.

That said, compatibility is mostly verified by tests. Certain things are disabled on certain platforms when not supporting it is intentional, but trying to get the buidl green everywhere is usually the main goal.

All you have to do is set up src/ as an include directory. Everything is header-only, and at the time of writing, requires no other setup.

CMake users can instead add_subdirectory() and take advantage of the stc interface target:

target_link_libraries(your-program stc)

FetchContent also works:

include(FetchContent)
FetchContent_Declare(stc
    GIT_REPOSITORY https://github.com/LunarWatcher/stc
    # Optional: pin stc version
    # GIT_TAG <hash>
)
FetchContent_MakeAvailable(stc)

# Same system as subdirectory
target_link_libraries(your-program stc)

The current version of C++ targeted is C++20. This is not a new change at the time of this commit, as a dumb mistake resulted in a C++20 function being part of the library and not being caught, because testing hard.