I was hoping that this would talk more about the logic behind generating a diff, rather than the optimisations involved in rendering the text.
IMO (as someone who doesn't have to deal with the actual rendering) it would go a bit deeper into talking about deciding how to show what has changed. There's a lot of improvements that could be made there. e.g. "whitespace has changed here" so there's no real code changes involved.
Or "this big list of imports has changed, and code formatting has line-wrapped the list into different lines" - gitlab for example copes poorly with this. I'd love to just see a clean diff that highlights the additional import, and not just ten lines of changes caused by adding one line to a big list of imported symbols/functions.
But almost all social networks and search engines won’t let you advertise without a license from the required jurisdiction.
Which is a good thing! This is an area full of scammers, if you can't set up your business legally, I'm very happy to hear it's more difficult for you to advertise it.
It's really annoying. I have a sudoku game on my phone, works great but give it internet access and it's suddenly full of sketchy adverts.
If I'm playing it on my commute, it's usable with mobile data disabled for the app. But when the train stops in a station long enough to auto-connect to wifi, immediate full screen adverts :(
because of OS-level overcommit, which is nearly always a good thing
It doesn't matter about the language you are writing in, because your OS can tell you that the allocation succeeded, but when you come to use it, only then do you find out that the memory isn't there.
Oxbridge have never had to 'let in dumber people'. They are always heavily over-subscribed, and give offers to a small fraction of the people who come for an interview, let alone apply.
The whole point of the interview process is to assess not just the applicant's past achievements, but what they might be able to achieve if they got their place at the uni. Part of that is looking at the applicant's background, and knowing that even if they aren't currently at some elite high-fee school, they might still have the ability and capability to do well.
I am all in favor of this style of selection. The dark old days of "this kid's dad went to our college, we should do them a favour and let them in" are long gone, thankfully.
Can you point to any kind of evidence that Oxbridge are dumbing down their teaching, or lowering their standards of teaching? I doubt it.
Full disclosure: cambridge alumni, from a state school!
Improvement suggestion: Keep the search text in the search field when you show the results. The 'what are you looking for' box gets cleared when you show the results, it would be nicer if the search text was kept so that you could tweak it.
Does that mean it excludes most of the results from "Floor to ceiling libraries without a ladder"?
You know, if I'm buying a house, I think I can supply my own ladder separately...
Less pedantically, what I'm trying to say is: are you really sure these are the kinds of searches that home buyers are really looking for? "Home in london, under £1m, with big beautiful windows" - I suspect that most London buyers are going to care an awful lot about where in London the house is, a city-wide search isn't going to be useful to most. Maybe your functionality (as presented) won't inspire actual buyers.
Speaking of which, that might be a way to improve it - combine with location & mapping data to figure out nearby transport, services, schools, etc...
But it is (or was originally) used in lots of places, not just jump tables, generally to do relative addressing, for example when you want to refer to data nearby, e.g.
Yeah, it was that way for all previous ARM processors too, for exactly that reason. Adding special cases would have increased the transistor count, for no great benefit.
The only downside was that it exposed internal details of the pipelining IIRC. In the ARM2, a read of the PC would give the current instruction's location + 8, rather than its actual location, because by the time the instruction 'took place' the PC had moved on. So if/when you change the pipelining for future processors, you either make older code break, or have to special case the current behaviour of returning +8.
Anyway, I don't like their reaction. What they mean is 'this decision makes writing an emulator more tricky' but the author decides that this makes the chip designers stupid. If the author's reaction to problems is 'the chip designers were stupid and wrong, I'll write a blog post insulting them' then the problem is with the author.
Is this really C++ specific though? It seems like the optimisations are happening on a lower level, and so would 'infect' other languages too.
Whatever the language, at some point in performance tweaking you will end up having to look at the assembly produced by your compiler, and discovering all kinds of surprises.
Your comment boils down to 'all code should be perfect'. Which is a lovely request, but doesn't really help.
In particular, I'd challenge you to find one large program that handles OOM situations 100% correctly, especially since most code runs atop an OS configured to over-allocate memory. But even if it wasn't, I doubt there's any sizeable codebase that handles every memory allocation failure correctly and gracefully.
I've not seen a very convincing use-case for ETags vs Last-Modified date caching.
In the example request, the server still has to do all of the work generating the page, in order to calculate the ETag and then determine whether or not the page has changed. In most situations, it's simpler to have timestamps to compare against, because that gives the server a faster way to spot unmodified data.
e.g. you get a HTTP request for some data that you know is sourced from a particular file, or a DB table. If the client sends a If-Modified-Since (or whatever the header name is), you have a good chance to be able to check the modified time of the data source before doing any complicated data processing, and are able to send back a not modified response sooner.
Thousands of words written about how, specifically, gcc produces poor slow code ('the application users' time is more valuable than their time') and yet the article never tries to measure how slow or fast any of their examples are.
I mean, maybe it is true that gcc is bad, maybe it isn't, but complaining that a function takes 27 bytes and it could have been written in 25 is missing the point entirely when you are asking for speed. Does it run fast or not?
IMO (as someone who doesn't have to deal with the actual rendering) it would go a bit deeper into talking about deciding how to show what has changed. There's a lot of improvements that could be made there. e.g. "whitespace has changed here" so there's no real code changes involved.
Or "this big list of imports has changed, and code formatting has line-wrapped the list into different lines" - gitlab for example copes poorly with this. I'd love to just see a clean diff that highlights the additional import, and not just ten lines of changes caused by adding one line to a big list of imported symbols/functions.