I hear crickets chirping

[Kent-Dorfman]

Did not, but never thought to create such an abomination. I do know that I prefer while(1) to for(;;;)

[JonB]

It's actually quite a bit worse than that. Read C++ has good reasons to specify that infinite loops are undefined behavior and shudder when you discover a compiler on

#include <iostream>

int main() {
  while (true)
    ; 
}

void unreachable() {
  std::cout << "Hello world!" << std::endl;
}

actually prints Hello world, apparently....

[Kent-Dorfman]

I also have no great aversion to using a labeled goto to create an infinite loop, which is often necessary as an event procesessor in embedded systems.

[Kent-Dorfman]

I guess as long as it doesn't optimize out something like this:

while(1) { asm("nop"); }

Then I don't mind the "undefined behaviour of an empty loop.

Also, a lot of embedded microcontroller examples use the empty while loop as a "stop processing on error" catch in both C and C++ examples...I guess incorrectly then?

I don't know which clang version they are referencing but I tried the labeled goto variant

label:
goto label;

empty loop and it works properly in both g++10 and clang+11

[J.Hilk]

No worries—C++26 is going to address this and make the behavior consistent across all compilers.

Just 6 years away!

[JonB]

@J.Hilk
How come "C++26" is "6 years away"? Not 2026? Or does it get "adopted" next year but not "rolled out fully" for another 6 years/you are being ironic?

[Kent-Dorfman]

@Axel-Spoerl Now you're just makin me jealous. I'd love to do a couple weeks on a ketch rigged and outfitted for a toodle around the caribbean. Have fun!

[Axel Spoerl]

It'll be Montenegro / Albania this time. Albania will sure be fun, they have very little infrastructure for pleasure craft and shallow beaches in the North. So anchoring at 5m depth puts you a mile off shore.

[J.Hilk]

@JonB

@chatGPT explains the joke in I hear crickets chirping:

Excellent question! Let’s break it down clearly and simply.

When someone jokes:

“C++26 is only 6 more years away before release”

they’re poking fun at how long it often takes for compilers and tools to fully support new C++ standards after they are officially published.

Here’s the context in plain terms:

1. C++ naming: “C++26” is the standard planned to be finalized in 2026. So the name means the ISO committee is targeting 2026 to finish the standard.

2. But availability lags:

   • Even though the standard is published in 2026, your compiler (like GCC, Clang, MSVC) won’t fully support all its features immediately.
   • Historically it often takes 4–6 years after the standard date for widespread, stable, mainstream support.

3. Examples:

   • C++17 was finalized in 2017, but many people didn’t have fully usable compiler support until ~2020–2021.
   • C++20 was finalized in 2020, but full usable support (including modules, coroutines, concepts) is only maturing around 2024–2025.

So when someone says:

“C++26 is only 6 more years away before release”

they're joking:

✅ The standard will be written in 2026.
✅ But you probably won’t really use it comfortably in production until ~2032.

[JonB]

@J.Hilk said in I hear crickets chirping:

But you probably won’t really use it comfortably in production until ~2032.

Absolutely understood!

[J.Hilk]

@Kent-Dorfman

let me blow your mind!

int main ()
{
    std::println("Hello World");
}

[JonB]

@J.Hilk
Looking this up it says std::println() is C++23. Is C++23 not really a "thing", hence it won't appear until C++26?

[J.Hilk]

@JonB :P

fair, but thats like only 6 month more

[Kent-Dorfman]

@J.Hilk said in I hear crickets chirping:

@Kent-Dorfman

let me blow your mind!

int main ()
{
    std::println("Hello World");
}

I wouldn't use it anyway. I prefer iostreams. ;^)
One of my great fears is that I'll wake up some day and they will have deprecated them.

At a previous company they hired a guy I asked them no to, and I made the mistake of asking him to create or find a preexisting streams based logger class similar to syslog function and to implement manipulators so we could modify log level and output destination. He then started a multi-week campain to convince me why streams are a terrible idea and that we should have nothing to do with them. std::println() is something he would have liked.

[GrecKo]

And he was correct about that.

[Kent-Dorfman]

@GrecKo said in I hear crickets chirping:

And he was correct about that.

will agree to disagree. will do whatever I can to avoid pythonizing c++, or making it look like a java clone.

[SimonSchroeder]

On the one hand, I really like the new formatting syntax. It is especially helpful if you want to have translations inside your source (single string with placement of the arguments). But, it was so much easier to implement an operator<< for your own type than it is for fmt. Sure, there are some inefficiencies in the streams we cannot get rid off without breaking a few pieces of code (something related to locales, if I understand this correctly). There is still nothing better than streams for a generic interface for input and output. I have written a couple of classes that work on input and output streams, e.g. a class that computes a CRC32 on the fly while reading or writing a stream. It just adapts to another stream and is a drop in replacement where the stream would be used before. The new stuff is only about formatting, but not about composability. I'm still not sure where I am going to land concerning streams versus fmt.

@J.Hilk: Your hello world example won't compile. You forgot the import std; 😉

[JonB]

@SimonSchroeder
If you want to be picky, it presumably won't compile with warnings -> errors as the int function does not return anything ;-)

[J.Hilk]

@JonB since C++11 int main() has, as the only case in the whole standard, an implicit return value and not writing your own return 0 is completely valid.

Do not flame on me, I do not agree with this decision

[JonB]

@J.Hilk Really? That's ridiculous! It's a non-void function, so it needs a return, simplez ;-)