101–110 of 269 posts
Earlier quoted context omitted.
Have a look at any serious job postings. C++ jobs outnumber Rust jobs somewhere around 50:1. Internet hype meets actual industry reality :-).
Or could it be (or to be a bit of devil's advocate) that Rust projects require only 2% (1/50) of manpower, comparing the same project using C++?
Earlier quoted context omitted.
The standards committee's job is not to develop products like software packages for free. It is to ensure that the language meets the requirements of stakeholders, many of whom develop competing commercial products. Of course, these tools are of interest to the broader C++ community. Thanks for sharing.
I'm not asking the standards committees to develop them for free. They were already developed! I'm saying that the committees should acknowledge their existence, and the fact that they solve some of C/C++'s biggest problems, in some ways better than the committee-blessed solutions. They deserve attention from the committees to direct language evolution in ways that support them better and encourage alternative implem…
>Both zapcc and Fil-C could benefit from the involvement of the standards committee.
What exactly does the standards committee do for these software projects without being involved in their development? I think there is nothing to do here that is within the scope of the language itself. Of course, if the creators of those projects come up with a cool new idea, they can submit to the standards committee for comment. They can also comment on new standards that make the tools not work anymore. But that is help going from the project to the committee, not the other way around.
Earlier quoted context omitted.
Why should anyone use zapcc instead of ccache? It certainly sounds expensive to save all compiler's internal data, if that is what it does. I'm sure you must be aware, these compiler tools do not constitute a language innovation. I'd also imagine that both are not productions ready in any sense, and would be very difficult to debug if they were not working correctly.
Zapcc can, and frequently does, speed up the compilation of single files by 20x or more in the incremental case. CCache can't do that. And it's by far the common case when compiling iteratively during development. A speedup that large is transformational to your development workflow.
Earlier quoted context omitted.
There is a big big difference between C and C++. The article is about C++, which is being replaced by Rust imho. C is different, and far more frequently used for embedded or OS development. Don't know about games, but last I looked, stuff like unity was C#, so something else yet again.
C++ is widely used in embedded. Most compilers support it. Usually you turn some things off (e.g. -fno-rtti, -fno-exceptions) and try to stick to some sane subset of the ++.
C++ as C with classes is a pretty good language!
Earlier quoted context omitted.
D modules are very fast. Many of our customers rely on D being way faster than C++ to compile.
I often hear about a lot of advantages of D. So I don't understand why it is so unpopular. Probably I need to give it a chance, but I'm unsure that I will find a real job with the D stack.
Earlier quoted context omitted.
D modules are very fast. Many of our customers rely on D being way faster than C++ to compile.
How does D avoid the problem I described?
Earlier quoted context omitted.
What has to change in C++ templates for this to work? It seems particularly tricky to define a template in a module and then instantiate it or specialize it somewhere else.
In order to make things work smoothly, the module has to have its own namespace, and a namespace that is closed. D also has an `alias` feature, where you can do things like: alias Q = abc.T; where from then on, `abc.T` can be referred to simply as `Q`. This also eliminates a large chunk of purpose behind the preprocessor.
Earlier quoted context omitted.
A lot of the problems with C++ are more foundational; you can't adopt the changes that newer languages have made, because that would be a new language - and we know this, because that new language's name is Carbon. There are things you can add , but the rot still permeates the foundations, and much of the newness goes partially unused because they're just not at home in C++. Use of `std::optional` and `std::variant`…
optional is heavily used in new codebases. variant isn't, yet. We'll eventually get some kind of structural pattern matching that will make variant or it's successor more idiomatic. C++ does have quite a bit of rot, you're right. But that's the price of building technology people actually use. Carbon doesn't seem to have any fundamentally new ideas, we'll see how well it fares in the wild.
Thats the fantastic thing about c++, you can already write an easy to use match, but they just chose not to include that in the stdlib but rather want you write that yourself.
Example:
match(foo,
[](Foo&) {
},
[&](Bar& bar) {
},
[&](const auto& mode) {
// catch all
});