Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
EA Standard Template Library
EASTL stands for Electronic Arts Standard Template Library. It is an extensive and robust implementation that has an emphasis on high performance.
That's why I am currently against its use, unless there is a very special case.
Regarding UniquePtr 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.
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.
https://github.com/SerenityOS/serenity
The best way to write proper exception free C++ is not to use the C++ Standard Library.
> you can still use it with smart pointers provided by any other library
Is the point of having a kitchen-sink library like this not that you dont have to reach for a 3rdparty library for things that you need 'all the time'?
Certainly, not everyone needs it.
...but, not everyone needs threads either. Not everyone needs an http server; and yet, if you have an application framework that provides them, when you do need them, it saves you reaching for yet-another-dependency.
Was that no the point from the beginning?
unique_ptr is a fundamental primitive for many, as you see from some other frameworks (1), and implementation is not always either a) trivial, or b) as simple as 'just use std::unique_ptr'.
This does seem like a very opinionated decision with reasonably unclear justification.
[1] - eg. https://github.com/EpicGames/UnrealEngine/blob/release/Engin..., https://github.com/electronicarts/EASTL/blob/master/include/...
> you can still use it with smart pointers provided by any other library
Is the point of having a kitchen-sink library like this not that you dont have to reach for a 3rdparty library for things that you need 'all the time'?
Certainly, not everyone needs it.
...but, not everyone needs threads either. Not everyone needs an http server; and yet, if you have an application framework that provides them, when you do need them, it saves you reaching for yet-another-dependency.
Was that no the point from the beginning?
unique_ptr is a fundamental primitive for many, as you see from some other frameworks (1), and implementation is not always either a) trivial, or b) as simple as 'just use std::unique_ptr'.
This does seem like a very opinionated decision with reasonably unclear justification.
[1] - eg. https://github.com/EpicGames/UnrealEngine/blob/release/Engin..., https://github.com/electronicarts/EASTL/blob/master/include/...