25 ms·
Sane C++ Libraries
- shortrounddev2 3y agoThe lack of STL containers or even a fully implemented set of custom containers, to me, makes this kind of a non starter. I use C++, in part, because I don't want to have to implement Data structures and algorithms myself
- pagghiu 3y agoThat's a fair observation. What containers, beside Vector<T> (and Map<K,V> made with Vector) + variants would you like to see the most?
- shortrounddev2 3y agoSet, Stack, Queue, and their various implementations (HashSet, PriorityQueue, etc)
- pagghiu 3y agoThere 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_containers.html#autotoc_md90 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.
- smallstepforman 3y agoMy projects use stack and deque often.
- pagghiu 3y agoStack 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_containers.html#autotoc_md87 https://pagghiu.github.io/SaneCppLibraries/library_container...
- Profan 3y agoIt's still funny to me how something titled "Sane C++ libraries" has zero interop with the STL; guaranteeing an even more fragmented C++ ecosystem. C++ has its place, but something new could not possibly displace it soon enough, even with C it feels like libraries fit together more easily.
- chornos 3y agoIts the very reason C++ is still alive. Its unopinionated on how u code and coding enviroment. Plenty of other language are far more restricted in their ecosystem
- Profan 3y agoI just think things could be a little more aligned as I use C++ daily and often end up interacting with many different libraries and each has their own slightly idiosynchratic String/Vector/etc type, which quickly makes life.. interesting But I see the point in it helping C++'s unusual longevity as well
- pagghiu 3y agoYes 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".
- Profan 3y agoHuh right I see, I do like the idea of that and I wish that is what the actual C++ stdlib was more like, it would make my life of using C++ a lot more pleasant than it currently is :) (also sorry my initial comment came off like ragging on your library, it wasn't meant that way, it was more of a commentary on the overall state of the C++ ecosystem, so I appreciate people with a slightly broader view like yours!)
- pagghiu 3y ago
- sublinear 3y agohttps://github.com/nlohmann/json https://github.com/nlohmann/json I used this for JSON last time I wrote any C++ a few years ago and it still seems popular. It seemed sane enough to me.
- nly 3y agoBoost.JSON is arguably the better choice these days. It's roughly as usable as nlohmann but faster than RapidJSON Overview: https://www.boost.org/doc/libs/1_84_0/libs/json/doc/html/json/quick_look.html https://www.boost.org/doc/libs/1_84_0/libs/json/doc/html/jso... Benchmarks: https://www.boost.org/doc/libs/1_84_0/libs/json/doc/html/json/benchmarks.html https://www.boost.org/doc/libs/1_84_0/libs/json/doc/html/jso... Parsing Options for non-standard JSON: https://www.boost.org/doc/libs/1_84_0/libs/json/doc/html/json/ref/boost__json__parse_options.html https://www.boost.org/doc/libs/1_84_0/libs/json/doc/html/jso...
- gumby 3y agoLooks like the author likes C but would like a few of the features of C++ and wants to have some fun. There’s noting wrong with that, but it ain’t for me. The stuff he considers complex is mostly complex because it handles a lot of corner cases, or else it has back compatibility constraints he will be dealing with as well. Good luck to him though. Doing stuff for fun is the best!
- pagghiu 3y agoI 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 :)
- colejohnson66 3y agoAs someone who doesn't write C++, why does almost everyone seem to insist on ignoring the STL and writing everything themselves? Both C++ and C# take a "bags included" approach to the standard library, but no one is writing their own `List<T>` for C#.[a] Yet, everyone seems to have their own opinion about `std::vector<T>`. [a]: Obviously, people still write their own collections/containers in C#, but they tend to only do so for very specific/performance-sensitive circumstances.
- deleted 3y ago[deleted]
- blovescoffee 3y agoBecause people tend to write c++ for performance reasons and the perf profiles of std::vector are not always sufficient
- jeffbee 3y agoThe only thing you can really quibble about with std::vector is whether your library has made an optimal choice of growth strategy, which you can often hack around by reserving. Aside from that, access via `operator[]` and growth via `emplace_back` will compile down to optimal code that is going to be close to impossible to beat. After the compiler gets done with it, it looks the same as if you had hand-coded it with arrays in a C-style, but without the plethora of bugs that often results from that approach.
- jsheard 3y agoThere's also the issue that std::vector<bool> is required by the standard to be specialized as a bitset, which is a footgun in generic code since you can normally take the address of a vector element but not if it's a vector of bool. Having a bitset in the standard library is fine but it should have been a seperate type. Admittedly that's not a performance issue, but it's annoying.
- 3y ago
- comex 3y agoMany of the principles here align with my tastes, such as focusing on fast compile times and supporting allocation failure. On the other hand: > Unplanned Features: > SharedPtr > UniquePtr > In Principles there is a rule that discourages allocations of large number of tiny objects and also creating systems with unclear or shared memory ownership. For this reason this library is missing Smart Pointers. I don’t like that at all. I take the common view that all heap objects should at least be allocated via smart pointers. Doing so is safer and easier and usually zero-overhead. After allocation, it may be necessary to pass those objects via raw pointers/references, but smart pointers should be used where appropriate. So while I agree that it’s undesirable to allocate “large numbers of tiny objects”, I would want smart pointers as long as there’s any dynamic allocation at all.
- markisus 3y agoI usually like to place all dynamically heap objects of type T into an std::vector<T>, if possible. There is sometimes an obvious point where the entire batch should be discarded and a new batch should be built. At this point, you can call vector.clear() which avoids deallocation/allocation cost for the new batch, as long as it is not bigger than the old batch. This is a sort of quick and dirty arena allocation. This style is also more cache friendly if you are going to be looping through the elements.
- neeeeees 3y agoInteresting - is there a type safe way to do this? vector<variant<>>? and/or a custom “vector allocator” to hide the details?
- CyberDildonics 3y agoWhy would you need a variant? If you have one of something, put it on the stack. If you have a lot of the a type, put them in a vector.
- emi2k01 3y agoIsn't that an arena allocator at that point?
- arccy 3y agohow does it compare to https://abseil.io/ https://abseil.io/
- jsheard 3y agoAbseil is more of a complement to the STL rather than a complete replacement like the OP is, for example the only containers that Abseil provides are maps and sets since the STL ones are particularly bad, and the rest of the STL containers are good enough (for Google at least). Whether that's the right approach depends on what your specific qualms with the STL are.
- j16sdiz 3y agoThe first library I checked was "Reflection". This is where I can see if their principle holds up
- pagghiu 3y agoOf course I would have been doing the same :) The documentation here states: https://pagghiu.github.io/SaneCppLibraries/library_reflection.html 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.
- dzogchen 3y ago'Sane' C++ is apparently still using macros all over the place. :) Not really to be taken seriously.
- pagghiu 3y agoThe 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?
- bsdpufferfish 3y agoJust use C and guarantee your sanity. The whole reason to adopt C++ is to support huge projects and libraries all of which are going to use the “bad” stuff.
- pagghiu 3y agoThat's actually an excellent advice! :D I love well written C libraries, like the sokol or stb libraries.
- nemetroid 3y agoLooked at the first library in the list, "Algorithms". The first item in that library is bubbleSort(). I'll pass.
- pagghiu 3y agoYes, the Algorithms library is just a placeholder, as specified in the docs. https://pagghiu.github.io/SaneCppLibraries/library_algorithms.html#autotoc_md52 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.
- csjh 3y agoWhat is the point of `algorithms::bubbleSort`?
- greysphere 3y agoLast I checked bubble sort was the fastest sort for small counts of small objects. That was 10 years ago though so thing might have changed potentially something that might take better advantage of vector ops. It's also often the correct choice for something like a collision partition for a physics sim where elements are most likely in the same sort position each frame.
- usefulcat 3y agoAround half as much code is generated for bubble sort compared to std::sort, e.g.: https://godbolt.org/z/KbaTeno3j https://godbolt.org/z/KbaTeno3j
- slaymaker1907 3y agoWhy would you implement your own atomics? It seems very similar to std::atomic, except you need to do a bunch of platform specific hacks to get it to work. The only possible reason I could think of why you would do this is if you aren't using at least C++11. If you aren't using C++11, then you probably shouldn't be using threads in the first place.
- qwery 3y agoI can't speak for the author, but using `std::atomic` would presumably break one of the project's listed principles: > No C++ Standard Library / Exceptions / RTTI
- reactordev 3y agoWhich is like making cookies without butter. It can be done, but why would you want to? The standard library exists for this reason. To provide these abstractions. And I laugh at the idea that C++ could ever be exception free.
- qwery 3y ago> why would you want to? It seems like you know C++ pretty well, so I think you could probably come up with some reasons if you gave it a try. The obvious thing that comes to my mind is because you can't rely on an undesirable, unknown, or potentially nonexistent implementation of the STL for your target platform. As for cookies: who am I to dictate what/how someone should bake?
- 112233 3y agoAs a person working in a large exception-free C++ environment, I'm all ears.
- pjmlp 3y agoI assume you're making use of no-throw placement new and not touching any standard library type, whose error conditions as available only via exceptions as per ISO C++. Otherwise good luck porting that exception free code across multiple OSes and C++ compilers, not only the big three.
- countWSS 3y agoActually this sounds useful as alternative to C++ stdlib: i've often compiled C++ code via GCC for simple stuff where C++ stdlib isn't included by default and all 'nice' C++ things are not linked, giving less overhead per file, but forced you to rely on ancient C functions. This would be a middle ground solution between unsafe C and bloated stdc++.
- pagghiu 3y agoI 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++.
- pjmlp 3y ago> No C++ Standard Library / Exceptions / RTTI This alone already rules them out as sane on my book.
- rockwotj 3y agoNo stdlib or no exceptions/RAII. Because everyone at Google is on the no exceptions/RAII train (according to the Google Style Guide), and I happen to like exceptionless C++
- pagghiu 3y agoAuthor here! Feel free to ask me any question, here or on discord/X/Mastodon I just saw this posted here, wow :)
- deterministic 3y agoPOCO is another solid collection of C++ libraries with similar objectives. It looks as if POCO is more mature.
- spacechild1 3y ago> It looks as if POCO is more mature. POCO started 20 years ago, so it has a slight advantage :)
- hermitcrab 3y agoInteresting. But I think the vast majority of this functionality is already available in the Qt framework, which I use for pretty much all my projects.
- pagghiu 3y agoOf 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.
- hermitcrab 3y agoThere probably isn't a compelling use case for Qt-philes like me. But I wish your project the best of luck! (the community version of Qt is LGPL, I have a small business licence)
- eterevsky 3y agoI don't think describing the build in C++ (https://pagghiu.github.io/SaneCppLibraries/library_build.html https://pagghiu.github.io/SaneCppLibraries/library_build.htm...) can exactly be called a "sane" idea. Declarative build definitions are generally much easier to work with and scale than using an imperative language.
- pagghiu 3y agoI 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 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.
- jokoon 3y agoStill no 3D renderer TinyEngine is good, but doesn't build on windows yet
- pagghiu 3y agoWell that would be slightly increasing the project scope
- integricho 3y agoI've come to despise how tightly integrated the C++ standard library is now with the c++ language itself, it is clearly evolving in a direction to make the two inseparable, but it is also making it less desireable. One cannot even compile a c++ executable with the /NODEFAULTLIB flag and not break core language features, e.g. static global object construction, dynamic_cast, ... For the purists that would like to separate the standard library from the language, and make tiny executables not depending on the runtime library, C is the only choice now it seems.
- trws 3y agoThis is what “freestanding” is for, FWIW. There are a variety of papers and implementations around this goal, which is generally to have a set of features of c++ the language and the standard library that can work entirely unhosted. I realize people think of this as a difference between c and c++, but if you go to compile C code with a thread_local variable and throw -nostdlib you’re going to have a bad day. Same for atomics, sometimes complex numbers, floating point exceptions, even receiving arguments and other core language features require some crt code. Removing the runtime library guts the implementation regardless of your language. The question is, does your language provide ways to deal with this? Rust has core, c has alternate ad-hoc embedded libc implementations and a history of bootstrapping implementations long enough to have them be well understood, c++ has/will have free-standing.
- rurban 3y agoI'm unsure about the asserts instead of errors