Headers are actually pretty great, in every language I have tried, modules suck. As for C++ trying to refrofit modules was as mistake. Instead of modules, headers should have been tweaked to make multiple precompiled headers possible.
Why n? some OSes use rn. And herein lies the issue
1 month ago
Anonymous
n is a newline not a linefeed/carriage return.
"endl" has never been necessary to get a proper newline. It's just cargo-culting. But then again if someone is telling you iostream is a good idea for doing I/O you're already in cargo cult city. Or you're taking advice from bjarne.
1 month ago
Anonymous
troons FEAR bjarne
1 month ago
Anonymous
Look bjarne, iostream is a shit API. Despite C++ being one of the most popular languages nobody has ever looked at iostream and thought "hmm that's a good way to do I/O, I'll steal it for my programming language". Meanwhile printf style I/O is everywhere.
1 month ago
Anonymous
okay, but people still use C++
1 month ago
Anonymous
They do and I do as well, I dread touching ioshit (Bjarne's pet library) and prefer using C stdio despite its own setbacks. I'm very glad about the new formatting libraries.
At least in msvc's case, imports are faster to compile than #includes.
IIRC puts flushes immediately, which will be slower than println which is likely buffered.
I used to think iostream was the most clever thing when I first started programming. Now I think that Bjarne was just moronic.
String interpolation is the way to go. Printf style formatting is second.
>Printf style formatting is second.
No, there's an overhead in passing and recovering arguments to a variadic function in x64, besides that you need to parse the format string, so that is the Black person way to go.
Atomic formatting functions is the way to go.
int
main(int argc, char* argv[])
{
const int32 times = 2005;
const char* color = "brown";
TOBuffer* buffer;
cctnln(cctstr(cctstr(buffer, "Hello "), "sir."));
cctnln(cctstr(ccti32(cctstr(cctstr(cctstr(buffer, "The quick "), color), " fox jumps over the lazy dog "), times), " times."));
cctstr(cctstr(buffer, "The quick "), color);
ccti32(cctstr(buffer, " fox jumps over the lazy dog "), times);
cctnln(cctstr(buffer, " times."));
absbffr_flush(buffer);
If you use MSVC maybe. Clang and GCC don't support modules yet, and honestly, headers worked fine.
>headers worked fine
but handling headers in big projects feels unwieldy, and they're not very fast to compile.
I wish they had been introduced much earlier for support and libraries to be ready.
nothing support modules yet, not even msvc, the whole concept behind modules is ruined anyway rendering it with no true benefits over headers
it's possible to use import std; on macos, but you cannot import your own modules yet
How did they botch this so hard.. is it the true purpose of the committee?
headers are the worst feature of C
Headers are actually pretty great, in every language I have tried, modules suck. As for C++ trying to refrofit modules was as mistake. Instead of modules, headers should have been tweaked to make multiple precompiled headers possible.
Modules work great in Go, Rust, Hare, C# and Java.
headers are a preprocessor feature, not a C one
so practically nothing ever written is technically C code because it requires a preprocessor.
The C preprocessor is a standard-mandated part of the C language.
>You have to write function signatures twice in two different files because uh... YOU JUST DO OKAY??
you don't have to, you can just declare everything in correct order in your src file so the declaration is always above the invocation
>a function is added to the standard
>its just formatted print, but prints additional character
why
Because the C++ committee is a bunch of cucks that can't say no to anything. All C++ gets is more bloat.
/C++
endl is slow, printf parse argument at runtime
or you can just include 'n' in the format string
Why n? some OSes use rn. And herein lies the issue
n is a newline not a linefeed/carriage return.
"endl" has never been necessary to get a proper newline. It's just cargo-culting. But then again if someone is telling you iostream is a good idea for doing I/O you're already in cargo cult city. Or you're taking advice from bjarne.
troons FEAR bjarne
Look bjarne, iostream is a shit API. Despite C++ being one of the most popular languages nobody has ever looked at iostream and thought "hmm that's a good way to do I/O, I'll steal it for my programming language". Meanwhile printf style I/O is everywhere.
okay, but people still use C++
They do and I do as well, I dread touching ioshit (Bjarne's pet library) and prefer using C stdio despite its own setbacks. I'm very glad about the new formatting libraries.
they need an entire paper just to print a blank line
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3142r0.pdf
very sexy
It should have been like this since the beginning.
Overloading << to print text is awkward as hell.
If Bjarne was serious about the craft he would have made a new operator, like, for example, <<--%
perhaps even 8=D~ (Squidward with boogers operator)
printf is in C++ Standard since its literal beginning
printf is unsafe.
It's not if you pass to it literals like in OP's example
It doesn't work with custom types
volatile?
wrong tread lol
true, but 'n' flushes and jumps to new line either way, despite slightly different behavior
Implying println does lol.
It does. You can write you own formatter with custom flags and everything.
At that point can't I just do
printf("my cool type: %s", myType.toString())
Agreed. Overloaded operators are cancer, should be member functions.
In shaa Allah, there is only one hello world program in C++ and it is as it was written:
#include <iostream>
using namespace std;
int main() {
cout<<"Hello World!"<<endl;
return 0;
}
Code monkeys are so fricking wear, I swear, too god.
Why cannot be simply like "Print: Hello world"
This man gets it.
frick off
in Nim this is just
echo "hello world!
literally never heard of it and who asked?
>literally never heard
Lurk moar, Zoomie
It's over, even C++ is becoming troony like rust
Preprocessor and << abuse were always shit.
i still prefer printf
Why doesnt the int function have to return int too? is it just returning zero by default?
>is it just returning zero by default?
Yes.
How is that any better than
#include <cstdio>
int main() { std::puts("Hello, world!"); }
At least in msvc's case, imports are faster to compile than #includes.
IIRC puts flushes immediately, which will be slower than println which is likely buffered.
formatting, duh
>C++ becomes safe and usable when it resembles Java
just use rust, unironically
it should be
import std;
auto main() -> int
{
std::println("Hello, world");
}
>import std
you don't need to do this in C++2
Please tell me you're a moron without telling me you're a moron.
I used to think iostream was the most clever thing when I first started programming. Now I think that Bjarne was just moronic.
String interpolation is the way to go. Printf style formatting is second.
>Printf style formatting is second.
No, there's an overhead in passing and recovering arguments to a variadic function in x64, besides that you need to parse the format string, so that is the Black person way to go.
Black personlicious, pls kys.
Atomic formatting functions is the way to go.
int
main(int argc, char* argv[])
{
const int32 times = 2005;
const char* color = "brown";
TOBuffer* buffer;
if ((buffer = absbffr_create(4096, flushcallback)) == NULL) {
return -1;
}
cctnln(cctstr(cctstr(buffer, "Hello "), "sir."));
cctnln(cctstr(ccti32(cctstr(cctstr(cctstr(buffer, "The quick "), color), " fox jumps over the lazy dog "), times), " times."));
cctstr(cctstr(buffer, "The quick "), color);
ccti32(cctstr(buffer, " fox jumps over the lazy dog "), times);
cctnln(cctstr(buffer, " times."));
absbffr_flush(buffer);
absbffr_destroy(buffer);
return 0;
}
>in 2024 c++ is what java was in 2000
based and redpilled
Does C++ have implicit returns?
Otherwise why is main not returning an int?
Main is special.
Get it from your favorite compiler in 2036
> import std
Looks like Python.
Thumbs up.