This is one of the many great improvements of C++11
6,062 karma · joined September 29, 2011
This is one of the many great improvements of C++11
But he wasn't a first famous social engineer. That was extremely old hat by then.
People keep claiming he is a notable technologist, but I can't think of how. The Internet and other systems had intrinsic design flaws in the early day because it was birthed as an overly trusted network of well-known peers. Poking for flaws in those days didn't require any skill. The Morris worm, for example, was extremely skillful.
My biggest exposure to anything related to him is KnowBe4 and it is an utter piece of crap. It provides training modules that have no idea who their audience is so it veers wildly between terrible advice and overly technical advice with alongside the correct advice.
And lastly, and I mean this sincerely, my condolences to his family and friends. No one should have to go through this so young.
Keep at it! Just as every program is a chance to improve programming, every article written is a chance to improve writing. It was well written.
String length tells you the frequency with which nul terminators will be found. Without knowing frequency of occurrence of the nul terminator, 's', and 'p' then you cannot know which one occurs most often.
Consider two benchmark cases: (1) every string tested contains exactly one character (2) every string tested is 1MB long and is composed entirely of 's' and 'p'.
The author's first "optimization" assumes nul is rare. It would make benchmark (1) worse, and (2) better.
The article is a good example of "specification is hard, code is easy." He insufficiently specified the problem to be solved, and his test cases contained information not in the code and not in the text of the article.
Consider this statement: "However, we know some things about this loop. We know that the only time we break out of it is when we hit the null terminator (’\0’). The code clang generates checks for the null terminator first, but this makes no sense."
This statement contains huge assumptions about the lengths of the input strings and the frequency of the letters 's' and 'p' in the input. And then has the chutzpah to call the compiler's failure to read his mind about this as "making no sense."
Good first effort by the author, but has not sufficiently thought through the problem.
That's an interesting and legitimate strategy to the scaling problem, but good to know the downsides with the upsides when trying to take lessons from this.
To have something properly function you need both a solid build and maintenance. Doing one well doesn't absolve you of doing the other.
This is about a major expansion of the concept, and includes (1) an insurance scheme so that private landowners can do a burn without fear of bankruptcy and (2) restoring cultural burns that Indians performed to manage land before they were banned by people who didn't understand them.
You are right that you cannot enter the data yourself, as far as I know. But if your lab or physician uses a system that can let you download the records, they will be stored. So I have access to all my blood labs, but there is no easy way to graph them.
As far as I know, there is no App Store rule against making an app that lets you log the variables manually, nor is there a rule against making an app that graphs stuff. Keep in mind that there are a lot of Apple rules around HealthKit data to protect privacy, and writing such an app could be difficult.
A resident is quoted as saying "What was an oasis has become a little island in a dead solar sea" because a single solar facility was built whose edge is three miles away. The facility has a radius of about 1.5 miles.
The Guardian couldn't have interviewed anybody less sympathetic than these guys.
Marketing positioning information does not have a BOM attached.
This is fake. Or at least altered from the real information.
If you ever see the macro NULL in code, be afraid. There are two valid ways of defining the macro and that cause weird issues when porting code. For example, in the statement printf ("%p %s\n", NULL, "Hello world!"), one of the definitions leads to NULL being interpreted as the null pointer, and the other leads to NULL being interpreted as an integer. The latter may crash if integer and pointer are different sizes.
It also causes problems with C++ overloading if one overload takes a pointer and another takes an integer.
Good lock free algorithms use double-width instructions like cmpxchg16b which compare 64-bits but swap 128-bits. You can then use the compared 64-bits as a kind of version number to prevent the a-b-a problem.
Using only the built-in atomics is working with a hand tied behind your back. With the wider version, it's trivial to write multi-producer multi-consumer stacks with no limits to the number of objects stored. It's also pretty easy (if you copy the published algorithm) to do the same with queues.
Never preface your talking point with an obviously wrong statistic.
The law says they can't warn about potential sesame contamination. Instead it must either be an actual ingredient or manufacturers must clean the equipment.
Seems like this fiasco could have been avoided if someone had gone and talked to manufacturers about how big a deal it would be to clean stuff. I'm guessing this isn't a question of a small amount of profit loss; it's probably a big expensive deal to comply with this law.
E.g. Fremont. According to the map, there is a large area north of Sacramento for whom "Fremont" refers to an unpopulated place in Yolo County[1] rather than the city of a quarter million a in the Bay Area. That seems.... unlikely.
[1] Railroad sidings have names and end up in geographic place lists. Looks to me like Wikipedia has filtered out many siding names but not all of them. I suspect this particular "Fremont" is a siding name.
Also the map of low-carbon countries looks a lot like a map of where it rains a lot.