The drying is awful in my Toto, it's not enough air pressure. It'd take 20+ min to dry completely. It's nothing like those hand dryers in public bathrooms.
Round trip business (with a return 6 months later) was 2,530 Swiss francs. So I screenshotted the horrible one-way price to go in my expense report, and then booked the round trip ticket.
No, I was meant to book a one-way ticket, since I was moving offices. But I had to have evidence to show that booking round-trip was cheaper in case anyone questioned why I had purchased round-trip instead of one-way.
Try London to Washington, DC and watch your eyes pop
You might be able to find an airline where it doesn't happen, but you will definitely find airlines where it does. Just verified with Delta and British airways and Lufthansa
US to Europe open jaw can be weird. I've done somewhat crazy return to origin European city (typically Heathrow) to avoid. And then I've had times when it's been perfectly reasonable.
Or it could just be a certain way of framing things?
But for the benefit of this debate I'll state my bias. Almost all my travel is as a group.
But in most other facets of life, we save by buying more, right? (buying wholesale, buying bulk, etc).
So I've actually had the other feeling... if I'm buying 4 tickets at once, can I get a bit of a volume discount? And I'm not sure that's what the airlines are doing here (I don't ascribe any altruism, it's probably more that families were getting cold feet with increasing prices), but I like that I get some kind of cheaper rate when I'm buying 4x of something, just like in just about every other purchase in life.
How about: each user creates an account with their legal ID. Obviously unique so they can’t create multiple using the same ID. Before the sale, everyone signs up. Once the sale is started, tickets are distributed using a lottery system for the users who signed up (so refreshing like mad doesn’t give any advantage). Can only buy up to 2 tickets per person (their own and an anonymous companion). ID must be shown and would be verified at entrance.
If you wanna be even more strict: You could allow up to X companions, but they must not have signed up with their own account (so they don’t have an advantage for doing so). And they must provide their ID before the event as well and arrive as a single party.
This addresses some of the hassle around buying multiple tickets, but does not address the inherent privacy issues. But there are still some problems.
First of all, this remains a hassle in most countries, since handling a national identity number (if such a number exists at all) is restricted by law. Even in some countries that do not legally restrict collection or storage of identity numbers (AFAIK the US does not restrict private sector usage of SSNs), there is rarely wide acceptance of providing your identity number for any purpose other than official government services and financial institutions. This means that in most cases, the event organizer has to resort to more traditional methods of KYC: Requesting some personal details (e.g. full name and birth date) and requiring to present an identity document that carries the details above. Verifying the identity document adds slows down entrance lines and increases the cost.
The other issue with this method is privacy. You're still not breaking the suggested BAP (Bots-resistance/Accessibility/Privacy) theorem suggested by the article. Additional personal information has to be collected and stored until the time of the event.
But I believe there is a way out of this. You can still create a limited resource that is more restricted than phone numbers or credit card numbers, and can be optionally verified at the venue cheaply. The only problem is that would require cooperation from the government (and a great deal of effort if you want to make it perfect). The government needs to already have an online digital KYC method that is bound to your digital ID or an online government account. Then the government can use that method to provide an anonymous federated login that provides a unique ID that cannot be traced back to any national identity number. This is essentially how Sign in with Apple works with "Hide My Email" selected: No personally identifying claims are included in the Open ID Connect ID Token and "sub" is unique (per Apple user + 3rd party service combination), but not traceable back to the the original Apple identity. Unique identities can also become ad-hoc per-event (instead of per ticket provider), which makes them completely private (ticket providers cannot track users across multiple events).
At described above, this service still only provides a limited resource akin to phone numbers. For events where the profit margin from ticket scalping exceeds $100, you could still get some scalpers who'd convince collaborators to identify in with their government account and buy tickets for the scalper for $20 per ticket. If you can get 5 tickets per ID, that's $100 of easy money for 5 minutes of work. You can add simple and fast verification at the venue by requiring the users to generate a QR code that is tied to their unique ID at the venue in order to enter. The QR code cannot be generated in advance and is based on a challenge QR that is presented at the venue. This requires collaborators would have to physically come to the venue or be available at the time the scalper's agents come to redeem the paper tickets at the venue. With a QR code generation and check directly at the gate, scalping is completely impossible (at the cost of longer lines and less entrance flexibility). With printed tickets the scalper needs to send agents to physically collect the tickets and communicate with the collaborators (who need to be available at the day of the event to generate the QR codes remotely) — which greatly inflates the cost of scalping.
Even when you get governments to cooperate with this approach, there are still some holes with this approach. The first issue is that eKYC needs to become popular enough to avoid a large loss in sales. The second issue is raising awareness with regards to privacy-preserving eKYC vs. regular eKYC. This two services look very similar (you log-in with your government account or ID to prove your identity), but the scope of the information shared couldn't be more different. Normalizing eKYC carries the risk of people becoming careless about divulging private information. Luckily, this could easily be solved by governments restricting private sector parties to which full eKYC is provided based on their callback domain names and registered credentials (like OAuth client ID and client secret).
The last problem is the probably the most complex one to tackle: how would you accommodate tourists? After all a lot of the venues sell a large share (or even the majority) of their tickets to tourists. I can think of two possible answers.
The first approach is to fall back to a manual passport-based KYC process for tourists. Tourist ticket buyers would have to enter their name and passport number in advance and the passports would be verified in person at the venue. This can be slightly sped up with automatic passport scanners if the venue has a high volume of visitors that warrants the costs. This approach seems to be where China is going: the resident ID card is used for entrance to many places and even for buying railway tickets, but tourists just use their passports. This works well when the percentage of tourists is low, but at a venue which expects a high number of tourists you'll run into all the issues I've described above.
The other option is probably more of a pipe dream, but it would be nice if countries could issue a temporary (and restricted) eKYC account to visitors when they complete their ETA. Even countries without ETA can still offer a pre-registration system just for obtaining an eKYC account in advance. This eKYC account can be used to purchase tickets in the destination country in advance, but it would only be activated for generating gate QR codes when physically entering the country with the matching passport. The main limitation of this approach is that you must first obtain an ETA before purchasing tickets, but you'd usually already have concrete travel plans by the time you're purchasing the tickets.
Yes but it’s not portable. If zero initialization were the default and you had to opt-in with [[uninitialized]] for each declaration it’d be a lot safer. Unfortunately I don’t think that will happen any time soon.
You probably don't want zero initialization if you can help it.
Ideally, what you want is what Rust and many modern languages do: programs which don't explain what they wanted don't compile, so, when you forget to initialize that won't compile. A Rust programmer can write "Don't initialize this 1024 byte buffer" and get the same (absence of) code but it's a hell of a mouthful - so they won't do it by mistake.
The next best option, which is what C++ 26 will ship, is what they called "Erroneous Behaviour". Under EB it's defined as an error not to initialize something you use but it is also defined what happens so you can't have awful UB problems, typically it's something like the vendor specifies which bit pattern is written to an "unintialized" object and that's the pattern you will observe.
Why not zero? Unfortunately zero is too often a "magic" value in C and C++. It's the Unix root user, it's often an invalid or reserved state for things. So while zero may be faster in some cases, it's usually a bad choice and should be avoided.
> Ideally, what you want is what Rust and many modern languages do: programs which don't explain what they wanted don't compile, so, when you forget to initialize that won't compile.
I think you're confusing things. You're arguing about static code analysis being able to identify uninitialized var reads. All C++ compilers already provide support for flags such as -Wuninitiaized.
Uninitialized variables reads can only sometimes be detected statically. -Wuninitialized is still good, but it will miss a lot of cases when the read is in a different translation unit. Whole program analysis could get more cases, but with large programs (multi-million lines of code) it is unlikely we can analyze everything (everything being more than just variables) before the universe ends - see the halting problem.
> Uninitialized variables reads can only sometimes be detected statically. -Wuninitialized is still good, but it will miss a lot of cases when the read is in a different translation unit.
From my experience, you're exaggerating the number of false negatives, which is more a factor of how you write your code than what static code analyzers do.
Also, your comment reads like an attempt at moving the goal post. We start this discussion being very adamant in accusing C++ of being impossible to detect uninitialized var reads. Once that assertion is thoroughly proven to be false and resulting from clueless ignorance, now we try to reframe it as being... Imperfect in some hypothetical scenarios? So what's supposed to be the actual complain?
The main problem with C++ is that some people somehow are personally invested in criticizing it from a position of complete ignorance. The problem is not technical, it's social.
> You're arguing about static code analysis being able to identify uninitialized var reads.
(Safe) Rust does guarantee to identify uninitialised variable reads, but I believe the point is that you can get the optimisation of not forcing early initialisation in Rust, you just have to be explicit that that's what you want (you use the MaybeUninit type); you're forced to be clear that that's what you meant, not just by forgetting parens.
let mut jim: Goat;
// Potentially much later ...
if some_reason {
jim = make_a_new_goat();
} else {
jim = get_existing_goat();
}
use(jim); // In some way we use that goat now
The compiler can see OK, we eventually initialized this variable before we used it, there's no way we didn't initialize it so that's fine, this compiles.
But, if we screw up and make it unclear whether jim is initialized, probably because in some cases it wouldn't be - that doesn't compile.
This is the usual "avoid early initialization" C++ programmers are often thinking of and it doesn't need MaybeUninit, since it's definitely fine if you're correct, it's just that the C++ compiler is happy (before C++ 26) with just having Undefined Behaviour if you make any mistakes and the Rust compiler will reject that.
[Idiomatically this isn't good Rust, Rust is an expression language so we can just write all that conditional if-else block in the initializer itself and that's nicer, but if you're new to this the above works fine.]
What flag do you have in mind? (To the best of my knowledge, no such flag exists -- unless you're talking about one of the heavily penalized sanitizer modes.)
> To the best of my knowledge, no such flag exists
Your knowledge doesn't seem to even reach the point of having googled the topic. If you googled it once, you'd not be commenting it doesn't exist. Hell, you don't even seem to have read the thread, let alone the discussion.
Something like that is heading into C++26 actually. Except the initialization is not to zero, but to some unspecified value (with explicit intention of not allowing leaking garbage) and allowing to trap. It's called "erroneous values".
You don't care because your job is not to ensure that a new release of C++ doesn't break production code. You gaze at your navel and pretend that's the universe everyone is bound to. But there are others using C++, and using it in production software. Some of them care, and your subjective opinions don't have an impact in everyone else's requirements.
> I only have to work with Clang, personally.
Read Clang's manual and check what compiler flags you need to flip to get that behavior. It's already there.
Lmao. You've misread both of my upthread comments and have somehow arrived at the conclusion that this justifies personal attacks. There's just no discussion to be had here.
Gcc already has [[gnu::uninitialized]] (clang doesn't, AFAIK), as well as -ftrivial-auto-var-init=pattern which exactly matches the new C++26 semantics, if I'm not mistaken
I believe this only helps for trivial automatic variables; not non-trivial automatic variables (structs/classes) that contain uninitialized trivial members.
Ah, you're right, thanks for correcting me! This also doesn't apply to heap-allocated variables, though I think p2795r2 should cover all these cases.
I wonder if (for stack variables) this is due to an implementation detail in the compiler. After all, non-trivial classes have 'actual' constructors that run and that is supposed to initialize their respective class instances...
The difference of course is that almost everyone uses or benefits from the economy of roads. Relatively very few people use trails and they use them for personal enjoyment.
You really can’t think of any ancillary benefits to the presence of accessible nature?
I feel like this sort of comment (from someone with 14k+ “karma” points) is a kind of DoS attack on their self-perceived opponents.
But nonetheless, here’s three benefits for all, regardless of usage:
- reduction in healthcare costs, both physical and mental
- increased tourism
- increased appreciation for environment which in turn loops back into this list from the top
Just focusing on health alone has wide ranging benefits. And if all you care about are tax revenues and GDP, a healthy, happy workforce goes quite a way to improving both.
I’m not going to list anymore because I got other things to do and think about. And this isn’t going to change your mind anyways.
I wonder if the parent to this comment is another "I don't use trails, so no one does!".
If you actually walk along a few trails on a regular cadence, it's clear that there are many different people - it's not just the same people every weekend.
The real difference is that people in cities pay huge amounts of tax to support the roads out to a relatively few houses in the country. Roads are the biggest outlay in every county I’ve lived in.
