ucrt
By huangqinjin
llfio
P1031 low level file i/o and filesystem library for the C++ standard (by ned14)
| ucrt | llfio | |
|---|---|---|
| 3 | 25 | |
| 55 | 779 | |
| - | - | |
| 0.0 | 6.3 | |
| over 1 year ago | 4 days ago | |
| C++ | C++ | |
| GNU General Public License v3.0 or later | GNU General Public License v3.0 or later |
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
ucrt
Posts with mentions or reviews of ucrt.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2022-12-09.
- Should I use platform dependent file IO instead of basic_fstream when performance matters
-
The wild west of Windows command line parsing
TBH, I would rely on the algorithm as implemented in the latest CRT (I believe a relatively fresh mirror can be found here) - that's likely what a program compiled against it will receive. There's an opposite (argv→command line) function there as well.
-
How I cut GTA Online loading times by 70%
Looks like it has a reason: https://github.com/huangqinjin/ucrt/blob/a52376780e631fb0e5d520748addb03651aef0b5/stdio/input.cpp#L95-L98
llfio
Posts with mentions or reviews of llfio.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2023-02-04.
-
File IO question if something is in stdlib or not
The reference library can be found at https://ned14.github.io/llfio/
-
Is there a good cross-platform (Windows / Linux) C or C++ library for file I/O?
Thanks for the suggestions, which I have transposed into https://github.com/ned14/llfio/issues/106
-
Should I use platform dependent file IO instead of basic_fstream when performance matters
There was an effort to get an afio library accepted into boost in the past. I believe the most current work on that library is happening here nowadays : https://github.com/ned14/llfio I'm not sure if it is considered production-ready or not. But I couldn't see any mention of it in the replies so I figured I would fix that!
-
File Handling in C++
It has an implementation: LLFIO
- Proposed Standard Secure Sockets reference implementation complete
-
Getting started with Boost in 2022
I'm a fan of Interprocess, used it for over a decade. But for mmapping I've switched to LLFIO and recommend it highly. (Plugging so Niall doesn't have to.)
-
Networking TS: first impression and questions;
Since that post, I have the reference implementation library very nearly passing its test suite https://github.com/ned14/llfio/pull/89. Once it's done I'll start very slowly writing its proposal paper for WG21 SG4. Should land before this summer.
- P2300 (Sender/Receiver) is DEAD in the water for C++23 !!!
-
IO library for embedded devices - looking for contributor
FYI it doesn't solve quite what you're solving, but I've been careful to ensure https://github.com/ned14/llfio works well on Freestanding and < 64 Kb microcontrollers and I know Victor has been careful to ensure a good subset of std::format could work well on embedded. In other words, the i/o story for embedded C++ may improve greatly in the next few years.
-
Weird fstream behavior after MSVC upgrade
If you want stronger guarantees than iostreams can give you, either use the OS-specific calls or a wrapper of said calls (e.g. https://github.com/ned14/llfio, disclaimer I'm the owner of that). Note that even in LLFIO, there is no concept of "seek to the end" because that's racy so we don't implement that. All you get is atomic append, otherwise you're on your own to coordinate what "end of file" means.
What are some alternatives?
When comparing ucrt and llfio you can also consider the following projects:
GTAO_Booster_PoC
mio - Cross-platform C++11 header-only library for memory mapped file IO
pysimdjson - Python bindings for the simdjson project.
libunifex - Unified Executors
simdjson - Parsing gigabytes of JSON per second : used by Facebook/Meta Velox, the Node.js runtime, ClickHouse, WatermelonDB, Apache Doris, Milvus, StarRocks
mold - Mold: A Modern Linker đź¦
countwords - Playing with counting word frequencies (and performance) in various languages.
parallel-hashmap - A family of header-only, very fast and memory-friendly hashmap and btree containers.
corrade - C++11 multiplatform utility library
robin-hood-hashing - Fast & memory efficient hashtable based on robin hood hashing for C++11/14/17/20
chromium_base_conan - Modified `base` library from chromium
wg21_p2459_2022_january_library_evolution_poll_outcomes - Outcomes of the 2022 January C++ Library Evolution polls.