I hear crickets chirping

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

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.