yuushi

Except this (attempted) mask mandate ban was for kids - i.e. those who are often too young to receive a vaccine.

Yes, our federal government absolutely failed when it comes to vaccine supply. It is our state governments that have instituted lockdowns, because of this failure on behalf of the federal government, to squash cases and stop our hospital system from reaching breaking point.

Yes, our federal government screwed up, and I don't know anyone who doesn't agree with that point, but given that, and given the outcomes America experienced before vaccination was prevalent, it is the height of hubris and arrogance to suggest that you and the rest of the Western world (this "data" being pulled from where, exactly?) is "horrified at us".

It is not endemic in many states in Australia.

But please, continue looking on in horror at us from (I'm assuming) America. Your post is a wonderful mix of condescending tone and factual inaccuracy, with the added cherry-on-top that you have absolutely moronic states like Florida "fighting for their freedoms" by banning mask mandates. This would be infuriating if it wasn't so painfully stupid.

That's because modules and namespaces are the same thing in languages like Python, whereas they are separated in C++. The code in the imported module will go into whatever namespace it is in within that module, not the global namespace.

Modules have nothing to do with shipping libraries (or dependency management), they are purely about encapsulation of interface and (API) implementation.

If by "reload" you mean "drop in an updated shared library and let the runtime loader do its job", I suppose so.

Yes, it only applies if you don't make any API (and ABI) changes, but that's what major, minor, patch versioning is for, and stable projects can go a long way on minor and patch versions...

> I can't remember the case in C, but in C++ the initialisation of a function local static variable is guaranteed to be thread-safe.

Only in C++11 onwards.

Depending on what you required, it can still be significantly faster than std::map. Any tree-based data structure is going to play havoc with cache. Also, it will perform an allocation for every single node inserted, which can become rather expensive (unless you're using some customized allocator for this).

Honestly, sorted vectors can often be a good replacement, depending on the workload, if you must have ordered data (this is what boost flat_map uses). All 3 (map, unordered_map, sorted vector) can have their uses, depending on what you are doing with the data.

If you need a better performing hash map, there's always Abseil as well.

Define "way easier". The interface, at least for day to day operations, is basically identical.

I remember this being in the context of video games, and from some time ago (so things may have changed with Steam sales and the like), but it said that something like 85% of sales occur in the first two weeks. Thus the DRM was there to (hopefully) hold out for as much of that initial time as possible.

Anyway, anecdotal story, take with (many) grains of salt.

Correctness defined as "this produces the right answer" vs correctness defined as the above with the addition of "this does not leak information / is not highly vulnerable to side-channel attacks" are very different things, and only one of those definitions is actually useful for cryptography.

Writing it yourself for the first time, or just copying some code off the internet, is going to have a vanishingly small chance of being actually secure.

I mean, you really are a special case - I have only lightly dabbled in Rust, but I immediately recognize your name because of the work you've done in the Rust community.

If you have the luxury of choosing between C++ and Java/C#, then you don't need C++.

This doesn't take into account the alignment of the type though (you'd want to use std::aligned_storage<sizeof(T), alignof(T)>), but that requires knowing enough about T to be able to use sizeof() and alignof(), which means no incomplete types, bringing us back to where we started.

This could only ever be doable with extremely simple architectures anyway. Off the top of my head, add in just one of branch prediction, micro-op fusion, out-of-order execution, pipelines and pipeline stalls, or cache misses, and this becomes impossible. Of course, this assumes you even know which CPU you are targeting its specific instruction latencies.

That's already an extremely niche set of processors. Further, the number of bits of code you're likely to care about this kind of extremely precise timing for, you'll either examine the emitted assembly, or just hand-write the ASM yourself.

It seems like a huge amount of effort for an extremely niche scenario. Remember, the ISA is still just an abstraction, after all.

Sure, you can pass by pointer instead of reference, but the post also mentioned that they didn't use the STL (hence no std::vector) and I'm curious if that means they used a replacement library or something else.

> SIMD

Intrinsics are directly callable from C++.

> likely/unlikely branches

Most compilers have extensions that will allow you to do this (__builtin_expect and so on).

> in-lining can't be forced when you know it gives better performance

Again, most compilers have this, not just GCC, e.g. __forceinline.

> the compiler has a lot of trouble knowing when lines of code are independent and can be done in parallel (b/c const =/= immutable)

This is true, as aliasing is a real issue. The hardware itself has some say over this anyway, dependent on its instruction scheduling and OOE capabilities.

What you don't mention, however, is the fact that almost no other languages offer any of these, let alone all of them. Rust may be the exception here, although some of this is still in the words (SIMD, I'm not sure about the status of likely/unlikely intrinsics).

For GPU programming, if you're using CUDA, you're almost certainly using C or C++, or calling something that wraps C/C++ code. Not everything is suited to GPU processing anyway, there's still a lot of code that's not moving off the CPU any time soon that needs to be performant.

The second is absolutely an advantage of references, and other than having to use (if I'm being honest, legacy and/or bad) interfaces, there is absolutely not a downside in this regard.

The first can be a legitimate complaint, although I find it's rarely an issue in practice.

Out of curiosity, what do you use? I hope it isn't back to raw pointers and size_t offsets for lengths. What do you do if you want to pass a container of ... anything around? What's the replacement for:

   U do_something(const std::vector<T>& vec);

Go is not even close to being any kind of replacement for C++. Also, not all "real programmers" think that C is a better language than C++.

They were bought out by iiNet. Apparently Adam also signed deals for a takeover by iiNet in August this year.

It shouldn't be the standard way of managing memory; it should be a part of the toolkit. In order, it should look like:

1) Stack allocation 2) std::unique_ptr 3) std::shared_ptr

You should be properly thinking about onwership semantics, and unique_ptr should be the default, not shared_ptr.

Sure. Think of void * in C. interface{} in Go isn't really that different, there's just a bit more language support for testing if it satisfies a specific type or not. Add in type assertions, and it's basically as though you had a dynamic_cast in C++ that worked from void * to an interface type.

To me, it just seems ugly. I like a type system where I know what a type is at each point, and there isn't some ugly "catch all" type that you can use when you run out of other options, which effectively just throws away all type information (and this is what interface{} does, as everything implements it).

I think interface{} is a horrible, horrible hack. For me, the answer is an emphatic yes.

I remember having read this before, but I always get a good chuckle from it; all of the snark is incredibly well done. I always burst out laughing when reading "Lambdas are relegated to relative obscurity until Java makes them popular by not having them."

Why does it have to be limited to a single language at all? Exposure to multiple languages should be the norm.

I agree with this, although I live in one of the smaller Australian cities and cannot move for various reasons. I am desperately trying to find a reasonable programming job, but having quite a hard time. Pretty much all the jobs around here are IT department style, with long winded garble on job boards, and silly requirements about - just from memory, I've seen things like "must be familiar with at least one of C, C++, Java, XML" (Apparently XML is a general purpose language) or "Knowledge of C++ or Delphi required" (What these two have in common I'll never know). I'm sure such ads exist in other places as well, but there seem to be an unnervingly high proportion around here.

I'm not sure what it's like in Sydney or Melbourne, however. Perhaps it's better there...

Which languages makes all the difference. It's more important to know at a language from a broad number of paradigms, rather than knowledge of a bunch of C-syntax-derived object oriented languages (I say this, but I'm just as guilty of it as many others, despite trying to rectify it).

Frequent usage is more difficult, though. I'd like to think I know C++, Java, C and Python all very well, SQL to a reasonable level. However, add the "dabbling" languages: Racket, Haskell, Scala, C#...where exactly would the time for using these frequently come from?

Arguably, languages are only important to an extent - libraries surrounding languages are the truly important part.

This is actually discussed in some length in Jacques Hadamards "The Mathematicians Mind" - although I'm certainly no psychologist or neurologist, and some of the ideas are probably incredibly out of date, it was interesting reading nonetheless.

Actually, a WRX won't have the luxury car tax applied to it; from Wiki: The LCT threshold is currently $59,133.00AUD. Car pricing in Australia is pretty horrific, which is probably due to both taxation and the government trying to protect local manufacturers.

That sounds fine for intra-school comparisons, but as far as I know, the teacher comparisons are inter-school, which is a whole lot less random in student assignments.