Hacker News: neonz80

New comment by neonz80 in "The PImpl idiom and the C++26 std:indirect type"

neonz80 — Fri, 24 Jul 2026 07:47:10 +0000

They didn't add PImpl support, they added std::indirect which can be used for PImpl among other things.

New comment by neonz80 in "A stray "j" ruined my evening"

neonz80 — Sun, 28 Jun 2026 10:17:19 +0000

Impossible, Signal TUI is written in Rust.

New comment by neonz80 in "C extensions, portability, and alternative compilers"

neonz80 — Mon, 25 May 2026 22:01:40 +0000

> Windows users singling out Linux users for not catering to their platform. How the times change...

In my experience this was a problem over 25 years ago when I developed for Solaris and other non-Linux operating systems.

New comment by neonz80 in "C64: Putting Sprite Multiplexing to Work"

neonz80 — Tue, 03 Mar 2026 22:24:57 +0000

If you put both handlers in the same 256 byte page you can get away with only updating the low byte of the address.

New comment by neonz80 in "Why Castrol Honda Superbike crashes on (most) modern systems"

neonz80 — Mon, 17 Nov 2025 14:10:03 +0000

Why an extra DLL instead of just patching the game executable? With some luck it is a one byte patch (from push 0 to push 4).

New comment by neonz80 in "A prvalue is not a temporary"

neonz80 — Thu, 06 Nov 2025 22:51:24 +0000

I find that this can reduce overall complexity. It makes it possible to use objects that can not be copied (such as a file descriptor wrapper) and moving can in most cases not fail. Without move semantics you'd have to use smart pointers to get similar results but with extra overhead.

New comment by neonz80 in "When O3 is 2x slower than O2"

neonz80 — Sun, 02 Nov 2025 13:47:45 +0000

I'm aware of how they are used, but fundamentally there is nothing with the words "array" and "vector" that says that one has a fixed size and the other has a dynamic size. If anything, it should be the other way around. Using the name vector for dynamic arrays is annoying when doing any kind of math coding. Even the designer of STL says the name was a mistake.

New comment by neonz80 in "When O3 is 2x slower than O2"

neonz80 — Sun, 02 Nov 2025 13:05:10 +0000

I find the short type names for integers and float hard to read. Somehow the size of the type is more important than if it is a signed integer, unsigned integer or a floating point number.

Using Vec for arrays is also annoying, repeating the mistake from C++.

New comment by neonz80 in "A secret to never forgetting numbers"

neonz80 — Sun, 02 Nov 2025 08:42:49 +0000

RobWords made a video about it a few weeks ago! https://youtu.be/UAT-eOzeY4M

New comment by neonz80 in "Async/Await is finally back in Zig"

neonz80 — Sat, 01 Nov 2025 19:29:58 +0000

You should take a look at the presentation I mentioned elsewhere in this thread. You also have to keep in mind that it's not only the branches that use space, but also the error handling code. Code which must be duplicated for every single call to a particular function.

New comment by neonz80 in "Async/Await is finally back in Zig"

neonz80 — Sat, 01 Nov 2025 18:55:12 +0000

The CPU can not remember an infinite number of branches. Also, many branches will increase code size. With exceptions the unwind tables and unwind code can be placed elsewhere and not take up valuable L1 cache.

New comment by neonz80 in "Async/Await is finally back in Zig"

neonz80 — Sat, 01 Nov 2025 17:00:05 +0000

That's a different type of overhead than having unwind tables. With exceptions you wouldn't need a branch after each function call at all.

New comment by neonz80 in "Async/Await is finally back in Zig"

neonz80 — Sat, 01 Nov 2025 16:36:13 +0000

There was an interesting talk about C++ exceptions in smaller firmware at CppCon last year: https://youtu.be/bY2FlayomlE

Basically, the overhead of exceptions is probably less than handling the same errors manually in any non-trivial program.

Also, it's not like these table doesn't exist in other languages. Both Rust and Go have to unwind.

New comment by neonz80 in "I write type-safe generic data structures in C"

neonz80 — Mon, 30 Jun 2025 21:49:21 +0000

I'm not sure about other compilers, but compiling C code as C++ with MSVC ends up with pretty much the exact same code, instruction by instruction. C++ is a bit more strict though especially with casting, so a lot of code won't compile out of the box.

New comment by neonz80 in "The Hall SC-VGA-2 Video Processor, the Atari ST and NeXTSTEP"

neonz80 — Tue, 03 Dec 2024 01:52:47 +0000

I do not find the Retrotink 4k any less configurable than the OSSC (non-pro, I haven't tried the pro). Note that the 4k is nothing like the 5X-Pro which is more plug and play.

New comment by neonz80 in "The Hall SC-VGA-2 Video Processor, the Atari ST and NeXTSTEP"

neonz80 — Sat, 30 Nov 2024 14:59:28 +0000

I've been using the OSSC to upscale a 50 Hz RGB signal (SCART) to 1024x1024 (256 lines duplicated 4x). Both my HDMI capture cards happily accept that resolution with the right software.

I haven't tried the OSSC Pro, but the Retrotink 4k should probably also work fine and is really easy to use. A bit on the expensive side though...

New comment by neonz80 in "European govt air-gapped systems breached using custom malware"

neonz80 — Tue, 08 Oct 2024 23:15:30 +0000

https://en.wikipedia.org/wiki/Unidirectional_network

New comment by neonz80 in "The Byte Order Fallacy"

neonz80 — Fri, 20 Sep 2024 22:08:52 +0000

The compiler can optimize this. See https://gcc.godbolt.org/z/hxW7hhrd7

  #include 
  uint32_t read_le_uint32(const uint8_t* p)
  {
      return p[0] | (p[1] << 8) | (p[2] << 16) | (p[3] << 24);
  }

ends up as

  read_le_uint32(unsigned char const*):
          mov     eax, dword ptr [rdi]
          ret

This works with Clang and gcc on x86_64 (but not with MSVC).

New comment by neonz80 in "Removing stuff is never obvious yet often better"

neonz80 — Mon, 26 Aug 2024 15:17:12 +0000

I guess Ethereal is available :)

New comment by neonz80 in "Show HN: SHAllenge – Compete to get the lowest hash"

neonz80 — Mon, 24 Jun 2024 20:51:20 +0000

I put my CPU code up here: https://github.com/neonz80/shallenge-x86 . It requires an x86 CPU with the SHA256 extension.

It manages 1.1 GH/s on an Intel i7-13700K.