There are tons of explanations. If you want a fancy one: depending on whether you type 23 on the numeric row with your left hand or on the numeric keypad with your right hand, the finger order is reversed.
why should it be a problem? in the UK, methadone is normally dispensed from a regular pharmacy, just like any other prescription you might get from your doctor. I wonder if what you are seeing is that the clinic has been placed in a neighbourhood that already had high crime/homelessness/etc. since that is where the addicts who need its services are? it just seems odd that a clinic would be placed in an affluent area, where property costs are probably high, and the service users have to travel to get there, but maybe it's an american thing?
I agree that it's consistent, I find it easier to read when the branching condition is front and center. In 99% of cases I've encountered, the scope of the branching condition variable doesn't matter. When it does, an extra set of {} defines a scope clearly.
That plus extra indentation. It also obscures the intent since it's not necessarily unambiguous why those braces are there? Is it just to group logically related code (without putting it in a separate method/function) or is it because you're relying on RAII -- it's only possible to tell by searching for destructors on all the classes you're instantiating.
It was submitted for PDTS (proposed draft technical standard), which means it goes out for balloting to ISO national bodies. That balloting either succeeds (at which point you have a Techincal Specification) or it comes back to the committee with comments that the committee then has to respond to (and then another round of balloting happens). Once it's accepted as a Technical Specification, it's still not part of the C++ International Standard. That's a decision the committee comes to at their own pace, much like what happened at this meeting where the Concepts TS was accepted (as amended) into the IS.
Think of a TS somewhat like a beta. There's no assurance that the contents of the TS will go into the IS at all or in the exact form it was originally specified in, but that's certainly the hope when the TS is published.
Yes and no. Many compilers support #pragma once, but whether your build environment handles it is another matter. Having your headers on network drives, or having symlinks to your headers, etc can cause issues with #pragma once handling (depending on the implementation) that can often be hard to track down, especially if building with multiple compilers. Include header guards do not have these issues.
This detects differing structure layouts between compilation units which is simple to do given some metadata in the object files. On the other hand it also shows why detecting ODR violations for executable code is non-trivial, because same source code compiled with different compiler flags can lead to different output that might or might not be compatible (enforcing same compiler configuration for all compilation units is certainly non-starter, think JS runtime vs. FFmpeg, 3D renderer vs. physics simulation...).
