Replace as much std library functionality as possible

[Dawoodoz]

Because the std library is deprecating new features before you have time to try them, it will certainly not last for 200 years. Replacing std dependencies with compact and readable code will make projects using this library easier to port. A single complex feature in a standard library can be enough to prevent a project from being worth porting in the future. Multi-threading and timers in the C++ standard library can however not be replaced, because they interface with operating systems that have not been created yet. They might as well deprecate everything that's not a hardware abstraction and let custom libraries handle all high level functionality without the bad design decisions.

• dsr::List currently depends on std::vector because it was a convenient way to start, but more direct control over the allocation would allow making features that std::vector don't have.
• std::shared_ptr is used in most type handles for the API, but just making an alias could make a future replacement easier in case of standard library features being deprecated.

[Dawoodoz]

The min and max functions are now implemented in the dsr namespace at scalar.h. These use varargs recursively to allow taking minumum and maximum of more than two arguments.

[Dawoodoz]

std::shared_ptr has the annoying design flaw of not being able to create reference counted handles from the "this" pointer in member methods, making it incompatible with member methods for the GUI components. Inheriting from a reference counted base type without any virtual destructor would solve this.

[Dawoodoz]

If one can start by making aliases for everything in the std namespace, it will be possible to get rid of the std namespace now and upgrade the framework to a version less reliant on the std framework later. Should be noted in History.txt with instructions for how to make the switch from std to dsr using automatic text replacement, before future changes break backwards compatibility.

[Dawoodoz]

If compiling with the latest GCC compiler on Arch based Linux (where programs are up to date) and then running the program on Debian based Linux (years behind on updates), the dependency on a newer GLIBC may cause failure to run the program despite having the C standard library installed on the system. The cleanest solution would be to not use the C standard library at all, to reduce dependencies and increase reliability.

[Dawoodoz]

If using the Linux command "objdump -p ./TheApplication", one can see which system dependencies are in the application:

• libX11.so.6 (the window)
• libasound.so.2 (the sound)
• libstdc++.so.6 (C++ standard library)
• libm.so.6 (C math library, which can be replaced with C++)
• libgcc_s.so.1 (GCC runtime)
• libc.so.6 (C standard library, which can be replaced with C++)

This can probably be reduced to four system libraries if only using X11, Alsa, C++ standard library and GCC runtime.

[Dawoodoz]

The hardest part of removing dependencies on the C standard library seems to be that the STB Image library included as a header implementation is written in C. In the event of having to replace it in the future, it is however good if most parts don't depend on the C standard library.

[Dawoodoz]

It seems like it is not possible to get rid of the final dependencies using G++, because just writing an empty main function without including the framework will rely on the C library. If the C++ startup code depends on the C standard library despite not using the C language, one would have to write a system specific startup code, which would not be easily portable by future generations. One can go around this problem by making sure to compile for release on the most outdated of Linux distributions, such as Ubuntu or Mint, which should work fine on more up to date distributions such as Manjaro.

[Dawoodoz]

Replacing the std::vector backend for dsr::List would allow giving better error messages when someone requests too much memory, by getting direct access to the memory allocation returning null. Replacing std::vector would however require a lot of testing and all basic examples found online does not handle all the possible element types. Trivially copyable types need to use memcpy for speed, while objects need to use move operations and in-place construction and destruction to avoid calls to copy constructors during buffer reallocation. Alignment requirements from the type has to be handled correctly.

Would be nice if dsr::List could return a temporary dsr::SafePointer with optional alignment and padding for easy vectorization of the content.

[Dawoodoz]

With a custom allocation interface, one could allocate memory with a range of accepted element counts and return how many elements that were allocated, so that filling a slightly larger space for a list can insert more elements before it has to reallocate again.