Why C is sucks?
- Home
- Board: /g/ - Technology
- Reading: Why C is sucks?
Why C is sucks?
???
>>53285332
int array[] = {1, 2, 3, ,4 , 5, 6};
printf("%d", sizeof(array));
output: 4
why not 24 ??!
>>53285384
because the name of an array is a pointer to its first element. array[subscrupt] is just some syntactic sugar for pointer arithmetic. Memory management is your responsibility in C, the compiler doesn't keep track of how much you have, and its your responsibility to free it when you're done.
http://steamcommunity.com/groups/godisadog
>>53286133
is learning memory management(C) important? coming from Java it seems like i don't have to worry about memory management at all but i also don't want to be one of those script kiddies cos programming is getting mainstream these days, people with java/python skills will probably be way too much
>>53285384
It's giving you the size of an int* kiddo.
You need to pass in the number of elements too.
>>53286171
You can't write any significant C at all without a good understanding of memory management. Most of it's just "remember to free() what you malloc()", but it's important to know about allocating on the stack vs the heap, how things are laid out in memory, and so on. C compilers are old-style "I assume that you know what you're doing" kinda tools.
>>53286133
>>53286172
>>53286280
I know what's going on with the code but what I mean is why the array not treated like real array like this: array[24] ???
why isn't this in C standards?
>>53286404
>why isn't this in C standards?
actually the behavior you find baffling IS what the standard says it should be. If you want an array of 24 separate bytes, make one. if you want an array of six ints, usually you want them to be six ints (which happen to be four bytes each) so you can just say something like x = array[3]; and get the four-byte int at that spot. You can do it manually, too, if you want:int* array;
/* allocate 24 bytes - space for six ints */
array = (int*) malloc(6 * sizeof(int));
>>53285324
It doesn't.
You just have to remember that in C your key abstraction is the machine itself, while in other hlls it's the system or process you're modelling.
C is the right tool most of the times that you want that to be true.
>>53286491
It's important to note the difference between the stack and the heap when comparing these two cases though.
>>53286404
I'm pretty sure an incomplete array is just a pointer. If you think that's bad, try using sizeof on an array parameter.
>>53286541
C is the wrong tool all the time.
>>53286491
why would you use
>array = malloc(6 * sizeof(int));
instead of
>array = malloc(6 * sizeof(*array));
Also why are you casting malloc?
K&R C or Modern Approach to buy?
>>53287271
malloc needs to be casted, otherwise you will just get void pointers
>why would you use
>array = malloc(6 * sizeof(int));
instead of
>array = malloc(6 * sizeof(*array));
try printf("%d, %d\n", sizeof(int), sizeof(int*)); on multiple machines, they are not always the same size.
you want to allocate space such that an int will fit into each space. in this case, 6 spaces. if you wanted to store an array of pointers to an int, then you would be fine.
>>53287529
Congratulations, this is the most retarded post on /g/ right now!
>>53285324
no namespaces
no operator overloading
poor type safety
poor const system
>>53285324
https://www.youtube.com/watch?v=KlPC3O1DVcg
>>53287697
wasn't there a rumor that he purposefully invented C++ to set back programming
>>53287727
No, ctards were so retarded that they took a joke as if it were reality. The truth is that the invention of C literally, provably set back programming over 50 years. To this day, we still don't have feature parity with forth, apl, lisp, or bcpl even though everyone obviously want these features since every year or so a batch of them are adopted in every other modern language.
>>53287754
>forth
Too powerful for it's own good.
>apl
I'm not buying a programming keyborad
define min(x,y)( (x)<(y)) ? (x) : (y)
main()
{
printf( "%d\n", min (3,6) +1);
}
why does it return 3?
>>53287566
>I'm so bad at programming I need safety nets and high level spaghetti code bullshit that reminds me of BASIC
>>53287754
I've programmed in C,it was my first programming lanuguage in fact, but I'm definitely not a C hacker.
My impression is that of a laguage that filled a niche at the time, and then it took off like a virus in the 70's-80's.
It's not a very good language, it comes from the "good enough" tradition of Unix.
It should be now possible to design a system programming language NOT in the tradition of C, but nobody seems interested.
>>53285324
If we are talking about developing the infrastructure everything works on, C sucks because you suck at programming.
For everything else it sucks because it's just inconvenient, the development time is an issue in end user programs.
>>53287806
>no #include <stdio.h>
>no # before define
>parenthesis in the wrong place in define (the one after <(y) should be at the end
This is why kids hate C, they suck at it.
>>53287837
Linear types are a great idea (ats, rust, idris, f*), though unique types are good enough (clean, etc.) to bring the same semantics as C with none of the lack of safety. From there it's possible to add any paradigm or abstraction you want without performance penalties or loss of safety.
C never actually filled a niche (as bcpl, forth and fortran already existed), it just happened to be pushed by the unix folks as the Next Big Thing (tm). It's basically 70's rendition of java in virtually all regards (high-level, but not as high as what can be, slow (it only got non-shit compilers much later), unsafe, verbose (thankfully modern compilers are good enough that we can strip 90% of annotations safely), pushed by a single large corporations, and learned by every monkey because pushed -> learn to get job -> people know it -> pushed due to low training costs). Unlike java, nobody has ever been allowed to call it shit (as it was).
>>53287806
also
>int main()
>return 0;
Baby's first C program?
>>53287906
It's not a good idea, but the compilers these days are usually smart enough to include the header by themselves.
>>53287831
Yeah, abstractions are for plebs. Who needs while/for/do when you have a perfectly good goto statements
>>53287948
Bullshit.
>>53287906
does this fix your autism?
>>53287957
Try it yourself with a simple program.
The program will work, but you'll get a compiler warning.
>>53287958
Because it will expand to ( (3) < (6) ) ? (3) : (y) + 1
>>53287958
>including stdlib for the unnecessary EXIT_SUCCESS (EXIT_SUCCESS is always 0)
>still not fixing the parenthesis
>still not using int main
>calling CORRECT FUCKING C CODE "autism"
Are you 12?
>>53287965
mind = blown
>>53287969
>EXIT_SUCCESS (EXIT_SUCCESS is always 0)
how do you know?
that's not very multiplatform of you to assume
>>53288026
Keep in mind that you should never actually do this.
Something about performance? I think?
>>53287948
No, it's called "undefined behavior." It might work, but it shouldn't.
If you can't even program correct fucking C, just stop even trying to be a programmer. Seriously, it's not fucking hard.
>>53287969
>doesn't know C
>calls others retarded because they actually know C
C is a lovely language if you take it for what it's worth. I personally prefer C++ because
>muh OO and
>muh functional programming
but C is probably one of the most elegant languages in the history of programming. Few other languages span such a breadth and depth in terms of talking to a computer without the labrynthian complexity best displayed by C++.
>>53288058
>doesn't know C
Those are all CORRECT C ACCORDING TO THE STANDARD FUCKING C. You fucking dumbshit baby.
>>53288054
no it's bad to assume your compiler knows wtf your doing.
thankfully newer gcc builds should throw error in the future
>>53287918
>C never actually filled a niche
What if the niche is smug Unix weenies?
>(as bcpl, forth and fortran already existed), it just happened to be pushed by the unix folks as the Next Big Thing (tm).
ehehehe
>It's basically 70's rendition of java in virtually all regards
No, Java was somewhat designed.
>(high-level, but not as high as what can be,
slow (it only got non-shit compilers much later),
a lot of C idioms seem designed to circumvent shitty compilers from the 70's
>unsafe,
Don't even get me started on this
>verbose
> Unlike java, nobody has ever been allowed to call it shit (as it was).
They did, but the Unix religion won
>>53287697*YOU* are full of bullshit.
C++ is a horrible language. It's made more horrible by the fact that a lot
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it. Quite frankly, even if
the choice of C were to do *nothing* but keep the C++ programmers out,
that in itself would be a huge reason to use C.
In other words: the choice of C is the only sane choice. I know Miles
Bader jokingly said "to piss you off", but it's actually true. I've come
to the conclusion that any programmer that would prefer the project to be
in C++ over C is likely a programmer that I really *would* prefer to piss
off, so that he doesn't come and screw up any project I'm involved with.
C++ leads to really really bad design choices. You invariably start using
the "nice" library features of the language like STL and Boost and other
total and utter crap, that may "help" you program, but causes:
- infinite amounts of pain when they don't work (and anybody who tells me
that STL and especially Boost are stable and portable is just so full
of BS that it's not even funny)
- inefficient abstracted programming models where two years down the road
you notice that some abstraction wasn't very efficient, but now all
your code depends on all the nice object models around it, and you
cannot fix it without rewriting your app.
In other words, the only way to do good, efficient, and system-level and
portable C++ ends up to limit yourself to all the things that are
basically available in C. And limiting your project to C means that people
don't screw that up, and also means that you get a lot of programmers that
do actually understand low-level issues and don't screw things up with any
idiotic "object model" crap.
>>53288071
>>53287958
is correct C according to the C standard. Just because you don't know C does not mean you're an expert on C. I have no idea why I have to inform you of this fact.
>>53288054
It's got nothing to do with performance and everthing to do with portability. just because your shit builds on some four year old gcc release doesn't mean it'll build on some other arbitrary clang release or whatever the hell people use these days. you should always be explicit when talking to your compiler.
>>53288089
Is there anything linus was ever not wrong about?
>>53287969
it's from a book and my question is why it returned 3 meant it complied correctly, i didn't want to write down unnecessary code on phone. So yeah you have autism.
>>53288089
hello, linus
>>53288089
C is genuinely a good choice for a kernel though.
It just werked for what it was intended to. This isn't the 60's bell labs programming on pdp-11 where 64k memory was huge
>>53288166
It's a horrible choice for kernels because it contains no tooling or primitives to ensure safety or correctness, which are beyond important at such a low level.
>>53288223
Yes, but it's as close to the metal as you can get without going into assembly language.
>>53285384
it does return 24.
>>53287806
because you fucked up the macro.
>>53288240
That's irrelevant since C requires OS primitives to actually perform its "low-level" operations (i.e. you'd have to bootstrap, whether or not you use C, C is only low-level because it's mapping close to OS interrupts, but since you wrote the kernel yourself, you already have the access-level you want no matter what language you use). Languages like forth are also very close to the metal yet expose much higher-level constructs and safety, too. The likes of ATS can perform arbitrary low-level operations in complete safety (although ATS's ugly as shit).
>>53287754
Congrats asshole you're the best troll i've ever seen.
I kek'd
>>53288374
lmao butthurt
>>53288374
>SICP was too hard for me but K&R was perfect
>>53285384
but this does output 24
>>53288405
>>53288434
>samefag
Your retard is showing.
>>53288522
>not even the same person
Ctards everyone!
>only one person can possibly be less retarded than me!11
>>53288518
Is it just my impression or there are people on /g/ who considers themselves C programmers just because they passed a college course?
>>53288537
>>53288434
>>53288405
>double samefagging
>being this retarded
grow up m8
>>53288576
If they took a class on C probably, I think you're a C programmer if you write C regularly. If it's been more than a year you /used/ to be a C programmer.
>>53288652
If you wrote C everyday for 10 years but its been 10 years since you've worked you are more than likely still a good C programmer so it wouldn't be used to be.
>>53288672
>If you wrote C everyday for 10 years but its been 10 years since you've worked you are more than likely still a good C programmer so it wouldn't be used to be.
A good C programmer with a 10 years' gap in understanding of how modern C has evolved since then.
>>53288679
I meant five years but still, you'd think he would have the ability to jump in and get up to speed quick even after 10 years.
>>53288704
I agree, I'm just pointing out that C also changes over time
>>53288679
how has modern C evolved in the past 10 years? give examples to support your argument.
>>53288723
Not the samefag but one thing i'd say is definately 64bit programming. The underlying assembly is completely different.
>>53288723
https://en.wikipedia.org/wiki/C99
https://en.wikipedia.org/wiki/C11_(C_standard_revision)
>>53288723
the _Generic keyword.
>>53287547
(x = â—¡ =) happy to oblige, also you're fat in real life.
>>53288089
http://warp.povusers.org/OpenLetters/ResponseToTorvalds.html
>>53285324
you're right C sucks
>ruby for life LMAO xDDD
Buffer overflow.
>C
>bad
Well, I wouldn't say C is bad, I mean it's used in the likes of the linux kerSegmentation fault
>>53287271
>sizeof is a function
you don't belong, m8
>>53287948
>include the header by themselves
never happens
>>53288052
>how do you know?
by reading the standard, you fucking monkey
>>53287529
malloc doesn't need to be casted
you don't get void pointers because you're not assigning it to a void pointer
>>53288100
>correct C according to the C standard
false
>>53292700
>facts are false
>pls sir i no c sir pls hire me sir
>>>/india/
>>53288751
nothing to do with C
>>53287529
everything in this post is wrong.
>>53292701
>I don't know C so I can't explain what happens
anon...
>>53292715
>facts
you only think that because you don't know C
>>53292761
ok pajeet
>>53292786
>ok
great; admitting your lack of knowledge is the first step
>>53292882
ok rajesh
>>53292895
>butthurt for getting told so easily
Top keks!
>>53292895
what is this shit flinging contest even about at this point?
who knows what and doesn't know something else?
>>53292929
Summary: the big dick playa that knows C rekt the unsuspecting "screen pic" faggot that doesn't.
>>53292925
ok pajesh
>>53292929
Some retard who doesn't know C thinks he is an expert at C for not knowing what the standard says, causing him to fly into an impotent rage as other people actually know the C standard and write valid C programs. He then goes around recommending C as if it were a usable language, despite the fact he literally doesn't even know C.
>>53293001
This guy? >>53287958
lmao whata bunch of fuckin nerds
>>53293016
>animooooooooooooooooooooooooooooo
>>53293013
No, this guy is correct.
This guy: >>53287969
>>53285324
Which one is sexier?
C:#include <stdio.h>
int main()
{
printf("Hello World\n");
return 0;
}
C Sharp:public class Hello1
{
public static void Main()
{
System.Console.WriteLine("Hello World");
}
}
>>53293029
>No, this guy is correct.
But that doesn't look correct at all. Do you even know enough C to have an opinion on this?
>This guy: >>53287969
All he said is true.
>>53293050
OCaml:let () = Printf.printf "Hello World\n"
>>53293087
Samefag harder rajeet. Maybe learn C sometime.
>>53287529
>malloc needs to be casted, otherwise you will just get void pointers
>>53293099
I actually know enough C to recognize the problems with that code. You should take your own advice.
>>53293050
Second one.
>>53293029
>this guy is correct
>this guy
anon, we all know samefagging when we see it
>>53293050
first one is both too verbose and incorrect
>>53293163
explain
>>53293050
first one
clear and concise, except for that int line what the hell man
>>53285324
old
>>53283128
nope
>>53288275
i wanna buy a set of pine64's but i'm leaning to a t1000 sun blade instead... more cores
>>53293132
The irony is palpable.
>>53293181
implementation defined main definition; use of printf instead of puts
>>53293266
>I don't know C
>>53293275
main definition is standard-compliant.
>>53293289
>I'm from india sir I know good C and kindly do the needful
>>53293290
>standard-compliant
what standard? not C, anyway
>>53293304
>projecting this hard
>>53293275
using printf isn't incorrect, it's just not ideal for a simple string ending with a newline
>>53293460
never said printf is incorrect
>>53287969
>calling out others on unnecessary stuff
>insisting on using int main
this guy
>>53293504
so using printf over puts is being too verbose?
i'd say the problem lies somewhere else than verbosity
>>53293635
>printf over puts is being too verbose?
obviously; do you know what verbose means?
>problem lies somewhere else than verbosity
it has that too, as already stated
>>53293559
>this guy
wants correct code? you disagree with that?
>>53287754
>muh features
You can have them when you can implement them efficiently and thread-safely in kernel-space. Till then, C will remain the language of choice for system software.
>>53285324
C doesn't suck for the same reasons the internal combustion engine doesn't suck
doesn't change that fact that it's long overdue for a replacement
>>53293128
>he doesn't cast his mallocs
Do you also have unprotected sex with niggers?
>>53293559
>his OS doesn't have exist statuses
>>53293780
>not just calling your own functions straight from _start()
Pleb
>>53293667
>obviously; do you know what verbose means?
yeah but i don't really see how a newline escape sequence is too verbose
>>53294023
do you fail to see how "puts("Hello World");" is shorter than "printf("Hello World\n");"?
btw, the return statement is also useless
>>53285384
4 = 6 times an integer?
The C Compiler assumes you completely understand the core concepts of the Cee-Lang Virtual Machine, as well as how most classes of standard "integer" behave on your native CPU architecture when applying common arithmetic instructions.
Provided you know these 2 core concepts you've mastered C. That's really it.
>>53294082
I see it's shorter but the difference is so minimal only a true autist would consider the latter "too" verbose
>>53294139
I have.
>>53294238
>I see it's shorter
great, that was the point; backpedaling is not required.
would you prefer to write "System.Console.WriteLine(String.Format("Hello World"));" instead in the C# version?
>>53293757
>I literally don't even begin to have a clue about what I'm saying
Typical ctard.
>>53294139
No, it's impossible to master C. Proof: even the greatest minds in the world still cause buffer overflows and leak memory.
>>53294663
No, I don't.
>>53294449
that IS the C# version
>>53294727
are you mentally ill?
>>53294663
Who says they weren't rushing, or calling other's code?
>>53294797
who says a language is usable if it requires literally infinite time to make a non-dangerous program with it?
>>53285324
Header files for no good reasons.
>>53294817
>literally
anon...
>>53294818
>I don't understand C
you're not entitled to an opinion then
>>53294911
I most likely understand C and compiler construction much better than you ever will.
Well, there is no good reason for them to exist.
They don't improve the implementation of linking, the ease of writing stuff or distributing libraries and they don't reduce the performance or memory size required for compilation.
A good module system with can beat the header/implementation thing in every regard.
And even if you wanted shipped headers for your own moronic reason, there is no reason to require them on all other occasions.
Reasons like these are why K&R should have offed themselves instead of reinventing CPL in far worse.
>>53287958
Compile the file with -E and look a the resulting file in a text editor then you understand
C BASICS THAT KEEPS YOU FROM GETTING REKT:
- compile your program with gcc and use "-ansi -Wall -pedantic -g" , look up what it means
- install nemiver
- debug your program with nemiver ./programname
- install valgrind
- When youre allocating memory use valgrind ./programname to check for leaks
- use "man fuctionname" f.e. "man printf" or use "man libraryname" to get the manual for a certain library like f.e. "man stdio"
>>53294911
>>53295135
Oh and before I forget, if you wanted to ship them so badly because you were too retarded to document your library properly it could have designed to generate those header files, but they fucked that up, too.
>>53286916
yeah the stack, man! Hmmm yeah the stack, and that heap is real important too right, man?
>>53295135
>the ease of writing stuff
Improves significantly with headers.
>or distributing libraries
Significantly easier to distribute libraries with headers since you can distribute the library blob and the headers without the implementation, allowing people to code against the API without runtime dynamic linking and function pointer capture hacks.
They also significantly improve documentation because you have the API and documentation in one place separate from the implementation, meaning a lot less text bloat in the implementation files and a centralized, easy to navigate documentation and API reference.
A good module system will literally always be implemented with a header/implementation pair, whether or not they need to be put in different files.
Not to mention that header/implementation separation allows hot-pluggable implementations.
TL;DR: you obviously don't know the first thing about C, compilers, or programming languages.
>>53295135
you probably don't understand C or compiler construction if you think your high-level modules would ever work securely and efficiently as headers do
>>53295135
>better than you ever will
serious sign of mental retardation
>there is no good reason for them to exist
you don't know anything about C
>They don't improve bla bla bla bla
do they simplify the language?
>good module system with can beat the header/implementation thing in every regard
except simplicity and reliability
>shipped headers for your own moronic reason
you don't make any sense
>no reason to require them on all other occasions
read some more about C
>>53295311
>>53295341
lol you guys dont know anything about anything it a miracle youre able to write
>>53295222
>worthless drivel
tldr
>>53295406
OK pajeet.
>>53295406
kill you're self
I found this function qsort in my C standard library
Is it botnet?
>>53295456
>kill you're self
>you're
>>53295459
yes.
use qsort_r instead.
>>53295481
newfag fuck off.
>>53295481
>I don't belong
m8...
>>53295459
It should actually be renamed ssort because it's slow as fuck, unlike the C++ std::sort.
>>53295519
>unlike
bwahahahahaha
>>53285324
>Why C is sucks?
lots of needless small flaws that add up
> unhygenic macros
> array/ptr decay
> in-band (null-terminated) control for C strings
the language doesn't offer any safe abstractions, so safety is a "design pattern" for shit as simple as passing and iterating through arrays.
and the worst thing is tha C fags can't understand that the language didn't need to bounds checking on every single element access to be 95% safer.
>>53295536
>bbut facts doesn't real!?!
ctards everybody
>>53295551
>muh safe abstractions
>I don't need performance
faggots like you should know their place and stick to slow, managed languages
>>53295551
>in-band (null-terminated) control for C strings
I'll never understand what's so bad about this. I understand the ""evil"" about the null sentinel, but the whole point of C is that if you want to store the size of a string along with the string itself, malloc & structs are available.
>>53295568
>facts
bjarnecucks actually believe this
>>53295551
>decay
>I don't even know what the fuck I'm talking about
>>53295605
maybe it's you who doesn't know
>>53295605
Literally any person with even remote knowledge of C knows what he's saying, which by definition must mean you don't even know the first thing about C.
>>53295613
who knows? maybe "decay" is mentioned in the standard, right? it's not like you've read it or anything!
>>53295643
>Literally
ask me how I know the rest of the sentence is not worth bothering
>>53295590
> keeping an array's element count associated with the array when you pass it to a function is an extravagence
>>53295551
>C fags can't understand that the language didn't need to bounds checking on every single element access to be 95% safer.
proven in your first reply
>>53295605
neo-/g/: where everything people don't understand is equivalent to rotational velocidensities
>>53295661
I guess I don't understand what being "in the standard" has to do with anything. the post was "criticisms of C", not "undefined shit not in the standard that I hate about C"
maybe put down K&R and pick up a book on comprehension
>>53295686
>I'm inbred and nobody can stop me!
>>53295715
>I don't understand
thus, not entitled to an opinion on C
>>53295706
>got told
>must control damage
m8...
>>53295722
literally?
>>53295764
It's funny because he understands C better than you ever will.
>>53295828
>than you ever will
the mental illness is strong here
>>53287754
>Feature parity with what are essentially subsets of c
Are you retarded?
C is how you program Von Neumann machines. All other languages are abstract simulations.
>>53295828
>he understands
>>53295715
>I don't understand
TOP FUCKING KEK!
>>53288307
>Languages like forth are also very close to the metal yet expose much higher-level constructs and safety, too.
You've clearly never used Forth.
Forth has zero type checking and it doesn't even check the 'parameters' passed to words (words just assume they have what's needed on the stack, and when they return the caller again assumes the stack is balanced, all with zero compile time checking).
Further more, the return stack is completetly exposed and even encouraged to use for arbtrary data, meaning it's extremly easy to introduce arbtrary code execution if you're not careful.
>>53295551
>> array/ptr decay
ah, the first and most correct response to OP's question, guaranteed to start flame wars every time, since it's true. (and it only took 170 responses this time)
>>53295590
>>53295605
>>53295661
>>53295686
for all you slow children, here's the deal:
> fundamental semantic trait of C is pass-by-value
> can't do this sanely with buffers
> pointers can be passed by value and operated on with [] syntactic sugar to get at elements
> type system is very poor, so making arrays (ptr, len) tuples with automatic casting (e.g., static sized int[N_ELEM] getting length fields added on call to a function) was not reasonable
> every time an array without in-band termination is passed to a function, size information is lost unless passed as a separate un-attached parameter
> people fucking this up all the goddamn time is how we get HEARTBLEED, etc.
> passing length params is a pain in the ass, so C strings defined as in-band null terminated
> which causes string overflows every time an idiot makes a bad assumption about buffer and input sizes, etc.
The bigger sin IMO was actually probably pass-by-value, instead of pass-by-(default-const-)reference, with ABIs allowed to optimize as pass-by-copy for small const references, since that has infected many other languages that managed to do buffers more sanely.
>>53295934
>muh dream architecture
well, reality needed a practical language and that language is C; keep jerking it to lisp machines, pedofag
>>53295934
>>> array/ptr decay
>ah, the first and most correct response
bwahahahaha, do you have any idea what you're talking about, m8? there's no such thing in C
>instead of pass-by-(default-const-)reference, with ABIs allowed to optimize as pass-by-copy
this ain't memejs, you idiot, things need to be efficient!
>other languages that managed to do buffers more sanely
typo for "slowly"? hahahahaha
>>53295934
>with ABIs allowed to optimize as pass-by-copy for small const references
You could only do that for inlined functions, because the callsite couldn't possibly know if the function will take the address of the reference (which is supposed to be the address of the referenced object, not of the local copy)
>>53296060
>there's no such thing in C
bud ...
>>53296090
yes, bud, it might come as news to you; read the standard for more shocking insights! you won't believe it when you're done and haven't seen one mention of "array/ptr decay"
>>53296136
of course not -- it's just a phrase to describe some details (which *are* in the standard). read some more:
https://lkml.org/lkml/2015/9/3/428
>>53295605
>decay
>>53296060
>no such thing in C
good lord, you dumb niggers...
"array decay" in C just means that you can't pass an array through a function argument without losing any size information the caller may have had.
> i.e., array arguments "decay" into pointers inside the callee
workarounds can obviously be done with separate length args, null termination, etc., but even "good" developers fucking this up is by far the single biggest source of security exploits in C programs.
keeping the pointer and length tied together at the language level doesn't cost a program any performance penalty since a safe program always needs to track both anyway.
>>53296187
>talks about standard
>uses 3rd party discussion link to prove his point
how about linking to the standard, you massive impressionable faggot?
>>53296187
>just a phrase to describe some details
codewords for "I don't know the actual standard terminology because I haven't looked at it but I head this shit on them webs"
>>53296204
>array arguments "decay" into pointers inside the callee
not even close; please stop citing random blogs and just read the standard
>>53295909
Found the clinically retarded.
>>53296204
>doesn't cost a program any performance penalty
>safe program always needs
and that's how you get lagdroid
>honestly guise, some more checks enforced every fucking time for no reason won't slow things down at all!
>>53295591
>I'll never understand what's so bad about this. I understand the ""evil"" about the null sentinel, but the whole point of C is that if you want to store the size of a string along with the string itself, malloc & structs are available.
I'm not a C programmer, so take what I write with a grain of salt.
If I wanted to create a more sane string type in C I would have to write something like:
typedef struct{ char *str;
size_t length;
} string;
But then wouldn't I lose all those functions that assume null terminated strings?
>>53296262
>not even close
As usual, cfags literally don't have a single clue about the language they suck the cock of.
>>53296262
>>53296241
>>53296225
just read it -- it says everything I already knew: arrays aren't pointers but decay into a pointer which point to the beginning of the array. who knew?
>>53296204
>safe program always needs to track both anyway
Not ALL THE TIME in ALL THE PLACES though. You don't need to pass around everywhere the length of a sha-1 digest buffer, do you?
>>53295591
Then none of the C string functions would work with your format, and as a result you'll have to rewrite the entire C standard library. Oh, and also every library that uses any features from the C standard library, which is all of them.
>cfags
>retarded
Choose two.
>>53296317
why do you assume that you should remove the null sentinel when you do this? surely you'd keep them for the inevitable function which needs just a regular old c char array. c++ does this too
>>53285324
>procedural programming
>in 2016
seriously now, C itself is ok; pointer arithmetic is clumsy but once you get the hang of it it gets manageable. i think c biggest problem are the libraries that use different coding styles; stuff like returning a int with error code or returning -1 for error code and ERRNO (errno is pretty bad); also if you are making syscalls get ready for headaches since they are constantly getting broken or are already broken, and people don fix it
>>53296328
you forgot to include a citation that proves your point
>>53296350
>Then none of the C string functions would work with your format
they aren't just regular char arrays, they are a structure. you wouldn't pass a structure to a function expecting a char pointer type, would you?
>>53296377
You forgot to not get lobotomized.
>>53296380
Exactly. Glad you understand that your argument was beyond retarded.
>>53296333
>just read it
I did
>everything I already knew
orly? you ALREADY knew? what blog post do you know it from?
>decay into a pointer
where does it say that? surely if you ALREADY read the standard you can quickly point it out
>>53296405
i don't think you understand what you're even arguing about.
>>53296410
>where does it say that?
ISO Sec. 6.2.2.1, Sec. 6.3.2.1, Sec. 6.3.6
>>53296425
Since you are retarded, maybe reddit would be more your pace.
>>53296369
>pointer arithmetic is clumsy
it's just fucking awesome; no language without pointer arithmetic will ever be taken seriously for low level programming
>>53296387
>I don't have one
expected
>>53296443
mirageos is written entirely in ocaml - an actually competent language. It is also the most popular microkernel by far.
>>53296262
>>53296410
The standard calls it "conversion", and other people call it "decay" to reflect that extra information is only lost.
> §6.9.1(10):
> On entry to the function, the size expressions of each variably modified parameter are evaluated and the value of each argument expression is converted to the type of the corresponding parameter as if by assignment. (Array expressions and function designators as arguments were converted to pointers before the call.)
>>53296437
are you even aware there's a C string library which does exactly what I said? i never said that a packing a char array along with its size in a struct would be able to be coerced into a char array.
which is the whole point of C -- gives you the ability to define shit the way you want. don't like depending on null sentinels to determine length? pass it with a struct. otherwise, shut up
>>53296459
It is pretty obvious that you don't have a brain, anon. No need to blog about it.
>>53296480
It's OK to be retarded, just don't do it on 4chan.
>>>/tumblr/
>>53296510
oh ok i'm just getting trolled now
>>53296443
what is "the correct tool for the job"
>>53296518
>being literally so retarded you think reality is trolling and saying the most stupid thing remotely conceivable is normal
>>>/reddit/
>>53296549
>what is "the correct tool for the job"
I'm not sure, but I can tell you what "the incorrect tool for the job" is.
C.
>>53296510
>implying 4chan isn't worse than tumblr
>>53296570
kek
but you're wrong
it's C++
>>53296435
nothing about decay there
>>53296471
>other people
yes, the retards that don't know what they're talking about
>extra information is only lost
nothing is lost; the original array is still an array, it didn't lose anything, it didn't "decay" to anything; the expression involving it has pointer type; that's something else that idiots such as yourself can't comprehend
>inb4 pedantry
yes, it's what separates the knowledgeable from the amateurs like you; stick to css programming
>>53296590
Is that literally everyone uses C++ over C when it's not to program for an environment with only C primitives?
>>53296598
cool bud. you can argue semantics all day. good job bud
are you this guy as well?
>>53296152
>>53296624
could you rephrase that? i didn't understand
>>53296627
>hurr durr semantics
read a book, you fucking illiterate shit skin!
>>53296624
english?
>>53296598
are you so retarded as to think that people were arguing that data at rest in a caller got destroyed?
(btw, you can't put words into peoples' mouths then try to engage in a semantics argument about what you thought they meant.)
it's just information as viewed by a callee that's lost, and it's why shit like Heartbleed and the more recent SSL getaddrinfo() bugs come to be.
>C bait threads still get hundreds of (You)'s
>>53294652
>I wanna have nice features across the board, but I don't wanna go through the trouble of figuring out how to make them work stably on a bare metal environment where I don't even have access to a standard library, and I have no idea what the overhead would be
Go away, you're either trolling or buttmad 'cause we can find jobs and you can't.
Stay rectally shattered.
>>53296598
> get told, stays mad
topkek, buddy.
if you can't handle people saying mean things about your favorite language, you probably aren't tough enough to hang around a board even as retarded as /g/.
maybe go to /v/ and try for an even lower audience?
>>53296718
>data at rest
no such thing
>in a caller got destroyed
nope; didn't argue something that doesn't exist
>information as viewed by a callee that's lost
the callee didn't lose anything because it didn't have it in the first place, stop being an idiot
>shit like Heartbleed
sloppy programming, not validating your input is a problem in any language, but cargo-culting retards like you get their knowledge from click-bait article titles
>>53296782
C is the best!
>>53296858
your ass will drip blood for a long time after being rekt by such a big dick
>aren't tough enough
fite me irl, fgt!
>>53296867
C breeds sloppy programming because its type system is so shitty.
Are you surprised that buffer management bugs exist when functions can't return arrays or even accept them without decaying them into pointers?
The language could have been VASTLY better with a very small number of changes, and all your crying can't change the truth.
Stay mad, neckbeard.
>>53296858
>people saying uninformed things
ftfy
>>53296907
> people point out legit criticisms
> become CIDF because they don't use my preferred terminology, don't actually defend the faulty semantics.
kek
>>53296350
>Then none of the C string functions would work with your format, and as a result you'll have to rewrite the entire C standard library.
Actually it wouldn't be a bad "interim" solution.
You could fake real array types with structs containing pointers and a size/length field, and build all the functions of the standard library around that.
But really, we need a C substitute.
>>53296905
>breeds sloppy programming
nah, it's just that the average programmer is shit; you'll be shit with any language but some of them will try very hard to protect you from your stupidity; C doesn't give a fuck about retards like you
>functions can't return arrays
how retarded can you be to want to do that?
>without decaying them
no such thing
>VASTLY better with a very small number of changes
nothing is stopping you to use Go, the "new systems programming language"; oh, performance is shit and you can't actually do systems programming? you don't say!
>all your crying
not the one crying, it's html shits such as yourself that can't comprehend a simple language
>stay mad
why would I be mad when I'm clearly better than you at every single thing? I fell pretty good :^)
>>53296952
>You could fake real array types with structs containing pointers and a size/length field, and build all the functions of the standard library around that.
yep this is what C++ does and is why std::sort is twice as fast as qsort.
Why c++ doesn't have garbage collector?
Becuase there would be nothing left.
TOP KEKS
>>53296996
>>without decaying them
>no such thing
what is it that you've been trying to tell the whole thread for 200+ posts about decayed pointers. what is your point?
>>53296939
>people point out legit criticisms
more like pointing out their ignorance
>my preferred terminology
it's called a standard, you should get acquainted with it instead of talking about stuff you don't understand
>>53297003
>std::sort is twice as fast as qsort
bwahahahahaha
>>53297055
>>fact
>bwahahahahaha
Cfags everybody!
>>53297023
>what is it that you've been trying to tell
>decayed pointers
that they don't exist, how fucking handicapped can you be?
>>53296996
>>functions can't return arrays
>how retarded can you be to want to do that?
how retarded are you that you can't see the semantic value of keeping array locations and lengths tied to each other across function calls and returns?
>>53297003
>yep this is what C++ does and is why std::sort is twice as fast as qsort.
I don't know. qsort requires that you pass a function pointer to it, maybe that's why it's slower.
>>53297064
>no proof
>fact
m8...
>>53297092
It's one of many reasons, not the only reason.
>>53297082
>that they don't exist
which is like saying "death doesn't exist, but unlife does."
>>53297039
when people can cite what portion of the standard they're referring to, and everyone else understands and agrees to what they were saying even before that, odds are that you are the one with some cognitive shortcomings.
>>53297084
>I want high level abstractions in this language designed for performance
who's the retard here?
>>53297107
>which is like saying
please, you just don't belong here
>>53297084
you can return a pointer to an array
>>53297092
function pointers generally won't matter these days as compilers "lookup" the function so the "indirect" call and direct call (without function pointer) produce the same assembly
>>53297126
The people who don't know about the likes of ATS, or even ancient languages like forth and bcpl (a.k.a. you).
>>53297145
>>>/reddit/
>>53297155
Calls to functions via pointers cannot be inlined, unlike actual function calls.
>>53297126
>Abstraction necessarily impacts performance
>>53297126
>who's the retard here?
you obviously are.
arrays should be passable and returnable, and retards who think they need to pass arbitrary sized array locations without a length parameter can manually cast parameters to pointers.
ta-da!
>>53297203
it does
>>53297117
>when people can cite
they cite random blog posts
>portion of the standard they're referring to
yet they don't understand what the standard says and instead use click-bait terminology they've saw on stackoverflow
>and everyone else understands
no proof of "understanding"
>and agrees
sure, cargo-culting like cattle; just admit it, this is not for you, you'd be better off in "web development"; there you have the opportunity to get all your information from blogs and twitter because there are no standard documents anyway
>>53297171
yes, that's where you should go
>>53297003
std::sort takes a pair of iterators - not any length - and in fact it doesn't even guarantee a valid pair at compile time, so if you pass iteratios from two different containers or just out of range iterators (since they overload arithmetic like pointers) you can have a buffer overflow.
The only reason std::sort is (typically) faster is because it's defined in a header file.
Pull out a qsort definition into the header so the compiler cant constant fold and inline (and both gcc and clang can inline function pointer calls when definition is visible) and you'll get equivalent performance.
>>53297214
>it does
Really?
Everytime?
>>53297158
>performance
m8...
>>53285324
Having to recompile every fucking time you modify your code. God i hate that shit
>>53297254
yes, every abstraction incurs a cost, no matter how small.
which is why every (non-trivial) hand-built assembly program will be faster than one written in C which will be faster than one written in Ruby.
those are big leaps in abstraction, but thousands of smaller leaps make up the big ones.
>>53297220
>>when people can cite
>they cite random blog posts
>>53296471
>§6.9.1(10):
uh-huh.
stay mad that people are using mean terms to describe your pet language. :)
>>53297214
> [citation needed]
>>53297220
>>53297240
>I literally don't know shit about C
>that means I'm an expert on C
I will never understand how you can possibly reach this conclusion. You are truly amazing: a unique specimen, by all rights too dumb to breathe on your own, yet here you are on 4chan shitposting.
>>53297213
>arrays should be passable and returnable
if you don't care about performance, try memejs
>need to pass arbitrary sized array locations without a length parameter
performance is desired, yes
>manually cast parameters to pointers
how about you manually pack your shit in structures that have a size field? ta-da!
>>53297257
>say the most retarded shit imaginable
>add "m8..." at the end to make sure everyone knows you're the same inbred everytime
ok kid
>>53295135
you do know that C is capable of providing proprietary object files with the interfaces in the header files, right? It is a way for the linker to link your program to other proprietary things.
Also, header files are where you put your forward declarations.
Header files also provide a way of information hiding.
It doesn't seem like you've programmed in C for more than 5 minutes.
>>53295909
>>53296293
This has to be bait. There is no other explanation to this idiocy. Poe's Law?
>>53297203
looks like it, nobody showed the opposite
>>53297003
>yep this is what C++ does and is why std::sort is twice as fast as qsort.
no. running a small test program has this kind of result.qsort : 115948, 0.115948 seconds
std::sort: 166944, 0.166944 seconds
>>53297277
Except it's false. It's virtually impossible to hand-write faster assembly than C compilers generate.
>>53297316
compilers are pretty advanced, no doubt, but still have to make trade-offs based on what it *thinks* is going on. and it gets that wrong sometimes.
>>53297241
don't scare the htmlcucks, anon! they read on stackoverflow that std::sort is magically faster!
>>53297286
I can't tell if you're a troll or a genuine retard, but your dedication to your craft is remarkable.
>>53297241
yes, but not for strings, which was my point. i was talking about strings so I assumed everyone knew the context.
>>53297277
>yes, every abstraction incurs a cost, no matter how small.
Meta abstractions have zero runtime cost (like a macro that repeats a statement you would've had to manually repeat).
>>53297280
>mean terms
aka invented; what's the matter, haven't read the standard to find out the proper terms? hahahahaha! back to CSS!
>inb4 muh decays!
>>53287529
do you even know why void pointers exist and stuff like malloc() doesn't just return char*?
>>53297277
>yes, every abstraction incurs a cost, no matter how small.
Dude, are you trolling or what.
What are macros?
>which is why every (non-trivial) hand-built assembly program will be faster than one written in C which will be faster than one written in Ruby.
Well, if you have a C program that is 5% faster than a asm one, is that really worth it?
Ever heard of tradeoffs?
>>53297277
but a working program is always faster than a non-working program, no matter how efficient it has been programmed.
that is why abstraction is a thing
>>53297306
Who knows, people who like C are always those who know nothing about it. It can't be just poe's law. I'll call it Claw for now.
>>53297281
>here you are on 4chan busting our illiterate asses with your big dick
well, time for you to move back to tumblr if you can't take it
>>53297313
Couldn't laugh any harder. Your retardation is a thing to behold.
>>53297291
pls, m8, no need to make a complete clown of yourself
>>53294449
No, I like C, but I really think you're making a dumb argument about verbosity when it comes to printing a string with printf and puts.
The real issue is how printf is more expensive and how it's a potential disaster if it's taking user input.
>>53297358
Which is why non-shit type systems can enforce valid memory access completely a compile-time, and bounds-checking almost completely at compile time (completely at compile-time almost always).
>>53297316
>virtually impossible
but not literally, amirite? fucking webshits
>>53297309
>looks like it, nobody showed the opposite
Macros?
>>53297377
Always? Senpai, I love C. It makes great backend modules for real compilers!
https://github.com/sbcl/sbcl/
>>53297339
>nothing to say anymore
ta-da!
>>53297358
You bring up a really good point of having code write itself in the compiler phase, but that has no bearing of the abstractions of the language itself. Would you rather have hygienic Lisp macros or macros for assembly? Macros write code and if that code is an abstraction, it incurs a performance hit.
So, macros for a garbage collected language are going to produce code that's -- guess what? -- garbage collected (an abstraction).
>>53297374
>>53297372
So you still agree with me that abstraction incurs a cost which was my argument.
>>53294663
Everyone makes mistakes, even in dumb as shit languages people fuck up.
If your definition of mastering a language is never making a single mistake in it, I just want to say: good luck.
>>53297316
It's trivial to beat any C compiler for any half decent asm orogrammer.
Often not by much, say a couple cycles or so, but it's pretty much always possible, one obvious thing compilers are handicapped by is rigid ABIs - they have to follow a particular calling convention which leads to a lot of unnecessary register spills which a manual asm coder can easily avoid.
>>53297372
>tradeoffs
backpedaling this hard, already?
>>53297437
There's a difference between never making a mistake and never making a critical, world-ending mistake.
>>53297440
>one obvious thing compilers are handicapped by is rigid ABIs - they have to follow a particular calling convention which leads to a lot of unnecessary register spills which a manual asm coder can easily avoid.
and create non-portable code
>>53297440
Oh, you're just trolling. Carry on.
>>53297401
>if it's taking user input
it isn't, are you fucking blind?
>>53297455
>>53297437
Both of you are wrong. The real mistake is not using Common Lisp
>>53297405
>almost
well, they're almost performant
>>53297485
The real mistake is not using OCaml. Common lisp's only advantage over modern OCaml is the ability to live-modify a running image, and the syntax. In all other matters, OCaml is strictly superior.
>>53295135
just rename your header files to have a .c filename extension and satisfy your autism :^)
>>53297470
>and create non-portable code
but the point was that asm can be faster than C when hand written
>>53297419
yes, C has those
>>53297498
It means you get your out-of-bounds check that you would've written by hand anyway only if required - and the compiler can tell if it's required better than you can, and it can also add or remove the check as needed without your having to reanalyze the entire program. In all instances where it's not needed, it won't be there. The only instance where it would be slower is if you accept C programs that are faster but crash under conditions.
>>53297472
>I don't know what those words mean so you must be trolling
please see yourself removed from this thread
>>53297435
>So you still agree with me that abstraction incurs a cost which was my argument.
There is a canuck vibe to this post
>>53297528
So you admit you're retarded then.
>>53297485
>>53297502
SLOW
L
O
W
>>53297429
Retarded it is. How sad.
>>53297556
OCaml is very fast (especially with flambda), SBCL is quite fast but slower than OCaml. If all you care is speed, you should be using forth anyway, not C. Moreover, ATS is C: "what if it were actually good?" edition.
>>53297528
C macros are like JS "objects". Horribly implemented and not worthy of their name.
>>53297556
>not having my eyes 60/60/24/7 on 4chin is bad
So fucking what, duck my sick.
We're talking about C's disadvantages, we'll pick that bone on another occasion.
>>53297551
how does that follow from C having macros? it also has functions! and types! and loop constructs! do you have a point?
>>53295481
how new can one be to still be baited by the oldest shit up the oldest oldfag's sleeve?
>>53297565
>I got told like countless other times by the big dick playa
ta-da!
>>53297582
>SBCL is quite fast
>slower than OCaml
who gives a shit about meme language comparisons between themselves? how are they compared to C? oh, slower? get the fuck out!
Why use C over C++?
Should I even bother learning C?
>>53297597
You're not worthy of breathing the air.
>>53285324
>Why C is sucks?
off the top of my head, and stealing other things listed here...
> abysmal type system
> call-by-value semantics is cancer
> unhygenic preprocessor macros
> compilation model designed around 1960s RAM limitations
> inability to pass arrays intact to/from function calls
> null terminated C strings
> high concentration of sperglord fans
Don't get me wrong, I prefer languages with non-spaghetti stacks (i.e., any functional language) and without exception based flow control (pretty much anything OO), but C could have been better regardless of the sins of other languages.
>>53297602
It's OK timmy, don't think too much about it, the tiny pea you call a brain might explode!
>>53297671
>Why use C over C++?
To work on legacy systems written in C, or if you're masochistic.
>Should I even bother learning C?
No. Even embedded systems are programmed in C++ nowadays.
>>53297683
one word for you: reserved identifier
>>53297582
>If all you care is speed, you should be using forth anyway, not C.
There are no Forth compilers that generates better code than gcc or clang ( not even close in fact)
>>53295706typedef struct {
nigger_t *sons;
uint64_t count;
} your_wifes_sons_t;
>>53297649
>le sbcl is a meem ebin meem
>>53297675
Watch your edges, bismuth
Shit, /g/ is the new /b/
>>53297703
>one word for you
>1. reserved
>2. identifier
>one word
Oh, Timmy...
>>53297683
You forgot that Lisp has proper macros, you filthy web shit!
>>53297715
>/g/ is the new /b/
now we KNOW you're new
>>53297723
if you need to count 2 words, you should consider killing you're self
>>53297649
Both can be faster than C. ATS is strictly faster than C about 90% of the time. OCaml is around 10% slower than C on average, sbcl is about 30% slower. Shittily written C code is an order of magnitude slower than the equivalent shittily-written program in either of these languages. When optimizing for speed in all these languages, speed is almost the same (+-2%).
>>53297760
I agree, but unfortunately, Timmy doesn't.
>>53297764
>can be faster than C
ah yes, the myth of the sufficiently smart compiler? java claimed the same once
>OCaml is around 10% slower than C
>sbcl is about 30% slower
so... slower
>Shittily written C code is an order of magnitude slower
you being incompetent is not C's problem
>>53297745
>could try to stay on topic and actually address real topics
>nah, let's just play the hurr durr otheranon is a newfag meem instead
>>53297786
kill you're self regard less
>>53297772
no, that would allow 32 bit computers to use it, which implies he has a cuck level lower than 2^32
>>53297812
>mad for getting found out
you don't belong, laddie
>>53297795
>literally can't read
As expected from a ctard.
>>53297812
What real topics? Some pro-C autist who has never used C in his life even for the likes of a hello world trying to twist reality is not "real topics".
>>53297839
>>>>>>>>>>>>>>>>>>found out
>>53297795
>i have the efficiency of assembly language combined with the portability of assembly language. Unless you're programming kernels or compilers, you don't need that speed. Newsflash, kid, it's not 1970 anymore. Programmer time is now actually valuable, and flogging yourself to squeeze out extra cycles is counterproductive.
>>53297710
> silly anon thinking I'm married
>>53297829
although niggers have zero value, they still have surprisingly large *size*, and it is a count of kids, not the count of Tyrones she fucked.
>>53297710
> cfags can't into coding simple structs
try this, genius:typedef struct {
mulatto_t *chillins;
size_t count;
} youre_waufus_niglets_t;
>>53297906
>Newsflash, kid, it's not 1970 anymore. Programmer time is now actually valuable
It's 2016 where a significant chunk of computing takes place on battery powered devices and better performance directly correlates to better battery life.
We could have way longer battery life if all apps were written in C.
>>53285324
one not already mentioned:
dereferencing operator is prefix instead of postfix.
Ritchie admitted they realized that was a mistake even in the early 70s but that it was already too late to change.
>>53297988
it's the count of tyrones she fucked, niggers dont make kids with the same cuck's wife more than once
>> silly anon thinking I'm married
ooh you left her because you didn't have a >64 bit computer to keep track of her sons? :^)
stay buttmad cuck, maybe im one of your wife's sons daddy <3
>>53298646
> imblying your non-nigger sized dick is good enough
> imblying niggers can even into /g/
>>53298707
>cuck shows his true power
you had some of that nigger cock too huh?
>>53298768
nah, just playing along, since I know the number of decent black C programmers in the history of the world can probably be counted on one hand.
back to the issue at hand:
size_t count for sons will be adequate for 32b machines even for the conceivable future.
Current UN projections don't show the count of all the niggers in all of Africa to overflow uint32_t until 2080-2090, and that includes the she-boon half.
>>53298867
I'm very aware that size_t would be preferred for this, but then again the point of the post in the first place wasn't really to make a realistic struct as much as it was to make a joke.
uint64_t was just to show it had to be a huge fucking number
