Why the library additions?
Why the library additions?
Posted Jul 7, 2024 9:10 UTC (Sun) by tialaramex (subscriber, #21167)In reply to: Why the library additions? by jlarocco
Parent article: New features in C++26
There are a large number of resulting problems, but in particular this creates an inevitable pressure to land things in the stdlib which should not live there, because it's convenient for everybody to just have them work and in C++ the only way to achieve this easily is to modify the stdlib.
This in turn creates a pressure to lower standards for quality of implementation (after all, the stdlib is maintained either by volunteers or at Microsoft by a modest team of people who aren't experts in all these myriad new features) and to fix in place forever the API since it would now be a breaking change for the entire programming language.
So the result is that you get a lot of mediocre "It was pretty good twenty years ago" stuff in the stdlib, and a pressure to keep adding more, forever.
Posted Jul 7, 2024 11:19 UTC (Sun)
by PengZheng (subscriber, #108006)
[Link] (4 responses)
There are already several C++ package managers, e.g. Conan/vcpkg.
I deployed Conan successfully in my day job, supporting a team of more than 100 C/C++ developers.
Posted Jul 7, 2024 20:08 UTC (Sun)
by atnot (subscriber, #124910)
[Link] (1 responses)
But that's somewhat besides the point, because the real reason they're not really solving the problem is that because the language and compilers, build systems and package managers are not being co-developed or co-standardized to any degree, neither can make any assumptions about the others being reasonable or even existing at all. You may have conan, or a blank windows install. You might have clang main, or an ancient shitty vendor toolchain. It might be bleeding edge C++ or k&r C. It might be some megacorp's hyper advanced distributed monorepo build tool, or hand-typed compiler invocations in a shell or batch file.
Now in part this is of course due to having approximately 40 less years to accumulate cruft. But even in modern C++, we see the same patterns, with e.g. modules being standardized in a form none of the popular build systems could easily support with a high quality implementation, because two compilers just implementing the syntax was considered sufficient to lock it in stone forever, because that's where the horizon ends as far as the C++ committee is concerned.
This is not only very different from the e.g. Rust process, where features can be experimented with across the whole stack, from crates.io to the compiler before being stabilized, which avoids such scenarios. It also prevents any part of that from chain assuming that you're probably using one of those tools, or at least something roughly equally capable (e.g. meson instead of cargo as a build system) in their designs. Which is exactly how the C++ STL ends up being simultaneously too big and too small at once and that just keeps getting worse.
I think they really urgently need to start acknowledging that build and dependency management is just as much a part of the language experience as the syntax is and pull it into the process, as controversial as that will probably be initially.
Posted Jul 8, 2024 13:34 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link]
There is some effort to try and get some consistency across the ecosystem:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/...
There are some revisions from the last meeting that don't seem to have made it to the paperbot yet; should be in the next mailing. For anyone that wants to get involved:
Posted Jul 7, 2024 21:11 UTC (Sun)
by edgewood (subscriber, #1123)
[Link]
I searched for "rust without cargo" to confirm my understanding, and found a quote that expresses it better than I could:
"Pretty much the entire ecosystem is based around you using Cargo. Things are not added to the standard library on the basis of "people use Cargo." The compiler's command-line interface is optimised based on the assumption that you are using Cargo. Many Rust tools are designed on the assumption that you are using Cargo."
That's the point that tialaramex was making: because C++ doesn't have a package manager that everyone has and approximately everyone uses, there's pressure to put functionality in the standard library that maybe isn't ideal there.
Posted Jul 8, 2024 13:30 UTC (Mon)
by khim (subscriber, #9252)
[Link]
And which tutorial tells about them before it tells you how to write any substantial program? Just look on Rust's official one. In there Getting started part includes precisely three subparts: Installation, Hello, World!, Hello, Cargo! And the other tutorials are similar: they talk about That way the use of And that in turn, means that if you decide not to use external crates (not any particular one, but all of them, on principle) you are “the weirdo who would have to do something about it”, while in C++ world it's not even remotely the case.
Why the library additions?
In this regard `cargo` may not be that advantageous over existing C/C++ tools as you thought.
Why the library additions?
Why the library additions?
Cargo isn't *a* package manager for Rust, it's *the* package manager. I understand that it's technically possible to not use it, but approximately no one does.
Cargo vs C++ package managers
> There are already several C++ package managers, e.g. Conan/vcpkg.
Why the library additions?
cargo as base way to use Rust and then, somewhere in the “advanced” section they talk about other ways to organize your code.cargo is the cornerstone of your development, it's when you decide to not use cargo you need extra knowledge and extra work.