C is the best programming language, period. There is no debating this. It is just pure, objective fact

Thank You.

Attached: Programming-trends.jpg (1421x753, 163K)

more like the Onions programming language

c++ inline does more than it should. the inline spec should inline a function and nothing more. mountains of implicit rules to be enforced across multiple files are the reason c++ takes twice as long to compile as c.

The semantics of inline or out of line function calls does not matter nearly as much as controlling linkage does.
C only compiles and links faster than C++ because a C++ linker is more useful than a C linker.

i might be wrong here, but doesn't c++ handle most of it's features through name mangling and implicit reference pushes? that would all be handled at the time of code generation. what's special about the linker then?

You can use Java without any frameworks if you want to spend all your time reinventing the wheel like you would do with C you idiot.

C is shit

C++ inline is different from C inline.
In C, a function defined as inline is never exposed as an externally visible symbol unless its prototype appears again as an extern inline function. Each translation unit that sees the inline definition is free to replace the function call with an inline substitution, but the compiler is free to continue using an out-of-line function call to an external symbol. This may result in linker errors if the function is not extern inline'd in exactly one translation unit.
In C++, a function declared inline may or may not be compiled as an externally visible symbol within any given translation unit depending on whether an inline or out-of-line function call is used in that translation unit. The linker ensures that all the externally visible inline symbols are the same so the duplicated symbols across all the translation units collapse together. It takes the compiler longer to compile duplicate functions and the linker more time to ensure they are equal, but it also means you can simply keep all your definitions in headers without having to create dedicated translation units for libraries.
If you have a small library used in few places then it can be worth simply inserting all your function definitions (and as of C++17 variable definitions) into the header without instantiating a dedicated translation unit for them simply for making your build process easier. For large libraries or commonly used libraries it's probably not worth it.

tl;dr: you can do header-only libraries in C++ but not in C because of the differing semantics of inline.

HolyC is better

What delusional faggotry. C is shit. Literally javascript and PHP tier.

>C
>objective
What did he mean by this?

I want to learn c++ as my first program language
I'm using this book. Is it ok?

Attached: images(39).jpg (300x376, 26K)

Don't start out with C++, python/java are better beginner languages

static inline in headers.

But the inline keyword is useless anyway, if you want guarantees you have to use compiler specific pragmas/attributes.

just use static inline

Const-ness is broken in C, and it triggers my autism way too much.

imagine that const means "in ROM"
then it all makes sense

except that string literals are not const char *
but oh well

Agreed.

Unironically this
Programming in C it's just so good
It's brilliant, the more you understand C the more new things you find
No other language comes close to C
No other language makes you feel this good when you solve and understand something
Thank you Dennis Richie

this is what I mean
void foo(const char * const * argv)
{
}

int main(int argc, char * argv[])
{
foo(argv);
}

if you compile as C (since C++ actually fixes this)
prog.c:12:9: warning: passing argument 1 of 'foo' from incompatible pointer type [-Wincompatible-pointer-types]
foo(argv);
^~~~
prog.c:6:31: note: expected 'const char * const*' but argument is of type 'char **'
void foo(const char * const * argv)

foo expects a const pointer to const data. But you're giving it a const pointer to non-const data

nvm I need my glasses.. You're passing a non-const pointer to foo

#include

void foo(const char **a, int s)
{
int i;
for (i = 0; i < s; i++)
printf("%s\n", a[i]);
}

int main(int argc, const char *argv[])
{
foo(argv, argc);
return 0;
}

yep that should work. Most people don't make argv const tho

It's even misleading to make argv const because it isn't, you are allowed to modify it.

you should though, bad things happen when you try to modify argv

says who???

My point was that I should be able to pass the pointer, since the following is valid:

void foo(const char * argv)
{
}

int main(int argc, char * argv[])
{
foo(argv[0]);
}

const, for function parameters, essentially means 'read-only'. So you can pass a non-const T* type to a function expecting const T*.

pass which pointer?

the argv pointer in my original example

lol

I agree

It's explained here
stackoverflow.com/questions/40090571/why-does-calling-a-function-that-accepts-a-const-char-const-with-a-char

const int a = 10;
void foo(int const ** ap)
{
*ap = &a;
}

void bar()
{
int * p = NULL;
foo(&p);
*p = 20;
}

If you were allowed to implicitly cast, this would be okay and you could be able to set a to 20.
C++ didn't fix anything, it has broken it.

That's why I wrote it like this
void foo(const char * const * argv)

The second const is what prevents what you wrote, like this
void foo(int const * const * ap) // here you cannot assign to *ap;

Static inline is the same as static, as far as linkage is concerned. You'll get horrifyingly bloated executables if you try it.

Also the point is not about inlining functions for performance, it's about how C++'s inline keyword weakens the One Definition Rule so you can simplify the build process.

You're right
I could swear that I remembered that once I tried to modify the program segfaulted but I guess I remember wrong, sorry
#include

int main(int argc, char *argv[])
{
char *c;

for (int i = 0; i < argc; i++) {
for (c = argv[i]; *c != '\0'; c++)
*c = 'x';
}

for (int i = 0; i < argc; i++) {
printf("%s\n", argv[i]);
}

return 0;
}

It was the best, back in like 1980. Then there was C++, then Java, then C#, and now we're at Rust. Rust is undeniably the best programming language in the world at 2018. There's a reason there's so much hype and excitement surrounding it, and constant development pushing the ecosystem forward. It has the best qualities of all languages that existed before it. It's fast. It's safe. It's easy to use. There's literally no reason to use anything else now, unless you're maintaining old legacy code that you can't afford to port to Rust, or if you're just plain retarded.

#include

int main()
{
char a[] = "foo";
char *s = "foo"; // this is dangerous, it should be declared as const

printf("%s\n", s);
printf("%s\n", a);

printf("%lu\n", sizeof s / sizeof s[0]); // this prints 8
printf("%lu\n", sizeof a / sizeof a[0]); // this prints 4

for (char *p = a; *p != '\0'; p++)
*p = 'x';

// this segfaults but if we declared s as const char *s
// and we compiled with -Wall it would warn us about it
//for (char *p = s; *p != '\0'; p++)
// *p = 'x';

printf("%s\n", s);
printf("%s\n", a);

return 0;
}

C# here.
Is rust really worth it? Jow Forums says it has dozens of limitations and personally I don't like things like 'fn', '|>' and '_' everywhere.

enjoy your chastity cage

Attached: k&r.png (595x592, 46K)