> Which is really no different from someone choosing to terminate.
If you std::abort(), you'll get a useful stack trace in the core dump. If you crash from an unhandled exception, you don't. That's a pretty huge difference and is one of the reasons exceptions suck.
That's nice but it's certainly not guaranteed by anything, just something provided by your toolchain or platform. ("Core dumps" aren't even a thing in C++.)
If you're looking for implementation-specific guarantees then you could make that happen with exceptions too. I think on GCC replacing a function like __cxa_throw might be sufficient to let you capture a stack trace?
If you're looking for source-level-only guarantees then another option is to just replace your throw <expr> statements with one that attaches whatever extra info you want. You could literally script this to patch your external repos automatically too. Or heck, maybe you could even just define throw to be a macro that shoves your stack trace into some global variable before actually throwing.
Just FYI, finally in C++ you can add a top-level exception handler and call boost::stacktrace::from_current_exception (https://www.boost.org/releases/1.85.0/), and get a stack trace on exit as helpful as in Python or Java.
> If you std::abort(), you'll get a useful stack trace in the core dump. If you crash from an unhandled exception, you don't. That's a pretty huge difference and is one of the reasons exceptions suck.
All of this is up to the implementation in practice. The codebases I work on generally follow the pattern that exceptions may be thrown but may not be caught*, and thus they practically serve as terminate. And we absolutely get stack traces in our core dumps (Linux, both GCC and clang), and basically all of the complex debugging I do starts with a coredump stacktrace.
* We follow this pattern for a few reasons, (1) it is generally safer for us to assume that libraries we consume (STL included) will behave as expected with exceptions enabled, (2) "don't catch exceptions" (or if you must, catch the as close-to-throw as possible) is a simple way to avoid exceptions-for-nonexceptional-cases control flow, and (3) most of the C++ codebase is exposed through bindings in Python, and propagating errors as exceptions is the only Python-friendly way to handle it.
> If you crash from an unhandled exception, you don't.
.. you absolutely get a stack trace from unhandled exception in c++, that starts where the exception is thrown? At least with clang and GCC, maybe MSVC isn't able to.
$ g++ foo.cpp -std=c++23 -g
$ ./a.out
terminate called after throwing an instance of 'std::runtime_error'
what(): boo
$ coredumpctl gdb
...
#7 0x00005555555551bb in bar () at foo.cpp:3
#8 0x00005555555551da in foo () at foo.cpp:4
#9 0x00005555555551e6 in main () at foo.cpp:5
it's a basic example, but it's how I've always done all my debugging in C++ since forever
Sure, in a desktop program you do. In embedded exceptions are a scourge because they crash your program until someone can get back out there to power cycle it. At least with return-codes you can continue execution even if you failed to effect the change you wanted. If that was ancillary to the system’s core function then the system keeps running.
You should carefully examine the evidence you have supporting that belief. Start by observing that this is a partisan issue in which the official positions of the two major parties disagree on a factual claim, not merely the policy. A disagreement on policy can (sometimes) be chalked up to a difference in values, even though those do sometimes arise downstream of factual incorrectness. But a disagreement on facts is one with in which someone is right and someone is wrong. (Or, more complicatedly, someone is closer to accurate and someone is cherry-picking.)
If what you believe to be true is in fact true, then you should be able to comfortably go searching for evidence to falsify it and support the alternative, and fail to find such evidence, confident in your assumption that you won't find it. Either way, I hope that you desire to find the correct answer rather than the one that would be convenient for your political position, and that whatever hypothesis you have has not set itself up to be unfalsifiable.
> you should be able to comfortably go searching for evidence to falsify it and support the alternative, and fail to find such evidence, confident in your assumption that you won't find it.
The system is confidentially designed to provide little to no evidence of the fraud it allows. Even simple signature and ID checking is banned in California.
The system itself is the evidence of the fraud. It is purposefully designed to hide evidence and prevent detection.
You are obviously an intelligent person but you've allowed your curiosity to be subjugated by propaganda.
You are creating an unfalsifiable hypothesis, and not attempting to falsify it.
Why do you believe what you believe? What would be true if it were false? Is that a thinkable alternative? If not, do you really have a hypothesis, or do you have a political belief being presented in the guise of a claim of fact?
The fun part about this is that it depends on facts that nobody actually knows.
If you don't check ID then anyone with a list of registered-but-unlikely voters (or who registers unlikely voters ahead of time without their knowledge) could be voting multiple times and there is nothing to detect it. If you check ID then that doesn't happen as easily, but you still have no way to know if it would have happened in the alternative.
The closest thing to knowing would be if apparent turnout declines in response to checking ID, but a) different elections have different turnout anyway and b) even if you could detect a significant change, one party would then argue that it's a reduction in fraud and the other would argue that checking ID is reducing legitimate turnout, and you still don't know which one it is -- it could even be both.
> they are doing everything they can to ensure that only the people who are legally allowed to vote are the ones voting
Illegal voting is so rare that almost every time folks go looking for it they come up empty handed. Examples of voter suppression, on the other hand, are trivial to fine. (And both parties do it, particularly around primaries.)
In my state, we’re trying to enact a citizenship-proof requirement which penalizes women who change their name on getting married and those who can’t afford a passport. In effect, a marriage and poll tax. Ironically, this will disenfranchise the MAGA voters who are themselves pushing for it, but I’m not really going to point that out aggressively.
(That said, a legitimate fraction of American politics right now is in convincing the other side’s likely voters that elections are rigged, the oligarchs are in charge, why even bother calling your electeds or voting, eat an ice-cream sundae and talk to your AI girlfriend.)
Perhaps so, but you still have to show that it is happening, not merely that it is possible. Moreover, you have to show that whatever cures you propose are both 1/proportional to the harm and 2/minimize undesirable side effects. (One challenge with the latter is that for some people, those side effects are actually desirable.)
It seems less hard if you datamine the shit out of everything, exfiltrate the social security database, and feed it into a computer. Get the historical voting records. SELECT address FROM voters that haven't voted in 10 years. Send someone to follow the mailman and steal ballots from that address. Or simply don't mail them out in the first place. They're not likely to notice to complain in the first place.
Not that I think the election was rigged, but if you think it's "unbelievably hard", I think that's a failure of imagination.
You’re describing an attack that entails both hacking the SSN database, 1 to 50 of the state voter databases, then physically following mailmen around and stealing ballots…
> If someone mails in my absentee ballot and I don’t complain, how do you detect that voter fraud?
You get followed up in an audit, if anyone asks. This happened like three million times in Arizona.
> there are currently many ways to vote illegally that don’t get detected
There are. None of the proposed plans limit them. (No county requires scanning and biometrically verifying passports. You could buy a wrapper on eBay and inkjet the pages in most counties.)
There are also lots of ways to blow up public buildings. We don’t require ID to enter DC because the frequency of the harm isn’t matched by the cost of enforcement.
We already handle all of that, comrade. Every corner case floating around your brain was floating around someone else's brain a long time ago. Most of this is covered in high school in the US, and it's all enforced by volunteers from across the political spectrum.
Our documented examples of voter fraud come from a time when in-person voting was the only option, again something we teach in school, while the modern concerns from security professionals focus almost entirely on electronic voting machines.
Can you describe the specific chain of events required to create a fraudulent vote that is "impossible" to detect?
Surely if you can confidently state the system not only is this way, but is purposely designed this way, you should have zero problem describing it exactly step by step.
Extra credit if you can describe a method that can produce 10, 100, or 1000 votes.
Okay so in this scenario, if this woman wanted to actually vote on behalf of these people, all she had to do was pay a bunch of people to register with her address, get 10, 30, 100, or 1000 ballots mailed to her address, then fill out all of those ballots and mail them in and hope no one noticed dozens or hundreds or thousands of ballots coming from an address that would clearly and directly implicate the person who lives at/otherwise controls that address?
And the trade off here is this person gets 10, 30, 100, or 1000 votes in a single county and at the minuscule risk of the rest of her life in prison?
(To be clear, this isn’t what DOJ is alleging, they alleged she was just collecting petition signatures, but I’m extrapolating out your proposed mechanism for actual voting)
>hope no one noticed dozens or hundreds or thousands of ballots coming from an address
So what? If it was illegal to register multiple voters at the same address then it could have been detected at the registration time.
>And the trade off here is this person gets 10, 30, 100, or 1000 votes in a single county and at the minuscule risk of the rest of her life in prison?
Did not you notice that this person has not been charged with voting with other people ballots (even though she was able and most likely did that) and only with paying to register? Such a charge would be very hard to stick.
> Did not you notice that this person has not been charged with voting with other people ballots (even though she was able and most likely did that) and only with paying to register? Such a charge would be very hard to stick.
Huh? There is literally no evidence or even allegation of that. The person was paid to collect petition signatures, so she fraudulently obtained petition signatures. Which obviously are way less closely tracked than actual votes.
> So what? If it was illegal to register multiple voters at the same address then it could have been detected at the registration time.
Well it's not illegal to register multiple voters at the same address, obviously. It's illegal to vote under someone else's name. A bunch of votes coming in from a single residence would be flagged. Should voter registrations from a single address get flagged? Sure! And they probably do! But as you say, that's not a crime. Voting fraudulently is, which is not even alleged here.
Not sure what you are doing now. You asked for a scheme, you got it and now are appearing to be saying that such a scheme would not work because people would get busted even though you admit yourself there would not be any evidence.
> Can you describe the specific chain of events required to create a fraudulent vote that is "impossible" to detect?
You literally just described a scheme that is possible to detect in any meaningful amount. 10, 100, or 1000 ballots coming from a single address is, obviously, trivially detectable.
I see. It's possible to detect the scheme per se even though the detection would not lead to charges (ballots from the people registered at the same address are completely legal) and thus would not be conducted. The point your correspondent has initially made: it's impossible to detect illegal voting in such a scheme.
Virtually every type of fraud is first detected by detection of a nominally legal but abnormal behavior, then it's investigated to figure out whether fraud actually occurred. That would – obviously – be exactly how any voter fraud detection scheme works, but I guess you're saying that because the initially detected abnormality is not itself illegal, it wouldn't be investigated?
This is like saying "it's not illegal for all the numbers on your tax return to end in $xxxx.00 and $xxxx.50, so therefore tax fraud is undetectable by means of analyzing numerical patterns."
Here's how it's detected: "There are 1000 ballots from this one address that has never had more than 3 ballots sent from it. We should look it up in our GIS and tax records and see how many people reside there. We should also make sure that the affiliated registrations are fully documented as having individual residencies there from e.g. their drivers licenses or utility bills at time of registration."
Sorry but you are naive beyond words if you think voting systems don't flag even a dozen ballots sent to a single residential address, or you don't think there's any investigative capability to look further into flagged cases.
Which do you believe? There are only three options:
1. You believe that 1000 ballots sent to a single address will not be flagged
2. You believe that it would be flagged but not investigated
3. You believe it would be flagged and investigated, but not actually result in any prosecutable offense
"Sorry but you are naive beyond words" that made me actually chuckle, coming from you. I am really done with your fantasies, you obviously have no clue how voting registration works (you are not required to live at your registered address for example) and what "checks" are in place yet imagined yourself an authority on the subject. It's so ignorant that makes me think you have not voted in the US and project your home country system.
Talk about projection, lmfao! Not even here long enough to prevent your weird writing quirks from revealing that you're a foreigner, and yet comfortable implying some strange nationalist superiority to a native-born American. Beyond parody.
Are people from your country unable to answer simple multiple-choice questions like "which of these three options do you believe?"
Lmfao you think naturalizing makes you no longer a foreigner?
How is it that you're immediately detectable as not-American on a messaging board then?
Hint: It's the low-trust third-worlder attitude, which unfortunately the legal process of naturalization doesn't always solve.
Hilariously, your allegation of me being a foreigner was the nail in the coffin, as any actual American would know they can have disagreements on stuff like this without accusing the other of being a foreigner. But, being what... Russian? Georgian? Israeli? Obviously everything must be infused with an (unearned) nationalistic superiority haha.
> Sure, both languages offer both generic comparison sorts†. But the defaults matter and as always in C++ the defaults are wrong, here it's reflected in naming.
Why, exactly, is the c++ std::sort "wrong"? There are tradeoffs both ways. You happen to prefer stable sorting to speed, but that is a preference not an objective fact.
It's silently an unstable sort, which is surprising, and then to add insult to injury it's also slower. Yeah, I know, the C++ unstable sort is so slow it's slower than Rust's stable sort.
YMMV for input types, sizes etc but generally that's what the numbers look like and though it's not universal it's actually quite common. "I bet the C++ is faster" is the wrong instinct, sometimes by a large margin.
And stable sorting typically allocates large amounts of memory, which is also an unpleasant surprise.
I prefer the C++ naming convention, because it matches my expectations. When I studied CS, quicksort was considered the default sorting algorithm, and stable sorting was therefore a special case.
My pet peeve is that standard library sorting algorithms are still mostly single-threaded. Multicore CPUs have been the norm for ~20 years, but standard libraries still don't offer reasonable algorithms for sorting large arrays.
No? One of the giveaways of how unserious such responses are is that I spent many years getting paid to write C. The home where I'm writing this was bought† with money made writing C years ago. Rust wasn't even a twinkle in Graydon's eye when I started that job, let alone when I first wrote C last century.
The choice to provide the unstable sort and then add a stable sort as an afterthought smells of the New Jersey approach to me. It was easier to do this, and too bad for the users, they weren't the priority.
It's the wrong choice because if you don't know about sort stability this outcome is surprising, so this means that although a beginner probably thinks they know what "sorting" means they actually mustn't use the sorting APIs in such a language until they've learned extra material.
† For cash, I don't like to owe people money, including having a mortgage
It's not so simple that you can just declare what is surprising. Surprise depends on context, and not everyone will have the same context as you. You say you would expect the term 'sort' to mean a stable sort, and I would expect it to always mean in-place sorting, others may expect it to use the absolute fastest way to get something sorted... Different users will have different priorities and therefore expectations.
Sort stability does not matter when the sorting key is the only thing in your data being sorted. E.g. When I sort my M&Ms by color, I never keep them in the same order, because it doesn't matter. A red M&M is a red M&M. Nobody expects their red M&Ms to remain in the same order after sorting. I do tend to expect my M&M sorting to happen in-place. I expect to not need to provide additional candy holding bowls to later clean up that were used for temporary storage while my M&Ms were getting sorted. But I'll optionally grab additional bowls when I'm in a time crunch it if it speeds things up...
Now, if we're sorting all the cars on a parking lot by color, it may be more important to keep all the red cars in the same order where they started, for example if they were previously already sorted by brand, it /can/ be useful if that is preserved. But it's not guaranteed to be important or useful. Maybe the rich owner just want to torch all their red cars all together. I typically won't have access to additional temporary parking lots only used during sorting, or maybe the owner is coming with a flame thrower at 1PM and it has to be done as fast as possible whatever the cost. There is a tradeoff, rent additional parking lots during sorting, or take more time and do in-place stable sorting, or jumble up the car brands.
So what I want is control. That's all. Whether or not the ambiguous term 'sort' is stable or unstable, or in-place or not is just semantics. The only way to get clarity is to either use prior agreement, or to not use ambiguous names. Maybe a language should ban 'sort', and only allow 'foo_sort_bar' names with stability of memory usage postfixes or prefixes to 'inform' the developer. Neither choice is ideal and will satisfy everyone. It's like being a DJ at a high school party.
I'm not saying that the STL is great in practice, since it appears to optimize for usage flexibility with defined algorithmic and memory complexity at the big-O level, and mostly disregards actual real-life metrics. Arguing, however, that a language or library is better because an objectively ambiguous choice was made differently than your expectations is like arguing for fundamental superiority of either endianness over the other.
> It's not so simple that you can just declare what is surprising.
On the contrary, of course I can tell you that I was surprised and I'm far from alone. The fact you immediately grasped for "real world" comparisons ought to tell you that you're not thinking about this correctly because these are software sorts and so have very different affordances than the real world.
The claim that you wanted control doesn't make sense in the context of C++. There are in place stable sorts - the bubble sort you may have seen in class years ago is one, but C++ doesn't promise one in its standard library. However it does provide an unstable sort, which it just names "sort" and that's what I'm pointing at as a problem.
As to the "absolute fastest" you're in the wrong place if you've used a generic comparison sort expecting the "absolute fastest". For the machine integers it's usually not even the correct category of sort for "absolute fastest". But the C++ standard library is the wrong place to look even if you did need a generic comparison sort, because so much crap C++ exists and maintainers are scared to change anything for fear of what may happen.
Did you know libc++ didn't even have a guaranteed O(N log N) sort until the Joe Biden presidency? The introsort paper was written last century and the C++ standard itself did finally incorporate this basic requirement in 2011, but it took another decade for the Clang team to fix this.
Ok, I'll keep it short: I'm far from alone being surprised that a sort allocates temporary memory...
C++ is used by a lot of different people with a lot of different background, and... expectations...
My point is that "sort" is ambiguous and having expectations on ambiguity and arguing that a certain one is better is like arguing little endian being better or worse than bit endian.
> Ok, I'll keep it short: I'm far from alone being surprised that a sort allocates temporary memory...
In a sense I'm sure this is true. C++ programmers routinely report being astonished about all sorts of properties of the language they have previously insisted they know well and who could blame them (for the former, at least).
Again, this is not symmetrical. LE and BE are symmetrical, if you have to pick one there isn't a "safe default" that isn't surprising to people who expected the other one†. In contrast sort stability isn't like that, all stable sorts also meet the criteria for an unstable sort. Likewise all the in-place sorts meet the criteria for an allocating sort.
C++ chooses to offer an unstable sort just named "sort". It doesn't offer a stable in place sort at all, but it does offer a stable allocating sort and names that stable_sort
† But what you can do is where it matters you explicitly offer the LE and BE options and silently whichever is native on your target is fast. Users can write whichever they meant and their program works rather than "Oops, by default on this platform it's the opposite byte order, there's a special conversion function to run". Needless to say C++ doesn't do this either.
You are failing to make an argument for why stable sorting is objectively the correct choice. Just because something doesn't match your expectations doesn't make it wrong.
There isn't a symmetry here. If you know about sort stability then you can seek out the unstable sort if you know that works for your purpose, if you do not know about sort stability then the unstable sort's behaviour would be astonishing, so stability by default is the right choice.
I work in a FAANG. My sense is that most of my teammates are loving the AI. Personally, I hate the AI tools and the hype around them and what it has turned this job into. My own morale has never been lower in the 7 years I've been there and I'll probably try to switch careers or semi retire sooner or later.
I have also considered switching careers, but my employer is not really enthusiastic about AI, so I am trying to hold out for as long as I can. As in, my employer does not pay for nor use any AI at all.
I feel like the economic value of talent is about to be in an interesting position sometime in the not so distant future. Perhaps talented engineers use AI is a more talented manner, but I am not sure that is entirely true nor will it remain that way forever.
We should not treat this as an acceptable strategy. If we do not have a viable mitigation for the risks of AI, then AI should be banned from public usage, just like nuclear weapons.
Well, unless political candidates and the general public suddenly gain 30 IQ points and become more collaborative than at any point in history, it's the best we have.
The fact that we don't already measure/enforce outcomes for legislative actions should tell you everything you need to know.
Context: I work in robotics. We use mostly c++ and python. The entire team is about 200 though the subset I regularly interact with is maybe 50.
I basically don't use AI for coding at all. When I have tried it, it's just half working garbage and trying to describe what I want in natural language is just miserable. It feels like trying to communicate via smoke signals.
I'll be a classical engineer until they fire me and then go do something else. So far, that's working. We've had multiple rounds of large layoffs in the last year and somehow I'm still here.
If you std::abort(), you'll get a useful stack trace in the core dump. If you crash from an unhandled exception, you don't. That's a pretty huge difference and is one of the reasons exceptions suck.
reply