It has a (albeit experimental) flag for transforming enums, namespaces and other runtime-impacting aspects of TypeScript, if that’s what you were referring to?
My go to for formatting would be clang-format, and for testing gtest. For more extensive formatting (that involves the compiler) clang-tidy goes a long way
Clang tidy does both: it can run clang's analyzer [0] (also available with clang++ --analyze or the scan-build wrapper script which provides nicer HTML-based output for complex problems found), has it's own lightweight code analysis checks but also has checks that are more about formatting and ensuring idiomatic code than it is about typical static analysis.
MVSC [1] and GCC [2] also have built-in static analyzers available via cl /analyze or g++ -fanalyzer these days.
There is also cppcheck [3], include-what-you-use [4] and a whole bunch more.
Running unit tests with the address sanitizer and UB sanitizer enabled go a long way towards addressing most memory safety bugs. The kind of C++ you write then is a far cry from what the haters complain about with bad old VC6 era C++.
It's "great" mainly in the sense of being very large, and making your code very lage - and slow to build. I would not recommend it unless you absolutely must have some particular feature not existing elsewhere.
Anthony Fu’s epoch versioning scheme (to differentiate breaking change majors from "marketing" majors) could yield easy winners here, at least on the raw version number alone (not the number of sequential versions released):
I don't know if this is the origin, but the semver spec says 0.x.y is unstable. Sure, not everybody uses semver, but it is popular enough for people to make incorrect assumptions.
It's not the origin. Using 0.x for stuff like this was already a thing long before semver. For example, the very first release of Linux in 1991 was v0.01.
I don't know if it's intended (and if so, hat tip to the designer), but the logo is not aligned: the arrows should form an X in negative space, but the horizontal distance between the left & right arrows is smaller than the vertical distance between the top & bottom ones.
“But if they have thermonuclear power, where then do they conduct their tests and detonations?”
“On their own planet, sir.”
Naron rose to his full twenty feet of height and thundered, “On their own planet?”
“Yes, sir.”
Slowly Naron drew out his stylus and passed a line through the latest addition in the smaller book. It was an unprecedented act, but, then, Naron was very wise and could see the inevitable as well as anyone in the galaxy. “Silly asses,” he muttered.
I own a Switch 1, and the other day I wanted to play on the train, but the battery was low. I figured "no problem, I can connect it to my laptop and let it charge off is battery".
Nope. The MacBook Pro started charging off the Switch instead.
I was really excited when I learned that unplugging the cable, waiting some short period of time and plugging it back in, triggers a power-role swap.
I've only tried it out on one occasion, and I'm not clear on the delay, or whether both ends need to be disconnected or only one. I was a little surprised it isn't talked about more.
Is that for a specific device? For standard dual-role USB-C devices they do a negotiation that is partially based on chance which power role they land on (but they can have policy that strongly prefers one role over the other).
Whatever I read made me think it was some sort of standard.
You know more about this than me, so now I think what I stated about unplugging and re-plugging is likely incorrect advice, one step above "turn the cable around" which I think also works enough of the time that people keep trying it and repeating it as a method.
I have this issue with my power bank and my Linux machine. In the end my workaround has to put it in suspend by closing the lid then plugging in the power bank
For two DRP (dual role) devices connected to each other, I believe in a default case the one that happens to advertise as a source first just becomes one.
The standard allows for a role swap at any point while connected, and if that’s triggered will be dependent on the firmware/config on one or both ends.
There’s probably more nuance hiding in the real world hardware too.
They can also prefer one role, with a mechanism called Try.SNK and Try.SRC (‘try sink’ / ‘try source’).
Basically DRPs toggle back and forth between sink and source until they happen to match up (one side has switched to source and one to sink). If it doesn’t prefer to do the role it’s resolved to randomly, it can switch to the other way and wait a bit - if the other side is fine with it then it will switch too and everyone is happy, if not you can switch back.
We use this for a device that can on-charge a device when it has external power plugged in (in which case we prefer source role) but not when running on battery (in which case we prefer sink but don’t actually pull any power because it’s self powered).
> Any DRP port must have pull-down 5k1 resistors on CC wires (as a sink), AND 10-22-56k pull-ups (as provider), but not at the same time. The DRP then alternates the sink advertising (5k1 pull-downs) with pull-ups (source advertising) about 10 to 20 times per second.
> If another DRP is connected, they both will toggle their advertising until a correct (pull-up - pull-down) combination occurs. Then CC controller(s) will stop toggling, and the end that happens to be in provider mode will provide +5VSAFE VBUS. The process will end in one or other direction, which will happen at random (since frequencies of toggling are independent).
It works surprisingly well in practice. The key thing to remember is that you rarely connect identical devices together.
A laptop and a power bank both support both modes, but the laptop will have a "prefer sink" policy and the power bank will have a "prefer source" policy. As long as you don't connect two laptops or two power banks, it'll work out just fine.
Moreover, it has an override mechanism in case you do connect two identical devices. If you do connect two laptops together for data transferring, the OS should be able to let the user override the power flow direction - or even disable charging altogether.
What are the alternatives, for a mass market standard like USB used literally by everything out there nowadays?
Unplug it and plug it again until it works it's easier for everyone that going to some obscure menu (although maybe smartphones/laptop/console could just display a modal "do you want to charge or be charged?")
Usb historically solved this with ended connectors It was why you had "A" and "B" sides. usb C has an awful lot of user hostile fallout considering it's stated goal of "a cable that just works for everything"
I think to solve it, while keeping all the other goals of usb C would be to orient the charging pins on the plug, not charging the direction you want? unplug then flip one side.
Having a plug that works differently based on the orientation it’s plugged in, feels like it would not quite be „keeping all the other goals of USB-C”.
It could default to charging the device with the lowest battery level. Can't find it but I believe having read years ago Apple does something like that.
This happens with one of my powerbanks! If connected to a USB hub as a USB device (not as the power source), it still starts charging my Macbook which is connected to the hub.
https://bsky.app/profile/danielroe.dev/post/3lxczp5apec2x
reply