201–210 of 444 posts
Say I have a new project to start today. I need pick a language to use: 1. a well-tested language 2. can not use garbage collector due to *performance* requirement 3. easy to hire if project expands. 4. ready to use tooling support 5. widely available tutorials and info on the web. 6. language is itself alive and updated 7. project can be scaled over time. what options do I have? I have to pick up c++ in this case. i…
Earlier quoted context omitted.
Go's garbage collector is faster than you imagine. Have you used it? Go is a good replacement for C and C++ for almost all purposes. Most purposes where Go is inapplicable should be using explicit SIMD (GCC intrinsics) or CUDA C anyway. The others purposes where Go is inapplicable are low-level real-time stuff that should be written in C for a specialized software stack (e.g., software in a car).
What are people using C and C++ for that you can comfortably use Go instead?
The compiler is a huge assemblage of C++ templates, stitched together with a little Python.
The generated code is in an assembly language for a highly parallel machine, and needs to be heavily optimized down to the cycle.
But the compiler itself does NOT need to be so minutely tuned. It needs to be maintainable and it needs to allow easy development of complex code generators.
Go would be a great choice for the compiler.
Instead, we struggle with C++ templates, CMake'ing our code slowly and with absurd complexity, modifying the compiler slowly and with great difficulty...
Many are of the listed items are merely being deprecated. These shouldn’t really qualify as breaking changes. In fact, the ability to migrate away incrementally is precisely the point of deprecating instead of removing a feature. What surprises me is that a lot of the deprecated functionality seems really recent — C++14 or newer. Compatibility is C++’s big thing, that’s historically why it kept almost all of C as a s…
Mostly deprecations mean something was deemed to be a bad idea, which means it's at the very least worth taking a moment to evaluate whether somehow they were a good idea when you did them. For example should I have a method whose parameters are volatile? Well, why did I do that? It didn't do anything in C++ 17 and it still doesn't do anything in C++ 20 but now it's deprecated. Programs are written first and foremost…
"Most" maybe by count, but I'm not sure if it's "most" by usage frequency. There have been & will be lots of nonsensical deprecations that are much more common in existing code than "putting volatile on an object argument" (which I've honestly never even seen anyone do in my life)... like static (which was undeprecated, thankfully, but how were people supposed to know this ahead of time?), std::aligned_storage, std::bind1st, std::iterator. They're frustrating as heck, have questionable merits to begin with, and working around the deprecations in existing code provides practically zero business value.
Earlier quoted context omitted.
Go's garbage collector is faster than you imagine. Have you used it? Go is a good replacement for C and C++ for almost all purposes. Most purposes where Go is inapplicable should be using explicit SIMD (GCC intrinsics) or CUDA C anyway. The others purposes where Go is inapplicable are low-level real-time stuff that should be written in C for a specialized software stack (e.g., software in a car).
Even with version 1.18 the median is 3x slower than c++ in the benchmark game. And most of those programs don't even exercise the GC (other than binary trees benchmark). If you are targeting a quadcore arm embedded type thing with no gpu, go is going to take something that saturated one core, and make it saturate 3, if you are lucky enough it is easily parallelized. Even when a gpu is available, it often isn't a good…
For example, the C/C++ implementations use arena allocators, and they could do the same for the Go implementations, but they don't.
The Benchmark Game is a joke. Here it is, for anyone who wants a good laugh: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
I wonder how long it would take an experienced developer to rewrite all of Chrome in Rust. It would probably take a special person though who is an expert in C++, Rust, and the codebase.
If a tech giant wants this to happen - e.g. because memory un-safety is mostly the root of all evil - they can use people from the current team and throw a few millions on hiring new talent.
My introduction to c++ was a variant of this book https://www.amazon.co.uk/Sams-Teach-Yourself-21-Days/dp/0672... when I was about 12. However one thing that really stuck with me was a professor at university saying "if you think you know c++ that just means you don't know it well enough to know you don't know it"
Earlier quoted context omitted.
1. No, that's wrong. Incrementing a volatile isn't undefined. The problem is that some people are using volatile when they actually want atomic variables, so the behavior of the program becomes undefined when you have two threads incrementing the same volatile variable at the same time. The compiler might or might not compile volatile_variable++ into an atomic operation, but some people wrote code under the misunders…
std::move is just syntax sugar over static_cast (t) ; the language feature that needs library support afaik are: - Overloading some of the "new" operators (need #include ) - - typeid which needs as you said I don't see which parts of the language need pair and tuple at all?
Say I have a new project to start today. I need pick a language to use: 1. a well-tested language 2. can not use garbage collector due to *performance* requirement 3. easy to hire if project expands. 4. ready to use tooling support 5. widely available tutorials and info on the web. 6. language is itself alive and updated 7. project can be scaled over time. what options do I have? I have to pick up c++ in this case. i…
Sounds like Fortran to me.
Say I have a new project to start today. I need pick a language to use: 1. a well-tested language 2. can not use garbage collector due to *performance* requirement 3. easy to hire if project expands. 4. ready to use tooling support 5. widely available tutorials and info on the web. 6. language is itself alive and updated 7. project can be scaled over time. what options do I have? I have to pick up c++ in this case. i…
Go's garbage collector is faster than you imagine. Have you used it? Go is a good replacement for C and C++ for almost all purposes. Most purposes where Go is inapplicable should be using explicit SIMD (GCC intrinsics) or CUDA C anyway. The others purposes where Go is inapplicable are low-level real-time stuff that should be written in C for a specialized software stack (e.g., software in a car).
I started reading the link "bans everything to start with anyway" in the slides: https://chromium.googlesource.com/chromium/src/+/HEAD/styleg... And I noticed the ban of shared_ptr and . I know the use of shard_ptr should be done cautiously, but just banning it from use? How do the Chromium devs solve a problem that requires shared ownership? I guess you can come a long way with singletons and consumer/producer queue…
Chromium has an existing ecosystem with a variety of smart pointers already.