Yes, I am trying to make C++ more pleasant than t currently is :)
I like Python and JS ecosystems a lot (but also Zig and well done C libraries) and I'm trying to learn a tiny bit by their success and bring it to C++, that is my favorite language)
No problem at all for your initial comment! I share similar sentiment, I've found a lot easier in the past glueing C libraries to do something more than trying to integrate a C++ library for the exact reasons you're describing...
I could bring multiple examples, but just to make one CMake, what I think today is the most popular way of describing builds in c++, describes builds in an imperative language.
Most "declarative" build systems are not actually what they "declare" to be.
I've seen too many DSLs introducing half backed imperative concepts here and there to do _if_ and _for_ constructs or function calls, redoing the same as imperative languages but poorly.
Of course Sane C++ Libraries targets a much much smaller functionality subset than Qt (that is a good library in many ways) and of course it has orders of magnitude less complexity.
You can use Sane C++ Libraries adding a single file to your project for example.
Also, Qt used to have an LGPL + Commercial licensing scheme (not sure how this has recently evolved), while this project just MIT.
I don't like to market it as an alternative to C++ stdlib, also because it doesn't cover all the things done by the C++ stdlib (in particular regarding Containers and Algorithms, as noted in other threads on this discussion).
I like to market it as an "alternative world" where the C++ stdlib is more a platform abstraction library focused on carrying practical tasks like networking, Async I/O, HTTP etc.
It's also definitively placing itself in the middle between unsafe C and bloated C++.
> No, instead of using std::exception, serenity has ErrorOr template. C’mon, that’s basically the same thing.
I think that handling errors with ErrorOr<T,E> or similar techniques (I use something similar too) is very different from exception handling.
My main problems with exception handling are:
1. It's not zero-overhead (brings in RTTI often)
2. You can't know if a function throws something by looking at its signature
3. You don't know what types exceptions a function can throw
4. It doesn't force users to handle errors that can happen, leading tomore "happy path" style code
Something like ErrorOr or similar with [[nodiscard]] ticks all the above 4 points.
Yes the library is trying to model an alternative C++ world where the standard library tries to be more like the standard libraries of other languages (Python, nodeJS for example) providing actual functionality out of the box rather than just "containers and algorithms".
Note
Reflection uses more complex C++ constructs compared to other libraries in this repository. To limit the issue, effort has been spent trying not to use obscure C++ meta-programming techniques. The library uses only template partial specialization and constexpr.
The majority of the macros are SC_PLATFORM_XXXX to inject platform specific code here and there.
There are macros in the Reflection library but you have the option not to use them.
And yes, complex stuff sometimes tries to handle "everyone's use case" but if you can limit yourself to 95% of use cases, your code suddenly become a lot simpler.
The backward compatibility consideration holds true as well.
For example, I have been creating an Async Library (plus a few other things like the FileSystemWatcher etc.) that cover a good portion of what is done in libuv.
Of course libuv code handles A TON more of edge cases and has a lot of compatibility constraints, but with a lot less code I can provide enough functionality to satisfy a lot of use cases.
Not all use cases, but a lot of use cases.
Thanks for the good luck!
I am definitively doing it just for fun :)
This is all in an effort to bring down compile times, avoiding including anything from the standard because you can never know if including <atomic> is bringing 10K lines of code in your header.
I will probably provide an optional USE_STANDARD_HEADERS flag someday to allow including a few standard things, including atomics, to avoid doing things wrong on compilerS that are not tested enough (as I clearly can't test every compiler).
For me personally SharedPtr is very rarely needed as it encourages building difficult to untangle ownership hierarchies. I did use a lot of Shared Ptr in the past when creating a node.js like library in C++ but breaking the ref cycles everywhere was needed has always been a pain.
That's why I am currently against its use, unless there is a very special case.
Regarding UniquePtr<T> I used to have one but I later on decided to remove it.
However, that being said the library is lean enough so that you can still use it with smart pointers provided by any other library (including the standard one) if that's your preference.
I love well written C libraries, like the sokol or stb libraries.