> One caveat though - using a normal std Mutex within an async environment is an antipattern and should not be done - you can cause all sorts of issues & I believe even deadlock your entire code.
True. I used std::mutex with tokio and after a few days my API would not respond unless I restarted the container. I was under the impression that if it compiles, it's gonna just work (fearless concurrency) which is usually the case.
> So this mode needs to set user expectations appropriately: your code breaking between compiler releases is a feature, not a bug.
Good luck. I feel that the C++ community values backward compatibility way too much for this to succeed. Most package maintainers are not going to like it a bit.
There has been plenty of breakage throughout ISO revisions.
The biggest problem is ABI, in theory that isn't something that standard cares about, in practice all compiler vendors do, thus proposals that break ABI from existing binary libraries tend to be an issue.
Another issue is that WG21 nowadays is full of people without compiler experience, willing to push through their proposals, even without implementations, which then compiler vendors are supposed to suck it up and implement them somehow.
After around C++14 time, it became cool to join WG21 and now the process is completely broken, there are more than 200 members.
There is no guidance on an overall vision per se, everyone gets to submit their pet proposal, and then needs to champion it.
Most of these folks aren't that keen into security, hence the kind of baby steps that have been happening.
Compilers at least allow specifying the standard to target, which solves the ISO revision issue. But breaking within the same -std=... setting is quite a bit more annoying, forcing either indefinite patching on otherwise-complete functional codebases, or keeping potentially every compiler version on your system, both of which are pretty terrible options.
Breaking within the same std, is something impossible to prevent in compiled languages with enough freedom in build.
Even the C ABI many talk about, most of them don't have any idea of what they are actually talking about.
First of all, it is the OS ABI, in operating systems that happened to be written in C.
Secondly, even C binary libraries have plenty of breakage opportunities within the same std, and compiler.
ABI stability even in languages that kind of promise it, is in reality an half promise.
Bytecode, or some part of the language is guaranteed to be stable, while being tied to a specific version, not all build flags fall under the promise, and not much is promised over the standard library.
Even other good examples that go to great efforts like Java, .NET or Swift, aren't fully ABI safe.
> First of all, it is the OS ABI, in operating systems that happened to be written in C.
It may be per-OS (I wouldn't try linking Linux and NT object files even if they were both compiled from C by GCC with matching versions and everything), but enough details come from C that I think it's fair to call it a C ABI. Like, I can write unix software in pascal, but in order to write to stdout that code is gonna have to convert pascal strings into C strings. OTOH, pascal binaries using pascal libraries can use pascal semantics even on an OS that uses C ABIs.
Try to link two binary libraries in Linux, both compiled with GCC, while not using exactly the same compiler flags, or the same data padding, for example things like structures.
Since committee people can explain it even better,
Sorry, this is nonsense. Binaries link just fine on Linux. If you use a compiler flag that changes the ABI, then you are on your own, of course, but the GCC docu makes it very clear which specific flags those are. There is some corner cases with problems where you get problems if you use different compilers, e.g. atomic alignment (by adopting the broken C++ design into C) and some other corner cases where compilers did things slightly different.
Things like this resulting in differnt alignment between Clang and GCC on x86_64 for _Atomic struct { char a[3]; }; See: https://godbolt.org/z/v5hsjhzj9
The problem is that in C++ these atomics are library types, but in C they are built-in types which should have a clearly specified ABI. But the goal was to make them compatibility with C++ library types, which is a rather stupid idea, which pulls in even more problems.
It's certainly not impossible to write code that breaks, or modify a library in an ABI-incompatible way, but ABI stability, at least on Linux, does largely Just Work™. A missing older shared library can be quite problematic, but that's largely it.
And while, yes, there are times where ABIs are broken, compiler versions affecting things would add a whole another uncontrollable axis on top of that. I would quite like to avoid a world of "this library can only be used by code compiled with clang-25" as much as possible.
Can't solve the issue of "you just don't have the library (or a specific version thereof) installed".
But you can make it worse by changing "You must have version X of library Y installed" to "You must have version X of library Y compiled by compiler Z installed".
As-is, one can reasonably achieve ABI stability for their C library if they want to; really all it takes is "don't modify exposed types or signatures of exposed functions" and "don't use intmax_t", and currently you can actually break the latter.
Release vs debug shouldn't affect ABI (or, at least, the library author can decide whether it does; all it takes is.. not having `#if DEBUG` in your exposed header files changing types or function signatures).
Multi-threading doesn't affect ABI in any way at all.
fast-math doesn't affect ABI (maybe you mean the setting of FTZ/DAZ? but modern clang & gcc don't do that either, and anyway that breaks everything float in general, ABI itself is one of the few float things that don't immediately break, really).
Presence or absence of SIMD extensions, hard-float, or indeed any other form of extension, also doesn't modify the ABI by itself.
There's a separate -mabi=... that controls hard-float & co, but generally people don't touch that, and those that do, well, have a clear indication of "abi" in "-mabi" that tells them that they're touching something about ABI. (SIMD does have some asterisks on passing around SIMD types, but gcc does give a -Wpsabi warning when using a natively-unsupported SIMD type in a function signature; and this affects only very specialized low-level libraries, and said functions should be marked via an attribute to assume the presence of the necessary intended extension anyway, and probably are header-only and thus unaffected in the first place)
That said, it would probably make sense to have a way to configure -mabi at the function level (if this doesn't already exist).
General CPU ISA is one thing that does inescapably affect ABI of compiled programs; but you can have a stable ABI within one ISA. But yes, there's the wider requirement of "You must have version X of library Y for ISA W installed", but yet "You must have version X of library Y for ISA W compiled by compiler Z installed" is still worse.
I'm of course not saying that C has a single universal ABI. But for any single platform (OS+ISA) where it is possible and meaningful to have shared libraries in the first place, there's a pretty clear single ABI to follow, so the distinction is, for practical purposes, completely meaningless. (ok windows does have some mess, but that's windows for you, it'll achieve a mess in anything)
Still have no clue what you mean by threading; sure, threads exist, even officially so in C11, but still just in completely no way whatsoever affect ABI any more than any other part of the standard library, i.e. "as stable as the stdlib impl is".
This is honestly what pisses me off about the whole ABI thing. The ABI is defined by the OS, not the compiler. The compiler just implements the ABI, but somehow everyone lets their OS be defined by what a particular C/C++ implementation does. This then leads to FFI realistically only being possible by using a C/C++ compiler for interfacing, which defeats the point of an OS wide ABI.
Maybe some things could be translated by a linker, but a linker can't change the size/layout of an in-memory data structure, and there's no info on what to translate from, even if info was added on what to translate to, anyway.
My favourite weird ABI choice is: Who does what for a barrier? The barrier needs one party to do work for a full fence, but which party that should be doesn't matter... There can be an x86 FENCE over on the store side, or we can put the x86 FENCE on the load. We could do both but that's pointless, so don't do that. However if we do neither we haven't built a barrier and now there's probably a horrible bug.
I'm kind of with you on the coding-style warning flags. it does really bother me that some opinionated person has decided that the way I use parenthesis needs to be punished.
but I totally disagree with your second point. running code often has real problems with race conditions, error handling, unwanted memory reuse, out of bounds pointers, etc. if a new version of the compiler can prove these things for me - that's invaluable.
Those machines unlocked more work, different work, that led to better paying jobs!
I am all up for AI if it leads to "better" work and jobs but cutting jobs to cut cost sound like a race to bottom!!
Are AI time
/cost savings going to help me pursue creative hobbies, open source, help my community without worrying about livelihood then great. If it is a means to make rich people richer by making most of us worse off, maybe we should stop and think for a while?
There may be a risk here that a zero/negative-sum game is advertised as a positive-sum game (e.g war).
freerouting plugin is available as a standalone program. It's pretty good. You export DSN from kicad and use freerouting. Not as simple as button click though.
> Egyptians don't like the notion that "they moved there from somewhere". They claim their own unique, uninterrupted, history and connection to the land as well as their civilizational independence from Mesopotamian, Asia Minor, Europe, and Africa.
Same here in India.
These ideas about civilization and racial purity/superiority are a scientific nonsense but very useful for getting people to hate each other.
Chinese mythology says they came from 崑崙 (Kunlun Mountain). The description of which sounds like Egypt coincidentally.
Translated something like: “To the south of the Western Sea, along the banks of the Flowing Sands, beyond the Red Water and before the Black Water, there lies a great mountain called the Kunlun Hill.”
The idea must have had some currency in the middle of last century, since Tolkien decided to place Hildórien, the birthplace of the Edain, in the Far East.
Human populations almost never sat still in one place and avoided mixing with others. Go back far enough, and Europeans and Indians are related. Go back further, and they're both related to Native North Americans. Go back far enough and we're all related. Anyone making claims that their ethnic group is somehow "pure" is ignoring linguistics, genetics, archaeology, and basic human nature.
We move around. We meet people. We make new people.
“Pure” usually means having genes from a narrow, selected group, so the offspring show predictable traits—like size, intelligence, or appearance. That’s why dogs and farm animals are called “purebred.” But making pure breeds often requires inbreeding, which, unless done carefully, can cause serious problems.
“LET’S SET THE EXISTENCE-OF-GOD ISSUE ASIDE FOR A later volume, and just stipulate that in some way, self-replicating organisms came into existence on this planet and immediately began trying to get rid of each other, either by spamming their environments with rough copies of themselves, or by more direct means which hardly need to be belabored.” Cryptonomicon. Page 24.
Populations can be homogenous though. If a hundred random humans were placed on an island to breed for 100 generations, they might homogenize into a distinct "type" and maybe that's something worth preserving or being proud of.
It's interesting that in Judaism, it's the opposite. Always moving in and then forcibly moved out. Abraham came from Ur (Mesopotamia), then Exodus from Egypt into Canaan, then Babylonian exile and back to Judea.
In myth-making, you've got to work with the established facts on the ground. It makes sense for China, India and Egypt to perpetuate the "always been here" mythology, but obviously for Jews being forcibly moved around and discriminated against is a given, so you build around that.
Look up the Harrapan Continuity Hypothesis. Very few scholars in India take it seriously but somehow it still finds its way into high school textbooks.
Spoken by the Athenians and resulting in a war that, as Thucydides's audience knew quite well, Athens lost big-time.
Which actually holds up quite well for everybody who loves to bring up that quote: realism aka "we shouldn't face the consequences of our actions" is the obvious rallying cry for people facing the consequences of their actions.
If neither side can agree on peace, if neither side has objectives which the other will accept, if neither side is willing to compromise; What other outcome is possible in terms of realpolitik?
It is upsetting to observe. We all want better for humanity.
There have been cases in the past where an external strong power has been able to suppress both sides but it has to be done for generations until the reasons are lost to time.
Depending on who you ask, there have been a variety of external powers stirring the pot. Most people are horrified by the violence. Beyond the territorial, religious and cultural disputes there are opposing geopolitical factions.
Of course it is understandable to be outraged by the violence and atrocities. The human suffering is real, but arguments focusing on these points can miss the larger picture. The underlying incentives dictate outcomes. Atrocities are often marketed as rationalizations for further violence.
We want to prescribe an outcome without atrocities. Yet discussions fall into recrimination before they can describe the conflict coherently.
Same here. I learnt about convergence, Cauchy seq etc. it was published by a local non profit publisher -- Hindustan Book Agency so it was super affordable too.
True. I used std::mutex with tokio and after a few days my API would not respond unless I restarted the container. I was under the impression that if it compiles, it's gonna just work (fearless concurrency) which is usually the case.