Thus void*+size is usually the right type if ones only care for the memory representation of an object (cstring functions like memcpy, etc.)

Most likely one would have both overloads:

    void Hexdump(const void *p, size_t size); // (1)
    
    template  // (2)
    inline void Hexdump(const T &obj) {
         return Hexdump(&obj, sizeof(T));
    }

(1) could also take std::span, but (void*, size) is the more common idiom, more convenient to use and to read , as it is unambiguous which overload it is.

You don't need to explicitly cast T* to void* (guaranteed to be safe), you only need to cast when converting out of void*.

The rules are basically the same as casting between pointer-to-derived-class and pointer-to-base-class and they make sense.

If they've been doing that to the other repo (and especially if they're just a spam account), there's a good chance using the "report" button and/or contacting GH support directly can yield positive results, up to the spam account being deleted (and the PR is usually deleted).

Unfortunately this doesn't scale.

New (and delete) can be used in constexpr functions, however memory "allocated" like that cannot leave the constexpr "sandbox" so to speak, therefore std::vector cannot be generated at compile-time, but std::array may.

If you are working with fixed-size data like LUTs, just use std::array [1]

[1] Make sure not to use std::to_array when embedding 200KB+ files, as it's a mere constexpr function and not a language construct and will exceed constexpr limits; either specify the size or use a C-style array in this case

And well, one can always prompt "review my feature branch" or "review this file for bugs" with these tools; code analysis plays into the strengths of LLMs far more than code generation, since false positives/hallucinations aren't a problem with the former.

By the way, I have something related rather large in the works, look forward for a "Show HN" ;) (hopefully this quarter!)

> better support than Nintendo does with all their trillion-Yen revenue available to them

Well, they had to develop the entire OS, all GUI applications and SDK (and docs, and tooling...). It would also be far from surprising if they moved significant headcount to developing the Switch after the 3DS launched (and considering the Wii U's apparent failure).

There have been traces of Switch 2 stuff in Switch 1 kernel 3 years (?) before the S2 launched, so, in terms of planning, this tracks.

> My only hesitation is the firmware update

If you "hack" your 3DS you will not have to worry about sysupdates anymore. It is slightly more straightforward to do so if your system version is <= 11.14, and quite trivial if <= 11.3.

As for homebrew dev on 3DS, you have a lot more RAM and a "proper" CPU with somewhat modern CPU concepts (an actual OS, virtual memory, caches, multicore).

Unlike the DS and GBA, the 3DS has an actual GPU (well, kinda, it doesn't have programmable fragment shaders), which was designed around a custom flavor of OpenGL ES and it shows; citro3d is a shim, other than stateful state tracking and mem allocation, it mostly exposes the GPU hw as-is.

Overall, I think it is easier for people to get started with 3DS homebrew development and that it provides more transferable skills (w/r/t OpenGL-like APIs).

Disclaimer: I'm the lead maintainer of Luma3DS, am a core maintainer of libctru, and wrote significant parts of the exploit chains the guide uses. Feel free to ask around.

Honestly, I think why the GBA is more popular than the DS for that kind of thing is because it only has one screen (much less awkward to emulate), has high-quality emulators that are mostly free of bugs (mGBA most notably), and its aspect ratio is better than the DS anyway (3:2 upscales really well on 16:10 devices). That is to say, it's much easier to emulate GBA software on a phone or a Steam Deck than it is to emulate DS software.

This police ordinance from 1800 was abolished in 2013

> requiring permission of the husband to work

Repealed in 1965

> require the STL

That it has to heap-allocate if non-inlined is a misconception. This is only the default behavior.

One can define:

void *operator new(size_t sz, Foo &foo)

in the coro's promise type, and this:

- removes the implicitly-defined operator new

- forces the coro's signature to be CoroType f(Foo &foo), and forwards arguments to the "operator new" one defined

Therefore, it's pretty trivial to support coroutines even when heap cannot be used, especially in the non-recursive case.

Yes, green threads ("stackful coroutines") are more straightforward to use, however:

- they can't be arbitrarily destroyed when suspended (this would require stack unwinding support and/or active support from the green thread runtime)

- they are very ABI dependent. Among the "few registers" one has to save FPU registers. Which, in the case of older Arm architectures, and codegen options similar to -mgeneral-regs-only (for code that runs "below" userspace). Said FPU registers also take a lot of space in the stack frame, too

Really, stackless coros are just FSM generators (which is obvious if one looks at disasm)

std::bit_cast is

-Wextra catches stuff like this, alas I know of a few people that think "-Wextra is evil" (even though annoying warnings can be selectively disabled)

In both personal projects and $dayjob tasks, the highest time-saving AI tasks were:

- "review this feature branch" (containing hand-written commits)

- "trace how this repo and repo located at ~/foobar use {stuff} and how they interact with each other, make a Mermaid diagram"

- "reverse engineer the attached 50MiB+ unstripped ELF program, trace all calls to filesystem functions; make a table with filepath, caller function, overview of what caller does" (the table is then copy-pasted to Confluence)

- basic YAML CRUD

Also while Anthropic has more market share in B2B, their model seems optimized for frontend, design, and literary work rather than rigorous work; I find it to be the opposite with their main competitor.

Claude writes code rife with safety issues/vulns all the time, or at least more than other models.

> what's the point of globally visible singletons except "everything is an object" cargo-culting?

Having the singleton be an object becomes interesting when:

1) it contains attributes that themselves have non-trivial constructors and/or destructors. Order of initialization and destruction is guaranteed (init is in forward order of declaration, destruction in reverse order)

2) more rarely, inheritance (code reuse)

In the case of 1), you can just opt to construct the singleton on a sufficiently-aligned byte buffer in-place with `std::construct_at`. This gets rid of static-init order fiasco, __cxa bloat (if applicable), atexit bloat, and you can chose to just not call `std::destroy_at` if you don't need to.

In these two scenarios it's a lot more efficient to group many related objects into a bigger object.

It's just that I value the right to reveal my identity on my own terms a lot higher than $1200 (using my username and project name is fine). For the offer to become enticing they would need it to be 5~10y instead of 6mo, or to simply remove the $realname part of the "publicity" section