351–360 of 444 posts
Earlier quoted context omitted.
I think if write-only code were the norm, then APL would be more popular.
But there are APL, k, j and other array lang programs. You can't do as if those don't exist when talking about programming as a whole. Perl used to be pretty popular too.
Earlier quoted context omitted.
Sometimes you need to avoid GC or have direct control of your threading model and you need a language that is more expressive than C. Your only two options here with broad adoption are C++ and Rust, both of which are very complicated languages. Other languages like Zig, Ocaml, and Erlang have legitimate claims to similar performance to C++/Rust with expressiveness, but they do not have the same adoption.
See my comment elsewhere in this thread, where I argue that Go is a good replacement for C/C++ for almost all purposes.
That is most applications, in practice. Unpleasantly often, though, applications move from un-demanding to demanding, and then having been coded in Go is unfortunate. A nimble organization will code a C++ program for that use case. Lesser shops will lumber along patching the Go code.
Earlier quoted context omitted.
The "idiomatic" version is slowly getting slower because the idioms are getting higher-level and more expressive. If you don't use the idioms, you can have the same speed. Smart pointers (including unique_ptr ) have non-zero overhead compared to Foo*. The object oriented parts can introduce significant slowdowns. Template code can have huge code footprints if you are not careful, which slows things down. If you are l…
The above is commonly encountered, but not good advice. Most important, defend your hot path against incursions. E.g., don't pass smart pointer arguments around on hot paths. That is what matters. New language features are not slower than old features. But there are slow constructs to use carefully. Which they are will always surprise you, usually pleasantly. For example, almost everything around lambdas is fast, fas…
Also, my experience with lambdas has been otherwise. There are a lot of cases where lambdas need a heap allocation when you otherwise wouldn't. However, being able to use FP ideas can make up for that.
Earlier quoted context omitted.
Yes, they have been banned forever, and not just for size reasons. In the end, it makes code very difficult to reason about. It was a deliberate design goal of C++ exceptions that intermediate libraries/callers/etc do not have to be aware of, or handle, exceptions. There is no way to verify or check that all exceptions are caught by someone, etc. This is, as i said, deliberate. This is quite nice in smaller systems,…
This sounds nice but is not true. The bigger the system is, the more value you get from exceptions. The cost is that cleanup operations have to be in destructors. Do that, and exceptions demand almost no attention. Problems show up only when some prima donna declares throwing exceptions from what they call isn't allowed.
Google uses absl::Status / absl::StatusOr as a replacement for what people would usually use exceptions for.
The benefits:
1. As an end user of a large library I can tell you exactly which calls are "guaranteed" to succeed without learning anything else about the code.
2. It is impossible to ignore a Status/StatusOr which makes it impossible to ignore a failure. You have to explicitly ignore the return value which is easy to spot in code review.
3. You can return your exception across RPC an boundary with added detail so if a caller of your service.
4. You can (very easily) enrich the Status with metadata at every single point. So much so that it is very common.
5. You can enrich the way "exceptions" works in a way that makes sense for your company by changing the structure of Status.
Cons:
1. It is more unnatural than dedicated syntax like try/catch.
2. You can't bubble exceptions up the stack automatically so there are macros that do this for you (https://cs.opensource.google/search?q=ASSIGN_OR_RETURN&sq=)
Earlier quoted context omitted.
It's a branding problem. They should probably be viewed as different flavors. Using say herbs or colors instead of numbers would help. If every time they're going to add things, remove things and break things then we're in practice talking different strands. Imagine some preprocessor where you can mix them like #flavor(ginger) Instead of say c++11 and then proceed with whatever flavor as necessary. I know you can do…
> It's a branding problem. They should probably be viewed as different flavors. They are already different language versions. They're specified in entirely different standards. I don't see what's left to be confused about. At most, perhaps the C++ standard committee could be criticized for repeatedly going out of their way to maximize backward compatibility. > If every time they're going to add things, remove things…
It is mildly painful, bit not more painful than restricting to c++14.
Earlier quoted context omitted.
Compare GC Java with GC Go. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Thanks for the work separating out the solutions. It really helps compare the sort of code I'd actually write in those languages. Also, what is the reasoning behind no numpy? I'd never do something like nbody or Mandelbrot without numpy or torch in my actual job, so it isn't idiomatic in a way. Not a complaint, I could always fork it if I cared enough, just curious about the reasoning. I know pypy didn't really want…
Earlier quoted context omitted.
C symbols are supposed to be in std if you use the cstdio style headers. It’s just that for a very long time compilers put them into the global namespace too.
GCC, Clang, and MSVC all still duplicate c* header definitions into the global namespace by default as far as I'm aware. In fact, the last time I checked, the MSVC cstdio header was implemented more or less like this: namespace std { #include } using namespace std; It's kind of crazy how major compilers have been ignoring the standard for so long that people consider a standard compliant compiler to be weird and brok…
Earlier quoted context omitted.
I didn't say array programming doesn't exist, I said it's not popular. How many people actually use those languages compared to e.g. Python, where readability is one of its main features. > Perl used to be pretty popular too And now it’s a meme due to how illegible it is. I’ll put it this way, there’s a reason Brainfuck is a joke lang instead of something people seriously use. Also, reading and writing are not orthog…
and I am not writing about popularity, just saying that there are many in an absolute sense (which is honestly the only thing that matters in practice, relying on popularity of things relative to each other in a state of abundance is absolutely stupid)
Earlier quoted context omitted.
One way you could interpret this (definitely not the only way) would be that Microsoft - or some group within Microsoft - sees C++ as a possible legacy system, with an opportunity to make a lot of money by judging correctly what customers want and how much income you need to justify that support as existing offerings rust out (so to speak). Do you have any particular CPPCon talks to recommend ? My favourite is "Absei…
I really love this talk in particular: https://www.youtube.com/watch?v=4P_kbF0EbZM (On charconv) But any of the ones I've seen from Stephan have been fantastic, I think, although I'm not actually sure if I've seen more. He seems to have a lot of talks on very specific subjects, which can be really fun. > Hyrum Wright is in the audience yelling interjections as a result of Hyrum's law This sounds absolutely hilarious,…
BoostCon/C++Now 2012: Regex In C++11 And Boost: https://youtu.be/mUZL-PRWMeg
GoingNative 2012: STL11: Magic && Secrets: https://docs.microsoft.com/en-us/events/goingnative-2012/stl...
GoingNative 2013: Don't Help The Compiler: https://docs.microsoft.com/en-us/events/goingnative-2013/don...
GoingNative 2013: rand() Considered Harmful: https://docs.microsoft.com/en-us/events/goingnative-2013/ran...
CppCon 2014: STL Features And Implementation Techniques: https://youtu.be/dTeKf5Oek2c
CppCon 2015: functional: What's New, And Proper Usage: https://youtu.be/zt7ThwVfap0
CppCon 2016: tuple: What's New, And How It Works: https://youtu.be/JhgWFYfdIho
CppCon 2018: Class Template Argument Deduction for Everyone: https://youtu.be/-H-ut6j1BYU
CppCon 2019: Floating-Point charconv: Making Your Code 10x Faster With C++17's Final Boss: https://youtu.be/4P_kbF0EbZM
CppCon 2020: C++20 STL Features: 1 Year of Development on GitHub: https://youtu.be/8kjRx8vo6y4
Pure Virtual C++ 2022: MSVC C++20/23 Update: https://youtu.be/DAl37n2XOwk