Yep, for types that's a new operator. It is also a binary operator for xor, for values. But no unary use from what I remember.They call it "reflection operator" in the paper.
It was previously used by Microsoft for their C++/CLR (or C++/CLI) to mark garbage collected values. But that was after the type, not in front iirc.
Having some form of coroutines or green threads seems like a good idea to me for something low-level.
Otherwise countless projects that need something like it will re-implent their own incompable version with longjmp or similar means.
Why is it combining back-tick with the previous letter in a ligature with almost all letters? Into a single character wide element it seems.
So looking at a Markdown file with "a`" will print it as "à" always even with letters like "t" or "Y".
Not just that, why is the backtick unconditionally combining with the previous letter? If you type "a`" it will always print "à" for me, even combining with letters like "t", seems like a ligature table bug or something.
Just randomly saw that when looking at a markdown file
Fully agree with #embed. I don't really need the feature often enough to justify it. But it feels fine to use the preprocessor for it. It's annoying enough for the people who need it to have some build-system work-around, so just some simple straight forward implementation seems better than some over-specified solution for every possible use-case (imagine the horror of some template construct with locales/encoding specification added to it).
Also, even if C keeps diverging from C++ having these basic constructs stay compatible is worth quite a lot imho.
One problem is that C++ wants to (eventually, at least as an ambition) deprecate the pre-processor. So it's embarrassing to add features which people need to this system which you claim you're deprecating. Which is it?
I think C++ would have been better off with a closer equivalent to include_bytes! (Rust's compiler intrinsic masquerading as a macro, which gives back an immutable reference to an array with your data in it) - but the C++ language doesn't really have a way to easily do that, and you can imagine wrestling with a mechanism to do that might miss C++ 26, which is really embarrassing when this is a feature your language ought to have had from the outset. So settling on #embed for C++ 26 means it's done.
I was concerned that maybe include_bytes! prevents the compiler from realising it doesn't need this data at runtime (e.g. you include_bytes! some data but just to calculate a compile time constant checksum from it) but nope, the compiler can see it doesn't need the array at runtime and remove it from the final binary just as a C++ compiler would with #embed.
> having these basic constructs stay compatible is worth quite a lot
Also, I think C++ can still use the same preprocessor as C at this point (it's been a while since I've had to deal with that)? If you're going to diverge the preprocessor you should get more benefit out of doing so than "not having #embed". For that matter, having important features like #embed only available via preprocessor also helps undermine the pointy-haired trolls who (allegedly?) keep trying to deprecate the preprocessor entirely in favor of some proprietary build system.
you need to "install" the PWA first.
So how's this different from regular desktop applications in regards to phishing specifically?
Do you mean an app presenting pre-"install" as something and then post-"install" as something else?
I'm having a hard time seeing a lot of difference. Most windows you want to "spoof" will look different in regards to the title bar either way.
In a regular browser window you'll have the browser title bar. In the PWA case you'll have the extra hamburger menu.
The metroidvania inspirations are pretty clear, it's a large map that you unlock gradually by finding abilities on the map. Including some back-tracking.
What do you think is missing for it to be called a metroidvania?
The graphics and scenery. It's 13 kilobytes of JavaScript with no bitmapped graphics in it, I know, but if we settle for (as an example) your two very broad strokes of running back and forth and unlocking new areas then hundreds of old NES and SNES games have suddenly become Metroidvania, despite nobody ever branding them as Metroidvania.
I don't mean to come off as a retro-gaming connoisseur, but there's a certain feel and atmosphere to the Metroidvania branding - it's more than a sub-genre - and it shouldn't be taken lightly.
I'd say that, particularly in modern genre terms, "Metroidvania" refers to a game involving gathering abilities that unlock new areas, with either mandatory or optional-for-bonuses backtracking to previously blocked paths. (This is distinct from just flipping switches or finding keys -- you have to find things that change your character's moveset, and the new capabilities are what let you pass through.)
Non-linearity and ability-acquisition are the only essential elements. There's often platforming, a certain isolation-vibe, and a large single map, but those aren't mandatory to get the label.
Admittedly, that definition as given leaves most Zelda games qualifying. You go around gain abilities, there are often optional rewards for backtracking and using those abilities. (BOTW is a pretty major exception here, and so are the NES zeldas).
One notable difference is that there is rarely benefit to backtracking into previously completed dungeons. Even for 100% it is often possible to get everything with the first pass (without even using glitches or unintended interactions), which is not like most metroidvanias. However, most Zelda games but the games do tend to favor overwold backtracking for optional rewards.
Zelda, Metal Gear, Wizardry, Faxanadu, Rygar, Ys, Mother/Earth Bound. The list goes on and on. The element of revisiting previous stages/locations to unlock portions you couldn't access earlier on was a basic ingredient of old adventure games.
Spanish wikipedia, while English wikipedia says something else. Did you hunt with Google until you found some lone source citing it as "Metroidvania" just to try get a point across?
I live in a Spanish-speaking country, so Google defaults to Spanish Wikipedia. I forgot to change it to English like I did with my second link for the HN crowd. But you are incorrect yet again. https://en.wikipedia.org/wiki/Rygar ctrl-f "Metroidvania"
My point is that you create a lot of noise when your "corrections" aren't actually correct. It's basically nerd sniping to be wrong on the internet, especially about games.
Yes, I'm contributing to the noise. But I'm correct, so it's okay according to unwritten HN guidelines.
Oh, what willful ignorance. KF is the kind of "technically legal" operation that the charge of racketeering was invented for. Everyone knows what's happening and why things are laid out as they are, but nobody immediately responsible for the illegal act can be found.
If that doesn't work make the part you don't like illegal. Enshrine something like the "right to be forgotten" stuff into law and make them take down threads if the people they refer to don't want them up.
I know it's hard to word something like a "right to be forgotten" without making it to broad and a tool for abuse of chilling speech but it seems worth the effort if the consequences are this dire.
A "right to be forgotten" is probably fundamentally incompatible with the First Amendment in the USA. While people have the right to their own identity, they do not have the right to absolute control over their reputations. The best they can do is sue when they are defamed.
In America defamation lawsuits are hard because of the First Amendment, not just because lawsuits are expensive. Even if you make defamation lawsuits cheap and accessible, it will still be an uphill battle if you're trying to sue somebody telling unsavory truths about you.
One problem is that one can't bring a prosecution oneself; not only does the state maintain a general monopoly on the use of violence, but it typically maintains a monopoly on prosecution. If police or prosecutors dislike you (perhaps because you are a member of some socially disfavored out group) what recourse do you have?
I already live in an EU country - as do many of the people with threads on KF. I don't even have the minuscule amount of control voters in the US would have over this, and Cloudflare only cares about US legislation (as with the anti sex work legislation in the article).
If you would stop derailing the conversation with unfeasible solutions.
As per my old boss, the difference in prices when it comes to these microcontrollers and "less powerful" linux socs is negligible that it wasn't worth trying to target them. Not sure if/how the economics changed over the last 2-3 years either.
"Qt for MCUs" isn't the full Qt library as I understand it, but an entirely separate development
> Qt Quick Ultralite is designed to serve as a rendering engine for the application's graphical user interface (UI). Its implementation is different from the standard Qt, and it does not depend any Qt libraries such as Qt Core or Qt Gui. Hence Qt Quick Ultralite applications need to use standard C++ containers and classes instead of those from Qt. For example, instead of using QObject or QAbstractItemModel, Qt Quick Ultralite provides a simple C++ API to expose objects and models.
> It does not include the following from the Qt world:
> The Qt C++ APIs.
The non-graphical modules such as Qt Core and Qt Network.
The Add-on modules such as Qt Multimedia, Qt Bluetooth, and others Qt Addon Modules.
The non-MCU embedded platforms such as embedded Linux or the mobile platforms.
These days "microcontroller" refers to a part that has self-contained flash and SRAM, and the MMU/Linux-capable SoCs need external mass storage and DRAM to run. So there's a cost adder on the Linux parts. You might also need a denser PCB to handle DRAM signals (although Jay Carlson might be right on this).
These this are much more complicated to define then you think when you consider the kinds of strange hardware C supports, where bytes are not 8 bits and things like that. We tried to get endian-ness conversion functions in to c23 but ran out of time just because defining these functions so that their functionality is clear on non standard hardware is so difficult.
It would have been reasonable to define the functions only for the CHAR_BIT == 8 case, and if any implementers that support weird architectures want the functionality let them come forward with a proposal. I got the impression that the people working on the proposal got into an avoidable mess of complications.
Given that weird platforms are so dependent on C and since we release versions so infrequent, we try to get it right the first time. Often even defining what is excluded becomes complicated.
It was previously used by Microsoft for their C++/CLR (or C++/CLI) to mark garbage collected values. But that was after the type, not in front iirc.