How C syntax should be

you can think of foo[0] as *foo and foo[][0] as **foo but this only applies to the first element of the array, beyond that it is no longer a pointer.

this is also why a pointer to an array (*foo)[5] and an array of pointers *foo[5] are different

>Set up a Mumble server of the highest quality, beautiful audio
>Walk winbabbies through getting it and connecting, basically made a foolproof idiot guide
>Not a single person I played games with joined
Fuck discord and fuck its shitty VOIP quality and garbage.

Attached: 1541078189080.png (512x512, 187K)

C. pointers are modifyable unless const arrays are not modifyable Lvalues even if it "works" its undefined behaviour.

Retarded as fuck. All type information should be in the type declaration. Pointers are a separate type. Arrays are a separate type. C compiler knows this but syntax indicates otherwise with shit like int* a, b. Here's how it should go.

int i;
int* i
int[] i;
int*[] i;
()->void f; //function pointer to a function with no arguments and returns nothing
(int, int)->double f;
(int, int)->double[] f;//returns an array of doubles
((int, int)->double)[] f;//array of function pointers

also (*foo)[] v *foo[] matters because compile time allocation v runtime allocation. you can make dynamic arrays like: char foo = malloc(3 * sizeof(char));

this creates an unnamed dynamic array which can be accessed using foo

Waaaaaat

And while we are at it, cut those semicolon litter.

video games are just rigged time wasting stress causin bitches

semicolons are very useful because you can have line breaks almost anywhere in C so ; tells you where the end of statement is. \ is the line continuation character.

*teleports behind you*
muffin personnel kiddo

Attached: Screenshot_20190915-030747_1.png (1440x1289, 499K)

not python

it's called python though

the compiler already knows where statements end without any semicolons.

See this is why C++ is king. It's just so simple.

Thank god for Rust/

``*int`` is invalid syntax and the table is just a shitpost that makes it more confusing than it actually is. The only time pointer types get confusing is when you have `int *array[]`, in which case just use parenthesis to make it clear what you want.

C++ is fine as long as you dont use OOP.
the compiler might not always know
rust is also bloat

Foo foo(Bar());

thats nonsense. google 'confusing C syntax'

It doesn't.
a
+b

is this
a+b;

or
a;
+b;

?

how about you give me an example of confusing but valid C syntax that someone might actually use in a real project. I don't have to prove to myself what I am already sure I know about C.

Both are dead code.

geeksforgeeks.org/complicated-declarations-in-c/

And represent completely different things. Replace a and b with expressions with side effects if you want.

why is everybody so dumb :|
can we fix that?

while we are at it lets replace the address symbol with @, so

int *a, b;
a = @b;

means a receives the address in which b is at

A + B;

Tell me what the above does.

compile time error because none of that shit has been declared :^)

agreed, athough there is already a compiler extention that uses @ alongside &. @ is absolute address & is reference operator.

C type syntax is ugly, ML style is so much easier to read and understand

foo(A,B);
Hurr durr functions are dangerous because you don't know what they do

>geeksforgeeks.org/complicated-declarations-in-c/
>obscure function pointers of functions taking and returning function pointers
this isn't even what the OP image explores and this is why you just typedef shit.

in sepples it leaks memory and spawns nasal demons.

Great post, except you do know. A function called "foo" does foo. Since it's pass-by-value, it doesn't modify its parameters.
Now tell me what A + B does.

7 pages of template error messages

>rust is also bloat
By what possible metric?

>A function called "foo" does foo.
An operator called "+" does addition.

>An operator called "+" does addition.
not in sepples

a function called "foo" doesn't have to do foo in any language.

Yea, but some people write more than just scripts. Its like saying I only do drywalls profesionally, so I do not have to think about statical calculation.

>it's pass-by-value
References would like a word with you.

references were mistake

2/3 of the list is regarding function pointers, which in my experince are never used. The only time I used a function pointer was for the stdlib qsort, which sucks.

OOP isn't inherently bad. No one is forcing you to use too much abstraction.

Nothing. That doesn't compile.

Show them the positional audio feature. This is pure kino.

You don't even need to pass C++ references, you can pass pointers and the data behind them can be mutated.

No, THIS is how C syntax should be.
int func(int[50] arr)
{
// sizeof(arr) == 50 * sizeof(int)
// pointer != array, arrays don't degrade to pointers
}

My point was that you can't tell a function that passes by value and one that passes by reference apart just from how they're called, it implicitly takes a pointer in the latter case, so you can't even tell if the function you're calling is gonna modify your parameters.

But then you can see that the function possibly changes the values in the function call.
In C++ you cant distinquish these cases only by the function call, in C you can.

composing symbol name into the type notation is stupid. try this
foo : int // foo binds int
foo : []int // foo binds array of ints
foo : []*int // foo binds array of pointers to int
foo : *[]int // foo binds pointer to array of ints
foo : *[]*int // foo binds pointer to array of pointers to int
foo : ()->*int // foo binds function returning pointer to int
foo : []()->[]int // foo binds array of functions returning array of ints
foo : []()->*int // foo binds array of functions returning pointer to int

this is so much cleaner to write, read and reason about
distinguishing function and function pointer is superfluous

one might say it's similar to Go, but go also copied it from elsewhere. In fact Go did it wrong as always ;-)
in other langs it was
symbol : type = value

where type was optional and it became
symbol := value

while Go rather did the var notation. fucking idiots

>"array of functions" and "array of function pointers" are different things
Hold up what

Attached: hmm.jpg (580x679, 58K)

>what A + B; does
Nothing. Give me more context.

Attached: ShareX.png (875x542, 36K)

Why wouldn't they be?

this is great, I would prefere to use this. However, I rarely use such advanced variable types, mostly array ofpointer.

What's the problem? You can macro away addition in C. It's incorrect and no standard library does it, so it doesn't matter in either case.

Dick is diamonds, thanks user.

wrong

>wrong
Okay retard.

Only identifiers can be #defined as macros. There's no way to #define the + operator.

You can #define any token in C/C++, you know.

godbolt.org/z/kUEL2X

If it's any consolation, you cannot override operators over basic types.

Oh, I misread what you were saying, nevermind.

Even function types in C are pain in the ass. And writing vtables in C is pretty common.

>addition
What does it mean? I know what it *probably* does for objects representing numbers, but other than that? There's no standard way to add two objects.
>references
>C
It's a C vs C++ argument, brainlet.

>there's no standard way
If you prove your objects with "+" are a group, you can safely define and use operator+, operator- and their unary ones.

This is how types should look like.

Attached: moxxoeir7iqz.png (2255x1261, 134K)

>If you prove your objects with "+" are a group
good luck doing that within ς-calculus

>monomorphised generics
eww

Okay?
Pic related is how AI will take over programming. The French logicians were right, declarative programming is the only way forward. You just tell your compiler your sets and your morphisms and what you want to happen, and every blank gets filled in automatically (better than a human ever could).

Attached: Screenshot_2019-09-15_12-35-47.png (1920x1080, 881K)

>Okay?
prove that in C++, objects of type string with concatenation as the operation form a group

They're not. Assume they are, but the element string("abbababasidjaspdjsapdjaspodj") doesn't have an inverse element therefore this is not a group.

great, so unlike with mystring_concatenate(A,B), you can't tell what A + B does

see
K&R C is totally fine calling mystring_concatenate on an int an a double. Since casting is widely accepted in the C community, mystring_concatenate(double(A), quadruple(B)) is also fine. I mean you can literally look up the docs or even see the comment on the tooltips display of your favourite IDE as to what + does.

>hurr literal autism
mystring_concatenate(A,B) also doesn't compile, you're just grasping for straws, it's very clear what mystring_concatenate() does even without looking up in docs, unlike overloaded operators which you actually need to look up in the docs just to be sure
>hurr C type system is weaker than C++
yes, not an issue unless you're an uncivilized pajeet and don't use tools like klockwork and frama-c

But discord just works

>you're just grasping for straws
I'm giving you the benefit of the doubt.
>need to
You're assuming that mystring_concatenate actually concatenates the strings. Into which memory? Does it (re)allocate? Does it set errno or throw? I can make a mystring_concatenate() that concatenates LHS to RHS.
>uncivilized
My IDE has more than I need, no use downloading and setting up arbitrary people's code.

>You're assuming that mystring_concatenate actually concatenates the strings
yes, just like i'm assuming my compiler won't kill a baby, they're comparably safe assumptions; with overloaded operators, you can't make such assumptions at all because you have no idea what it does unless you look
>Into which memory?
(unimportant) detail which you can easily look up with your IDE
>Does it (re)allocate?
(unimportant) detail which you can easily look up with your IDE
>Does it set errno?
(unimportant) detail which you can easily look up with your IDE
>throw?
no such thing in C
>I can make a mystring_concatenate() that concatenates LHS to RHS
and i can overload + so that it terminates the program
>My IDE has more than I need
apparently not, because you need to look up in docs what A + B does, instead of getting by with type signature and name
i don't need to waste time with docs, because with ACSL i write spec for my function and if your mystring_concatenate() concatenates LHS to RHS, it violates my assumptions and frama-c will scream at me

the one with the * has array decay

>safe assumptions
>unless you look
Then it's a safe assumption that operator+ over std::strings is concatenation because that's what string+string is in any other language.
>(unimportant)
If you have a problem figuring out what one single line means, despite being surrounded by context up and down, you may need to look it up either way.
>no such thing in C
Yeah I know, shit language if errno is all you got.
>i can
Good. Don't do that. And please make mystring_concatenation actually concatenate strings.
>look up
I know for a fact what it means because C++ is a statically typed language. The two arguments are defined somewhere and the compiler enforces type correctness. Unlike C where I have to huff and puff as to what this ambiguity means
const char* mystring_concatenate(char* left, const char* right);

Even though C has no such thing as strings, and the return type is const for some reason. Is this a heap allocation or what?

>this mess is what C fags consider reasonable syntax

Attached: 1358500837316.jpg (800x600, 264K)

>operator+ over std::string
yes, safe assumption, just like strncat() doesn't do RHS-LHS, etc.
but we're on custom objects, not standard library
>despite being surrounded by context up and down
a real-world example from VoIP in C++
auto& rel = BT.retransmit(); // This is a ref to "connection" object
auto& diff = CL.retransmit(); // This is a ref to "connection" object
return rel + diff;

your task is to tell me what it does, given the same information as i would have if it was instead an appropriately named function - type signature (it returns "connection" object) and \brief --- empty
inb4 "hurr bad C++ is bad C++", yeah the point is there's many more features that *are* abused in C++ than there's in C
>errno is all you got
i got static analysis on level you C++tards can't even dream of, keep throwing copes
>C has no such thing as strings
that's good, because i have yet to see a good language-level implementation of strings (well, Ada has one)
your type signature is wrong though, it's my_string mystring_concatenate(mystring* l, mystring* r);
>Is this a heap allocation or what?
consult your docs if it matters (or \brief if the author of your lib wasn't a retard)

>strncat()
I could not care less about arbitrary C code.
>"connection" object
I don't know what a connection object is, if I did I'd probably know what it meant to add them.
>i got
Who cares, you're just some dude duct taping a laser pointer to his hammer.
>that's good
Ambiguity and assumptions cause entire domains of UB, vulnerabilities, and errors that no C compiler can catch yet compiles happily.
>mystring*
You lied to me. Your function concatenates pointers. I expect the returned object to be the address l points to (in hex) immediately followed by the address r points to (in hex).
>if it matters
In C++ it doesn't because allocation is encapsulated inside types.

>I could not care less about arbitrary C code
and that's why you're stuck introducing retarded bugs with your disfigured version of C
>if I did I'd probably know what it meant to add them
it means nothing, the + was overloaded to do CRC check on a buffer in that object, this abuse is simply not possible in C
>duct taping a laser pointer to his hammer
laser pointer + hammer still does much better job at producing safe programs than your disfigured mix of the past 20 years worth of feature-of-the-month
>Ambiguity
there's no ambiguity, if you need strings in C, you write them to exactly suit your use-case
>assumptions
my assumptions are documented in the spec and frama-c screams at me whenever it can't prove that they hold
>UB, vulnerabilities, and errors that no C compiler can catch yet compiles happily
i use compiler to compile my code, not to catch UB, vulns and errors - that's what analyzers and deductive verification are for
>I expect
your own fault for ignoring idioms
>allocation is encapsulated inside types
that's a very unsafe assumption to make, especially since there's a lot of legacy C++ that you need to work with in the industry

>version of C
I don't use C or a version of C.
>not possible in C
Right, what is possible is writing code that is at least as ambiguous.
>better job at
It doesn't, judging by the amount of CVEs that get found in Tier 1 C codebases like Linux, Darwin (macos), *SSL etc. Let alone the mundane buffer overflow. Let alone the fact that the quasi-standard way of accessing "c-strings" is going out of bounds (UB) until you hit a \0 (not necessarily present). What a joke language.
>suit your use-case
std::string and std::string_view can fit every use case for a string (a series of ASCII symbols). If you need something different, you're doing it wrong and what you are using is not a string. You're also more likely to introduce bugs unless you also spend the 10k manhours into a standard library like other people do.
>frama-c
I'm not obliged to use it and it's not mentioned in the ANSI standard. In fact, most C code I even see doesn't ship with frama-c.
>analyzers and deductive verification
It's completely the compiler's job to know that what it is compiling is indeed C code. And C code is defined per ANSII. Therefore, your compiler must check for ANSII compliance and halt upon evidence of otherwise. Which it doesn't.
>fault
You proved me right, you made a function that concatenates mystring's but takes pointers instead of mystrings.
>legacy C++
That's true and I admit it. It's my current job to turn Ye Olde C++ to modern such.

>I don't use C or a version of C
C++ is a disfigured version of C, no need to hide anything
>at least as ambiguous
no, if it was C the function would have to be named which is much harder to screw up
>Tier 1 C codebases like Linux, Darwin (macos), *SSL
great examples you have here, how about the "Tier 1" C++ codebases like chromium or firefox? C++ really helped them out
none of the projects you listed has a spec, none uses appropriate tools for writing safe code, thus they don't care about safety
>mundane buffer overflow
impossible to introduce if your spec defines bounds (which it always does)
>"c-strings"
no such thing
>std::string and std::string_view can fit every use case
unless your strings are really, really long
>string (a series of ASCII symbols)
>you're doing it wrong and what you are using is not a string
so a string of unicode symbols is not a string?
>more likely to introduce bugs unless you also spend the 10k manhours into a standard library like other people do
no, i'm much less likely to introduce bugs since i always write a spec, unlike those other people (no, informal spec is not a spec) so the only way for me to introduce a bug is to write a bad spec (which happens rarely, but it still is a possibility), moreover it doesn't take 10k manhours, it takes fraction of that because i don't need everything in the monstrosity that is c++ stdlib and i don't go hunting for bugs in implementation because i have none
>I'm not obliged to use it
yes, you're not obliged to use modern c++ either
if you care about safety, you go out of your way to provide it, you don't throw your hands up and say "it's not for free"
>most C code I even see
most C code you see doesn't give a flying fuck about safety or being correct, just like most C++ code i see doesn't give a flying fuck about being safe (or clear, or even performant)
>your compiler must check for ANSII compliance
which it does; UB is not an error
>takes pointers instead of mystrings
common C idiom

sometimes its much comfy to inline shit so your code looks cute because it occupies a line.

>>"c-strings"
>no such thing
every time

There's no reason in C to ever have a pointer to an array, because a double pointer would have the exact same semantics, but if they were ever to implement it, I think they'd probably do it like this.
int (*foo)[]