I hear crickets chirping

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:

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.
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.
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 ;-)

J.Hilk

@JonB

Kent-Dorfman

@J.Hilk said in I hear crickets chirping:

@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

Nor do I. Hidden or implicit actions are not a good thing.

I wonder what would happen if you explicitly define

void main() {}

Since the startup code only cares about the symbol, not its type.

 c++ test.cc 
test.cc:15:1: error: ‘::main’ must return ‘int’
   15 | void main() {
      | ^~~~

Well, there you have it.

SimonSchroeder

@Kent-Dorfman said in I hear crickets chirping:

Doesn't anyone have any esoteric C++ incantations to discuss. It's too quiet in here.

Change of topic: I recently found some esoteric C++ incantations: a constexpr counter based on template instantiation: https://b.atch.se/posts/constexpr-counter/ . However, it seems that this behavior is about to be deprecated (you cannot rely on the order templates are instantiated). At the same time, something quite similar has occured in one of the reflection examples (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2996r12.html Chapter 3.17 "Compile-Time Ticket Counter"). This reflection proposal has been accepted, so we might be able to safely do a constexpr counter through reflection starting with C++26.