pagghiu

That's actually an excellent advice! :D

I love well written C libraries, like the sokol or stb libraries.

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...

Stack can be easily created with Vector (I can add it, thanks for the hint). I am conceptually against using Deque. If you need to keep stable addresses for objects you can use ArenaMap https://pagghiu.github.io/SaneCppLibraries/library_container...

There is a VectorSet that creates Set with an unsorted vector. I think it would be good (and easy) creating a SortedVectorSet for better performance.

HashMap and proper Map<K,V> are already on the roadmap https://pagghiu.github.io/SaneCppLibraries/library_container...

Stack can be easily created with Vector.

I think Queue is pretty specialized, but I will think about it.

Well that would be slightly increasing the project scope

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.

https://en.wikipedia.org/wiki/CMake#CMakeLists.txt

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".

The bloat free is more referring to executable size, build complexity, compile time and in general to hidden complexity.

Every library having its own version of common data structure is unfortunately something that C++ programmers can't really seem to agree on :)

That's a fair observation.

What containers, beside Vector<T> (and Map<K,V> made with Vector) + variants would you like to see the most?

Of course I would have been doing the same :)

The documentation here states:

https://pagghiu.github.io/SaneCppLibraries/library_reflectio...

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.

Yes, the Algorithms library is just a placeholder, as specified in the docs.

https://pagghiu.github.io/SaneCppLibraries/library_algorithm...

Hopefully it will get expanded with more useful algorithms, it has not been a priority in the first releases cycle.

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.

What macros are bothering you the most?

I honestly like well written C a lot :)

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 :)

You can definitively use C++ in exception free way. I've been working on multiple Exception free codebases for work.

One large open source project that is using Exception free C++ is SerenityOS for example https://github.com/SerenityOS/serenity

The best way to write proper exception free C++ is not to use the C++ Standard Library.

Exactly!

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.

https://github.com/Pagghiu/SaneCppLibraries/commit/9149e28

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.

You can do a Vector<TaggedUnion<Union>>. https://pagghiu.github.io/SaneCppLibraries/library_foundatio...

I have not been working (yet) on custom allocators, but that's on the roadmap: https://pagghiu.github.io/SaneCppLibraries/library_container...

Author here! Feel free to ask me any question, here or on discord/X/Mastodon I just saw this posted here, wow :)

I have never used wt so I may be wrong in the following considerations after reading a few of their features and examples.

By giving a quick read, I see that they also have asynchronous IO capability, and this makes it somewhat similar. Not sure about their build times, but knowing Boost I would not expect to be in the 5 seconds range. From what I understand they are tied to be used inside a browser, while we can generate regular desktop UI that also work in browser. I think that UI latency of our method is better than their system, but our approach requires far more computational resources and bandwidth. Their method probably scales better with many users connected.

Author here, feel free to ask questions