I hear crickets chirping
-
@J.Hilk said in I hear crickets chirping:
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 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.
-
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;😉 -
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;😉 -
@SimonSchroeder
If you want to be picky, it presumably won't compile with warnings -> errors as theintfunction does notreturnanything ;-)@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
Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct
Q: What's that?
A: It's blue light.
Q: What does it do?
A: It turns blue. -
@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
-
@J.Hilk Really? That's ridiculous! It's a non-void function, so it needs a
return, simplez ;-) -
@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
@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.
-
Doesn't anyone have any esoteric C++ incantations to discuss. It's too quiet in here.
@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
constexprcounter 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.
