I run a 2010 MacBook pro which I have upgraded the RAM and swapped out the disk for an SSD (luckily 2010 was pre motherboard soldering nonsense). It still runs like a champ 8 years later.
I wonder if one could introduce a secondary classifier which is immune (or more resistant) to this kind of attack as a fail safe. One idea that comes to mind is to back the neural net with a random forest, which I imagine would be very hard to trick with this kind of attack as a collection of independent (key) weak learners are trained on the data. To trick a random forest, you would have to trick the majority of the trees within it.
Cruising along with frequent pit stops for garbage collection.
All jokes aside I agree with you to some extent: C++ can be frustrating to work with, and there are a lot of quirks that make it really easy to blow your foot off.
These quirks are not without benefit though. Being able to control how memory is allocated is hugely important in performance sensitive applications where pointer chasing is not tolerable. The same can be said about r values/move semantics.
One nitpick (and this applies to almost every site of this genre, i.e. geeksforgeeks, hackerrank, etc.):
The code listed as "C++" is essentially C with ostreams. If I were interviewing someone and they claimed to know C++, and then used "sizeof(A) / sizeof(A[0])" to get the size of an array, I'd question how much C++ they actually knew. I understand that the focus here is mainly on problem solving and not language specific patterns, but when you advertise the site as a coding interview helper I think that the solution code should reflect that which should be written in an actual interview.
I'd be interested in seeing the rational behind the fairshare policy. I suppose theoretically the firstfit policy could result in starvation via one thread constantly preempting another during the lock contention, but I don't imagine that would happen very often in practise.
This is true, though generally anytime one uses `auto` it should be `const auto&` to avoid swallowing the quantifiers and potentially costly copies anyways.
Call me naive, but I REALLY think people are overreacting on this. Yes, the timing does seem quite coincidental given the Cloudflare bug, but Google has a pretty good record of being transparent with these things.
On top of this, Google does not use Cloudflare and as far as I know there have been no reports of accounts actually being comprised, only logged out. I would wager whatever maintenance routine they were carrying out accidentally invalided some user sessions.
Potentially, yes. Assuming that you are correctly synchronizing the actions inside each Task as to avoid race conditions (a big assumption), there is no control on the number of threads here. What if your program is already using a bunch of threads for something else, and then you go ahead and spawn off 10 more? You will oversaturate the CPU and end up with virtual threads, thus incurring scheduling overhead. In my opinion when you are doing this type of thing you should almost always use a thread pool to ensure that you aren't creating an unreasonable number of threads.
I've found that most of my multithreading needs can be serviced by a simple thread pool that I rolled using the constructs that c++ provides (std::queue, std::thread, and std::future mainly). Obviously it's not heavily optimized, but for CPU bound tasks it gets the job done and doesn't require any heavy lifting installing libraries and what not.
I noticed that too, I think he may be referring to the fact that generating super large actual prime numbers is hard, so people use probabilistic algorithms to generate probably almost primes
Not quite. You can submit as many jobs as you'd like to the pool and it will delegate them to 16 threads. The pool maintains a queue of work to be done and the fixed number of threads consume from the queue.
[1]: https://github.com/eliben/static-server/blob/main/internal/s...