271–280 of 395 posts
Earlier quoted context omitted.
> but they can't catch all the places where the abstraction leaks. Why does static analysis not work here?
It does, it's just a warning and not an error. And also experimental. But it does exist, and does catch some of these errors. Example: https://godbolt.org/z/CZTfSx
Earlier quoted context omitted.
Rust's learning curve isn't exactly a shallow one either. For the record I think Rust has a lot going for it, but it is not the C++ killer that many are touting it to be.
> Rust's learning curve isn't exactly a shallow one either. I don't know how people can be so sure of this. We know essentially nothing about how to teach or learn Rust effectively, it's something that the community is just starting to look at. However, one thing we do know is that the detailed support that the Rust compiler provides to the novice programmer is quite simply unparalleled in other mainstream languages.…
Earlier quoted context omitted.
desktop-GUI: What community? Web devs trying to write desktop apps? Embedded: Try to write a safe string and vector with bounds checking, or IO port access in C like in C++ type system allows for. Lua is nice for hobby, not production class hardware deployments. Scientific: Depends, many libraries are yet to be written. IDE tooling: Typescript and C# audience isn't the same as those using raw C++.
desktop-GUI: Yes, frontend today is a combination of Web & apps, C++ does not fit in either. UWPs can be written with JS or C#. Writing desktop-GUI is also on the decline, however I could see potential increase in desktop-GUI-programs if governments continue to pass bad regulations of the web like content filters & link tax. Embedded: How come C++ is not dominating embedded? According to you, it should. IDE tooling:…
I have spent the last 4 years doing green field desktop GUIs, apparently those customers haven't got the news.
HTML5 APIs still aren't a match for plenty of native APIs.
Embedded: Religious hate against C++ from older timer devs, as discussed in several CppCon and Meeting C++ talks, e.g. Dan Saks has quite a few of them.
CppCon 2019 will change location, because they no longer can fit everyone on the old location.
Earlier quoted context omitted.
Writing memory safe programs in C++ is possible. Most coding styles and some problem domains don't lend themselves to it naturally, though. In my experience, restricted subsets used for embedded software vastly reduce the risk of introducing errors and make actual errors easier to spot and fix.
> Writing memory safe programs in C++ is possible. Everything "is possible" in the sense that in theory you can do it. But if time and time again people fail to do it. Even people who invest almost heroic levels of effort (see above: valgrind, multiple sanitizers, and so on) you get to the point where you have to accept that what is possible in theory doesn't work in practice.
Earlier quoted context omitted.
A feature that exists since 1961, across several systems languages.
I never understood this type of comments, is what you are trying to say something like: "It was already tried and failed, why is this time better" "Mainstream languages always end up not using it" "People should reference more the original works of the past" ... One of the many explainations of the name Rust is that it represents a collection of old ideas. What was the point you were trying to convey in specific?
Earlier quoted context omitted.
> The standard library certainly is lacking things which are commonly used (say, JSON parsing or database connection), I strongly disagree. It's quite obvious that the C++ standard library does not need to add support for "common things", because they already exist as third-party modules. In fact, this obsession to add all sorts of cruft to the C++ standard is the reason we're having this discussion. If there is no w…
Standard libraries shouldn't include "leaf" modules, but probably should include interface / adapter modules. So no to JSON, but maybe yes to a serde interface. No to a database driver, but maybe yes to an interface like JDBC. Without common interfaces, flexibility in implementation is much more expensive, and innovation suffers too, as new things are harder to get off the ground without existing code that they can c…
So instead of trying to figure out which one of the dozens of GUI frameworks to use in making a window and have it change colour, you just write it using the standard library. You want to do a HTTP request, then there will be code in the standard library for that.
It will also save work trying to figure out which third party library to use when you want to do these things locally on a small test project.
Earlier quoted context omitted.
The difficulty here is combining multiple libraries each using its own abstractions. For example, since the standard library does not have a Matrix class suitable for numerical applications (or maybe it does today...) using multiple libraries each with its own Matrix class is difficult. Multiple libraries are needed since one library may not contain all numerical algorithms one may require for a given app. This is no…
> For example, since the standard library does not have a Matrix class suitable for numerical applications (or maybe it does today...) using multiple libraries each with its own Matrix class is difficult. well, Python comes with a builtin "matrix-like" array type and yet it's not the one which is the most used in scientific computation.
Earlier quoted context omitted.
The difficulty here is combining multiple libraries each using its own abstractions. For example, since the standard library does not have a Matrix class suitable for numerical applications (or maybe it does today...) using multiple libraries each with its own Matrix class is difficult. Multiple libraries are needed since one library may not contain all numerical algorithms one may require for a given app. This is no…
> For example, since the standard library does not have a Matrix class suitable for numerical applications (or maybe it does today...) using multiple libraries each with its own Matrix class is difficult. well, Python comes with a builtin "matrix-like" array type and yet it's not the one which is the most used in scientific computation.
Earlier quoted context omitted.
There is no such language as C/C++. There is C, which cannot be written safely, and there is C++, which can be, and quite often is. It has been many years since I shipped a memory bug in C++. It is just not a real worry for me. I am constantly dealing with design, specification, and logic flaws, which affect Rust equally, or moreso. I am aware that there are plenty of other programmers out there, writing bad code in…
> It has been many years since I shipped a memory bug in C++. It is just not a real worry for me. Can you write down the algorithm that you use to avoid writing memory bugs? Can you teach others how to do it? Experienced C++ programmers do seem to learn how to avoid those bugs (although very often what they write is still undefined according to the standard - but e.g. multithreading bugs may be rare enough not to be…
Structure the code in a way such that it is obvious what happens. Use "semantic compression" (e.g. be clear about your concepts and factor them in free standing functions), but don't overabstract/overengineer.
Eliminate special cases. If the code has few branches and data dependendencies, then successful manual testing gives already high confidence that it will be pretty robust in production.
Prefer global allocations (buffers with the same lifetime as the process), not local state. This also makes for much clearer code, since it avoid heavy plumbing / indirections.
I tend to think that modern programming language features mostly enable us to stay longer with bad structure. And when you hit the next road block, fixing that will be correspondingly harder.